号称“天生一对”的容器+微服务，能躲开微服务的悖论陷阱吗？
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者，给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术，此文不要错过。
一、微服务的悖论
Gianna作为高级软件工程师加入了Avidoo公司，这是一家生产力平台。在与其他团队的会议上，她提出了微服务的问题，以及团队是否开始采用。她立即得到了强烈的反应。
拜伦表示：“我们尝试过采用微服务，但是它们不起作用。
“这带来了可怕的混乱!”另一位同事补充说。
Gianna三次眨巴眼睛，期待着某种阐述，但没有一个往下接着说。
Gianna沉默了一会儿，问：“发生了什么事?
“起初很棒。每次我们被要求做新的东西时，我们都可以添加一个服务，并使用想要实验的任何语言和框架。我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间，事情开始越来越频繁地割裂，开发速度放慢了。 Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用，而他们打算建立的是微服务。
分布式巨石应用和其他庞然大物
Gianna所遇到的问题太常见了。微服务是灵丹妙药，IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
却忘记了天下没有免费的午餐这件事。除了优势之外，精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务，只有微服务不能提供的好处，或者由于它们的缺点而造成的不可接受的风险。使用微服务的优势选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点：
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时，这要求团队之间进行大量的协调，不可能同时处理一个特性。
利用单一专业团队创造价值
微服务通过cover一个功能来促进自治。因此，一个团队可以完全拥有它，而不需要多个团队一起，这有助于减少跨团队的协调。
利用多学科团队创造价值
2.更大的容错
团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中，通信通过REST接口，按需和pull-based。当这种互动是关键任务时，依靠这种通信的服务要么必须有合理的fall-back，要么就会失败。这种不健康的模式常常被系统运行状况检查所证明，如果系统的一个依赖性不健康，系统运行就会失败。除了导致部署顺序难以管理之外，它还说明了系统依赖性的困难。
运行时依赖关系
使用正确的软件架构(如event sourcing)，可能补充CQRS，可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
3.细粒度的软件生命周期管理
开发和业务人员一个共同的愿望是，尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写，又或由于紧张的上市周期需求而导致的技术债务，都使得开发速度落后了。有人可能天真地认为，这些是可以快速被替代的，但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改，反之亦然。
缺乏细粒度的软件生命周期管理
通过高度调节系统间通信，可以完全切换一个或多个功能，而不必触发任何依赖系统。
4.灵活的技术选择
不可否认，这是一个棘手的问题。在需求或个人兴趣的推动下，入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工，坦白地说，这可能导致大规模的罢工。
迫使技术做出选择
只要这些技术可以集成到自动化测试和部署工作流程中，一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控，日志记录和通信规则的组件。
那么为什么他们失败了?
因为不知道应该如何去做微服务。采用微服务并不会失败，因为人们不知道如何去做，他们经常不记得首先要解决什么问题。与其他任何决定一样，采用微服务会带来一些成本。软件架构师往往会忘记，他们不应该帮助企业的管理者采用微服务，而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
二、微服务和容器：6大长期管理技巧
部署基于容器的微服务仅仅是个开始，如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中，Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息：“部署容器非常容易。
他言简意赅的说：“尽管部署容器很容易，但是要多思考这些系统的运维。”
你可以用容器化的微服务深入到生产环境，但大多数专家不会推荐它，特别是如果这是你第一次使用这个强大的技术。
基于容器的微服务有相当多的优势：正如红帽技术布道者(Gordon Haff)最近写到的：“即使Match.com(编者注：一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划，持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线，需要实施智能最佳实践，确保高效运营。
SolarWinds公司的负责人Kong Yang说：“第一天之后，所有事情都变得更加复杂。
我们询问了Yang、Kavis等人，他们对有效管理容器化微服务的最佳建议。
1.保持简单
面对不断增加的复杂性，想要保持高效吗?那就保持简单，愚蠢。这种设计和工程原理，通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
对于Johnson来说，KISS和管理哲学一样重要，“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
对于IT团队来说，这些想法有一个可见的翻译，特别是在微服务和容器方面。
“为确保今后的成功运营，让每个微服务做一件事，做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
2.尽早把管理计划落实到位
微服务和容器可以实现更快，更灵活，更弹性，响应速度更快的软件团队。但首要的事情是，在部署到生产之前制定一个计划。这样一个计划的范例框架如下：
开发部署，安全和运维的最佳实践微服务和容器利用现代化的日志记录和监控解决方案探索容器管理工具(又名编排平台，如Kubernetes)，在云端和非云端点上了解自身的环境定期实行post-mortems，不断学习和提高
3.选择一个编排平台
编排工具对于容器化微服务的长期成功至关重要。
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如，一旦微服务不报告或者正在被超载，就可以用一个新服务替换或者被复制。”
4.制定一套最低限度的运营能力
一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说，除了像Kubernetes这样的编排系统之外，还需要确保每个容器化的微服务都遵循“最低限度的运营能力”，以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表：
编排系统需要能够访问每个微服务上的API，确定它是否准备好接收流量，以及是否健康。需要告知微服务何时正常关闭的方法。需要微服务公开指标和日志记录。在大多数情况下，微服务需要能够水平扩展，并且在某些情况下具备集群意识。
Grange也为开发人员分享了一些好消息：特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java，可以节省大量的开发这些最低功能的前期工作。
Grange说：“这些让开发人员更容易做正确的事情，获得许多开箱即用的功能，而不必编写更多的代码。
5.实施持续集成和持续交付
Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示，持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处，尤其是作为支撑企业编排工具的基础。
McGrath说：“如果没有CI / CD，微服务的维护将会因为手动流程而变得不堪重负，无法按预期进行扩展，并且最终将比基础设施和人力资源中的整体应用成本更高。”
随着时间的推移，CI / CD将帮助团队释放编排或管理工具的潜力，尤其是在管理如何在主机池中分配CPU，内存和存储时。
McGrath解释说：“一旦CI / CD成为产品生命周期一个自然的组成部分，管理系统就非常好，它们处理各种基础架构需求，并将其作为工程师的逻辑配置参数。“对于运维来说，要全面了解主机，容器和服务的资源消耗情况，以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定，而是与基础设施需求相联系时，这一点非常重要。”
6.不断重新审视并重新投资业务