容器和微服务天生一对吗？容器化环境能否更好地实现微服务？本文作者采访了多位从业者，给出了容器化微服务管理的6条建议。如果您也在评估和考虑微服务技术，请不要错过这篇文章。1.微服务的悖论Gianna作为高级软件工程师加入了生产力平台Avidoo。在与其他团队的会议中，她提出了微服务的问题以及团队是否开始采用它们。她立刻得到了强烈的反应。“我们尝试了微服务，但它们没有用，”Byron说。“它造成了可怕的混乱！”又加了一个同事。吉安娜眨了三下眼，希望得到某种澄清，但没有一个人继续说下去。吉安娜沉默片刻，问道：“怎么了？”起初很棒。每次我们被要求做一些新的事情时，我们都可以添加服务并使用我们想要试验的任何语言和框架。我们在需要使用或处理其数据库的系统上公开RESTAPI。但过了一段时间，事情开始越来越频繁地分裂，发展速度也变慢了。吉安娜叹了口气。听起来她的团队一直在构建分布式单体应用程序，而他们打算构建的是微服务。分布式单体应用程序和其他单体Gianna的问题太常见了。微服务是灵丹妙药，IT经理和工程师倾向于区分哪些优势适合他们的组织。但是请记住，天下没有免费的午餐。除了优势之外，精心设计的微服务架构也有消极的一面。没有“错误”的微服务，只有微服务服务没有提供的好处，或者由于它们的缺点而带来不可接受的风险。使用微服务的优势选择采用微服务首先要确定哪些优势适合自己的业务。以下是一些突出的优势：1.增强的团队许多公司的自主权围绕团队成员拥有的知识或组件来组织团队。在创造真正的客户价值时，这需要团队之间进行大量协调，不可能同时在一个功能上工作。利用单一的专业团队创造价值微服务通过覆盖一个功能来促进自治。因此，一个团队可以完全拥有它，而无需多个团队在一起，这有助于减少跨团队的协调。利用多学科团队创造价值2.更大的容错能力，团队自治还应该具有自治的特征。一个功能通常依赖于另一个。在大多数环境中，通信是通过REST接口进行的，包括按需的和基于拉取的。当这种交互是关键任务时，依赖这种通信的服务必须有一个合理的回退，否则就会失败。这种不健康的模式通常由系统健康检查证明，如果其中一个依赖项不健康，系统就会失败。除了让部署顺序难以管理之外，还说明了系统依赖的难度。运行时依赖使用正确的软件架构（如事件源），可能补充CQRS，可以完全消除大多数功能之间的运行时依赖。这主要是由于从基于拉的系统转变为基于推的系统。3、细粒度的软件生命周期管理开发人员和业务人员的共同愿望是尽快用新程序替换应用程序中的某个功能。无论是由于需求变更或重写，还是由于紧迫的上市时间需求导致的技术债务，开发都滞后了。人们可能会天真地认为这些可以快速更换，但事实并非如此。更改功能通常会导致必须更改它所依赖的许多系统，反之亦然。缺乏细粒度的软件生命周期管理通过高度规范的系统间通信，可以完全切换一个或多个功能而无需触发任何依赖系统。4.灵活的技术选择不可否认，这是一个棘手的问题。在需要或个人兴趣的驱动下，对员工进行入职和培训以转向通用技术有助于团队之间的流动性。但对于使用不同技术的多个部门的员工来说，坦率地说，这可能会导致大规模罢工。强制技术选择只要这些技术可以集成到自动化测试和部署工作流程中，团队就可以保持其技术选择。为什么要改变一个团结一致热爱C#的获胜团队？只要能生产出符合平台监控、日志和通信规则的组件即可。那么他们为什么会失败呢？因为他们不知道如何做微服务。采用微服务不会因为人们不知道如何去做而失败，而且他们通常不记得首先要解决什么问题。与任何其他决定一样，采用微服务也会带来一些成本。软件架构师往往会忘记，他们不应该帮助企业的管理者采用微服务，而应该帮助他们解决真正的业务问题。正确权衡这些方面的成本和收益对于业务需求至关重要。2.微服务与容器：6个长期管理技巧部署基于容器的微服务只是一个开始，如何有效管理？***云架构师MikeKavis分享了一个好消息：“部署容器非常容易。他言简意赅：“虽然部署容器很容易，但多想想这些系统的运维。”您可以使用容器化微服务进入生产环境，但大多数专家不会推荐它，尤其是如果您是第一次使用这种强大的技术。基于容器的微服务有相当大的优势：正如RedHat技术布道者（GordonHaff）最近写道：“即使是Match.com（编者按：婚介网站）也找不到更好的微服务合作伙伴。”伙伴。”但ITHeaven所做的大部分工作都需要一个强大而灵活的计划来持续管理企业的容器化微服务架构。您的企业可能存在实施智能安全实践以确保高效运营的学习曲线。“第一天之后，一切都变得更加复杂，”SolarWinds负责人孔阳说。“我们向Yang、Kavis和其他人询问了他们关于有效管理容器化微服务的最佳建议。1.保持简单性想要在不断增加的复杂性面前保持高效？保持简单，笨蛋。这个设计和工程原则通常被认为航空航天和系统工程师Clarence“Kelly”Johnson的指导原则。对于Johnson来说，KISS与管理哲学一样重要，“我们的目标是通过将常识应用于难题来更快、更有效地取得成果。对于IT团队而言，这些想法具有可见的转化，尤其是在涉及微服务和容器时。“为了确保未来的成功运营，让每个微服务做一件事，并且做得很好。不要将额外的功能扩展到现有的执行良好的微服务中。”2.尽早为微服务和容器制定管理计划，使软件团队更快、更敏捷、更有弹性、响应更快。但最重要的是，在部署到生产环境之前要有一个计划。此类计划的示例框架如下：开发部署、安全性和运营微服务和容器的最佳实践利用现代日志记录和监控解决方案了解您自己在非云点上的环境。定期实施事后总结，不断学习和改进。3.选择编排平台。编排工具对于容器化微服务的长期成功至关重要。“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期，”ShieldXNetworks的CTOManuelNedbal说。“例如，一旦微服务没有报告或正在超载，它就可以被新服务替换或复制。”4.制定一套最低限度的运营能力容器管理平台不会为你做所有的工作。RetrieverCommunications首席技术官NicGrange表示，除了像Kubernetes这样的编排系统之外，还需要确保每个容器化的微服务都遵守“最大运行能力”，才能在这样的环境中良好运行。他提供了以下这些功能的关键示例列表：编排系统需要能够访问每个微服务上的API，确定它是否准备好接收流量，并且是健康的。需要一种方法来告诉微服务何时正常关闭。需要微服务来公开指标和日志记录。在大多数情况下，微服务需要能够水平扩展，在某些情况下需要集群感知。Grange还为开发人员分享了一些好消息：特定语言的微服务模板库（例如Go的go-kit）和Java的dropwizard可以节省大量开发这些高级功能的前期工作。“这些使开发人员更容易做正确的事情并获得大量开箱即用的功能，而无需编写更多代码，”Grange说。5.实施持续集成和持续交付KevinMcGrath，CTO&SeniorArchitect,SungardAvailabilityServices，持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处，特别是作为支持企业编排的基础工具。McGrath说：“如果没有CI/CD，微服务的维护将因为手动流程变得不堪重负，无法按预期扩展，最终在基础设施和人力资源方面的成本超过整体应用程序。”随着时间的推移，CI/CD将帮助团队释放编排或管理工具的潜力，尤其是在管理如何跨主机池分配CPU、内存和存储时。一旦CI/CD成为产品生命周期的一个自然组成部分，管理系统就非常好，它们处理各种基础设施需求，并为工程师制作它们的逻辑配置参数。“对于运营而言，重要的是要全面了解主机、容器和服务的资源消耗情况，以便更好地了解哪里需要更多资源。当服务不再与特定基础设施相关联，而是与基础设施需求相关时，这一点非常重要连接。6.不断重新审视和重新投资业务容器和微服务不是一劳永逸的技术。DigitalOcean的工程经理MacBrowning建议，为了正确使用它们，需要对基于容器的微服务的运行方式进行持续投资。该建议适用于企业的人员、流程和工具。编排平台是一个很好的起点。“如果你完全投资并使用像Kubernetes这样的编排平台，这意味着要花费时间和资源来跟上项目和更新，”Browning说。并在您自己的部署中反映这些变化。“由于企业微服务现在集中运行，这项投资将对所有将要运行的服务产生积极影响，而不是一两个特定的单一服务。”
