云原生时代的微服务，适合所有人么？(3)

分布式服务的基础架构已经成熟，但是更高的效率只能来自于更好的声明式系统，这些声明式系统来自于改进的自动化技术和改进的可观察性。因为没有任何微服务是完全相同的，这么做可能很棘手。它们的任何自定义工作流程就像雪花一样。不同之处在于底层的体系结构，以及如何适应针对不同工作负载的微服务方法的不断开发。

设置边界很重要，这样微服务就不会被认为是万灵药或有趣项目的分支，因为微服务需要更多的管理。开发者大批量地构建微服务要追溯回2014年至2016年的鼎盛时期，这些开发者在喝茶聊天的时候决定了新的微服务该怎么构建。因此现在如果有几十个团队决定创建自己的微服务，会发生什么?虽然管理是完全可能的，但是会牺牲效率，从而影响优化和获得更好性能的过程。

毫无疑问，微服务是有效的。但是，一个构建良好的单体应用整体架构也可以扩展，并且在许多场景中仍然是很好的选择。例如，运行相同服务或工作程序的多个实例不一定需要微服务。创建不可伸缩的微服务也是完全可能的。因此在确定解决方案之前，首先考虑面临的问题是很重要的。

就基础设施和技术支持而言，生态体系现已接近关键的规模。微服务正迅速成为DevOps工具包中的一个工具，从而更好、更深入地利用资源。这进而创建了新的空间来交付额外的服务，从而进一步实现声明性的和优雅的工作流、工具和平台的潜力。

向着微服务过渡的业务和流程决策

云原生微服务是一种真正令人兴奋的架构演化，尤其是在构建、部署和管理复杂分布式应 用程序方面。然而，大多数围绕微服务的讨论直接涉及到技术：持续集成和部署、容器、 编排器等等。虽然技术实现很重要，但是还有一些更重要的事情需要考虑。

微服务必须与组织的目标相适应。开发人员可以构建微服务，但是体系结构只有与业务目标相结合时才有价值。因此必须提出关键问题，从业务用例、现有团队、技能和职责开始——采用微服务的决策取决于组织的目标和远景。组织中具有实现复杂体系结构经验的人员必须提出一个重要的问题，并在继续前进之前得到答案：我们是否适合微服务体系结构?

Container Solutions的CEO和联合创始人Jamie Dobson曾表示，客户找过来希望使用微服务作为技术问题的解决方案，实际上却常常是组织问题的技术解决方案。

评估云原生服务。评估企业采用云原生微服务与企业本身的关系，而与企业的规模、行业甚至实际技术关系不大。首先，从决策到执行的微服务迁移应该由企业的组织和管理方式驱动：

商业模式：软件可以差异化业务吗?如果是这样，开发团队必须继续增长和扩展，因为组织需要更多的资源和服务功能。基于微服务的体系结构允许更快的迭代开发，可以在跨多个团队的工作流中使用。依赖专有的、统一解决方案的组织将不太适合微服务方法。系统记录管理(ERP)到服务级别协议(SLA)类的商业软件协议意味着，如果企业选择遵循将它们带入微服务讨论的路径，那么它们将发生根本性的转变。对于完全依赖于商业软件平台的组织来说，实现微服务的成本可能会更高。微服务所需的在敏捷性和可伸缩性方面的工程支持和开销成本将超过它们的价值。

文化和内部流程：微服务需要一套新的工具和流程，并打破旧的工具和流程。对于负责管理单体的组织来说，突然改变工作流可能是一个困难的转变。接受DevOps原则是微服务成功的关键。然而，举例来说，团队可能会抗拒从传统的瀑布方法转向敏捷方法。微软首席云开发布道师Bridget Kromhout曾表示，“如果你意识到所涉及的人有着他们自己的习惯而且他们也许在不远的未来就要退休了，那么这种抵制并不是完全不合理的，而且他们不喜欢一切改变的想法，他们只是以他们喜欢的方式看待问题。”

微服务的基本复杂性在于应用程序体系结构本身：根据体系结构，每个服务都需要自己的支持团队、工具和基础设施。并不是每家公司都在正确的位置采取行动。专家强调，并不是说错误地采用这种体系结构是不可能的，只是这个过程会更长或更复杂。对于许多有着错误商业动机或文化的组织来说，成本将高于收益。Bridget Kromhout再次强调：不能通过实施正确的技术解决方案来解决组织中的每一个问题，因为组织是复杂的系统，其中也有可能以不可预知方式行事的人。

那么，什么时候微服务不适合企业呢?

敏感行业：某些行业，例如金融服务和医疗保健，面临法律、报告和合规要求，需要与新技术相协调。可追溯性因素：与更年轻、更紧凑或更敏捷的组织相比，一家在商业领域经营数十年的全球性公司，尤其是平均员工保留时间超过10年的公司，很可能更难适应向全新架构的巨变。“停滞不前”的公司：这些是规避风险的公司，决策链很长，层次结构僵化。因此当采用一种新的响应性微服务范例时，这些组织并不十分适合，甚至可能会对所需的快速适应产生抵触。

New Relic的首席站点可靠性工程师Jonathan Owens表示，考虑转向容器和微服务架构的组织应该问自己以下问题：您的运营团队向开发人员提供了什么产品，该产品使用了什么抽象层? 该产品是否适合您的业务，还是容器更合适? 容器是否更好，以至于您愿意更改抽象层，从而更改运营团队提供的整个产品，以便使用它们?您是否已准备好创建新角色来管理此新抽象的规模和可靠性?

没有哪个组织会在一夜之间发生这样的变化。从一个理想化的新架构到第一个产品部署的过程需要改变许多想法并创建新的流程，这并不总是很有趣。寻找具有微服务专业知识且能够做出必要的工具和架构决策的工程师也很困难。这些专家包括难以捉摸的“全栈开发人员”，他们了解每一层的应用程序：从网络和托管环境，到数据建模、业务逻辑、API和用户界面以及用户体验(UI / UX)。这些人处于独特的位置，可以看到技术体系结构和组织是如何相互关联的。要实现成功的微服务转换，组织需要一个按比例构建的技术体系结构，但维护该结构的团队也同样重要。

这就是为什么许多正在向微服务过渡的组织选择与专业服务公司合作，这些公司专门帮助客户使用各种不同的架构来构建云原生应用程序。这些顾问可以帮助评估组织对微服务的需求和适用性，或指导他们采用更合适的替代方案。

微服务最适合吗?

（编辑：ASP站长网）