在一个 东南亚数字经济博客，我们得出结论，康威定律将占上风，微服务在企业 DevOps 世界中必不可少。这意味着任何认真对待 DevOps 的人都应该学习如何定义微服务、如何管理微服务、如何最大化收益以及如何最小化问题。了解如何为不同的技术和不同的用例设计理想的微服务非常重要。本博客概述了微服务如何以最佳方式支持业务。

什么是微服务架构？

James Lewis 和 Martin Fowler 给出了微服务架构的最佳定义：

微服务架构风格提供了一种将大型应用程序构建为一套较小的服务（=IT 组件或应用程序）的方法，其中每个服务：

• 围绕业务能力构建
• 运行自己的进程
• 通过轻量级机制进行通信，并且
• 可通过自动部署机制独立部署

最后，微服务应该能够提高业务灵活性。如果新功能请求最大概率只影响一个微服务，那么就可以实现这一点，从而使 DevOps 团队能够快速修复问题，快速通过自动化重新测试并重新部署微服务。

什么是功能性微服务？

由于大多数功能请求来自最终用户，因此大多数微服务将以功能为导向。功能请求通常涉及更改 GUI、逻辑、工作流和数据，因此将所有这些部分都放在同一个可部署组件中的微服务设计将最大限度地减少变更的影响。

设计涉及的不仅仅是技术方面的考虑。我们已经看到，业务流程通常是将功能范围划分为良好微服务的最佳基础。这反过来意味着您应该让业务所有者和流程架构师参与定义架构。

我们还需要技术微服务吗？

一些微服务将更加注重技术，并且可以通过清晰稳定的请求-回复接口进行调用。当某项功能对于许多目的来说应该是相同的，并且不会经常更改时，可以将其拆分为单独的更“技术性”的微服务。

其他微服务可以面向集成，用于协调其他服务，或负责与其他大型系统和/或外部方的连接。如果中央 ESB 可以提高服务效率，则通常会用分布式专用微服务来代替，这些微服务可以保存自己的业务数据。

公司应该对微服务可以做什么和应该做什么持开放态度。一个业务领域的最佳微服务架构并不总是适合另一个领域。这与 DevOps 一致，在 DevOps 中，我们主要在团队层面委托设计决策。

重要的是不要重复使用太多或认为这是 SOA 版本 2.0。我们将在即将发布的单独博客中详细阐述这一重要主题。

组件的大小如何影响业务敏捷性？

对于微服务，大多数人认为，一个由 10 到 XNUMX 人组成的 DevOps 团队应该拥有、构建、运营和管理大约 XNUMX 到 XNUMX 个微服务。规模对于设计微服务来说相对灵活。

对于较小或相对较大的范围，没有必要将事物拆分成比业务要求更小的部分。例如，团队和架构可以与他们支持的业务功能保持一致，实现最大程度的自主性，以便轻松发展并创造价值。

然而，当“系统”的范围非常大时，将功能拆分成单独的微服务总是更好的选择。当多年来时间紧迫的修复和捷径产生不必要的依赖关系时，内部和外部依赖关系就会增加。很难改变系统，每次发布和部署的大量回归测试成本高昂且风险大。

图 2：在整体式架构中，用户组争夺关注，开发人员互相干扰。

微服务的理想规模与开发人员的数量有关。这意味着 HPA 平台比开源平台更具优势，因为它们可以稍后拆分、拥有更大的微服务或拥有更小的团队。

什么是 不会 微服务？

在推广了微服务的灵活性之后，有必要将其与 不会 微服务：

• 单体架构不是微服务，因为它们太大了。它们需要 10 人以上的开发团队，并且（通常）在同一个部署中有许多功能独立的流程。这需要更多的回归测试和更长的发布周期。依赖关系会随着规模和时间的增长而增长，并且它们不像微服务架构那样通过服务调用来明确。
• 业务数据位于 ESB 之下的分层 SOA 架构也不是微服务。它们不包含同一可部署组件中业务功能所需的数据和功能。相反，几乎每个业务功能都跨越多个技术重点突出的共享可部署单元“层”。根据 NGINX 的说法：“SOA 建立在尽可能共享的架构风格的概念之上，而微服务则建立在尽可能少共享的架构风格的概念之上。” 微服务应该是自主的并履行业务功能，因此它们具有 GUI、逻辑、工作流和数据库来在需要时存储内容。

图 4：微服务比其他模式具有更好的灵活性和业务与 IT 合作。

我们的观点：微服务的共同特征

微服务可以实现业务功能，并作为常规业务流程的一部分相互通信，使非技术人员更容易理解；这对于 DevOps 和团队决策来说是一件好事。我们认为，好的微服务应该具有以下共同特征：

1. 以流程为导向

功能性微服务通常实现业务流程的一个阶段或完整的业务功能。“服务”这个名称具有误导性。微服务可以是可调用的服务，也可以是专注于最终用户功能的应用程序。

2. 自主灵活

微服务应该单独开发、单独部署并包含自己的数据。它们应该随着时间而发展，并且易于更改和重新部署。

3.自动化和控制

微服务应该具有良好的测试和部署自动化、错误处理、监控和警报，并应允许用户反馈。

4. 大小合适

“微”这个词也有些误导，微服务既不能太小也不能太大。服务可以相对较大，最多可容纳 10 名开发人员。它比单体应用要小，但不必比普通应用小。如果使用像 Mendix，一个微服务几乎可以成为一个中型公司的核心系统。

微服务对您意味着什么？

如果正确实施，微服务可以促进业务和 IT 的协调，并提高运营流程的灵活性。在以前的模式下，很难改变业务流程，因此数字化对于大多数在职人员来说非常困难。DevOps 和微服务架构通过本地化决策和开发解决了这个问题：DevOps 团队直接与业务部门合作，可以自主做出决策。微服务是单独开发的，依赖性最小，并且作为自主单元单独部署。

Mendix 提供微服务现场研讨会和培训。我们帮助大量客户制定新计划和举措，提供决策支持，并为每个业务问题制定最优解决方案。 联系我们以获取更多信息。.