作为在各个组织中实施微服务的人员，我想分享一些通过学习和实践经验获得的宝贵见解。

微服务到底是什么？为什么它们可能是您组织的正确架构选择？

让我们深入了解微服务架构的核心概念和优势。

什么是微服务？

微服务是围绕业务领域建模的可独立部署的服务。业务领域是这里的关键，稍后会详细介绍。它们通过网络相互通信，并为解决复杂的架构问题提供了许多选项。

可以将微服务视为小型、专注的团队，而不是庞大的部门。每个团队都有特定的职责，在一定程度上独立运作，并在需要时与其他团队清晰沟通。您拥有的不是处理所有事务的庞大代码库，而是多个小型代码库，每个代码库专注于特定的业务功能。

正如 Sam Newman 在《从单体到微服务》中定义的那样：

微服务是围绕业务领域建模的可独立部署的服务。它们通过网络相互通信，作为一种架构选择，它为解决您可能遇到的问题提供了多种方案。

微服务提供了一种设计模块化系统并将其分解为有界上下文的策略。然而，我经常看到的问题是，开发人员使用微服务来强制执行代码边界。这是一个错误。我们稍后会解决这个问题。

微服务的关键特征

让我们探讨一下定义微服务的一些关键特征：

独立部署

您可以对微服务进行更改并将其部署到生产环境，而无需部署任何其他内容。这不仅仅是一种理论能力，而是您在大多数发布过程中实践的一项准则。

这里的价值是巨大的：较小的部署带来较小的风险，实现更快的发布周期，并允许团队单独测试他们的更改。

当某个服务出现严重错误时，您可以只修复并部署该服务，而无需协调整个系统的发布。这在大型系统中尤其有用，因为协调发布可能是一场后勤噩梦。

业务领域聚焦

微服务是围绕业务功能而非技术层进行组织的。您无需设立单独的前端、后端和数据库团队（以及所需的协调工作），而是可以设立专门负责“活动管理”、“客户账户”或“考勤”的团队。

这种一致性使得业务功能变更的实现更加便捷，因为所有相关代码（从 UI 到数据存储）都集中在一起。当业务需求发生变化时，您通常只需更改一项服务，而无需跨多个层级协调变更。

数据所有权

微服务封装了数据存储和检索功能，仅通过定义明确的接口公开数据。数据库隐藏在服务边界内，而不是在服务之间共享。

这与传统的多个应用程序共享一个数据库的方法形成了鲜明的对比，通常会导致紧密耦合和有风险的模式变化。

当服务独占其数据时，它可以：

• 在不破坏其他服务的情况下改进其内部数据模型
• 实施最适合其需求的存储技术
• 提供稳定的API供其他服务访问其数据。

多个服务共享同一个数据库的情况并不少见，但这样做会牺牲一些微服务的优势。实际上，每个服务一个数据库是最常见的做法。

网络通信

服务通过网络相互通信，使微服务成为一种分布式系统。这种基于网络的通信可以根据具体需求使用REST API 、消息队列、gRPC、GraphQL 或其他协议。

这种通过网络进行的显式通信允许服务独立部署，甚至在不同的基础架构上运行。但这也意味着需要处理网络延迟、潜在故障和序列化问题。

构建微服务的团队需要仔细设计其服务间通信模式，以平衡性能、可靠性和灵活性。

微服务的起源

“微服务”一词的起源颇有意思。2011年，一位名叫詹姆斯·刘易斯（James Lewis）的软件顾问开始对他所谓的“微应用”感兴趣——一种经过优化、易于替换的小型服务。

这些服务的显著特点是规模非常小。有些服务只需几天就能编写或重写。随着讨论的深入，“微服务”一词被逐渐采用，因为它们并非独立的应用程序，而是协同工作的服务。

值得注意的是，虽然名称中包含“微”，但微服务的大小并非其定义特征。相反，它指的是边界清晰的服务，可以独立开发、部署和扩展。

微服务的主要优势

采用微服务架构有什么好处？为什么您应该为您的组织考虑它？

让我们来探讨一下一些主要优势：

灵活性和适应性

微服务为您提供多种选择。它们为您提供了随时间扩展、发展和维护系统的灵活性。

• 当业务需求发生变化时，您可以只修改受影响的服务，而不必冒险更改整个系统。
• 新功能可以作为新服务引入，而不会破坏现有功能。
• 随着您对领域的理解不断加深，服务边界可以不断发展以更好地反映这种理解。

这种逐步发展的能力在快速变化的商业环境中尤其有价值，因为在这种环境中，上市时间至关重要。

技术多样性

借助微服务，您可以混合搭配各种技术栈。每项服务都可以使用最适合其特定需求的编程语言、数据库或框架。这种做法被称为多语言编程和多语言持久化。

例如，推荐引擎可能会使用带有专门机器学习库的 Python。另一方面，事务处理服务可能会使用 .NET，因为它具有强类型和性能特性。

报告服务可能使用针对分析进行优化的列式数据库，而用户配置文件服务可以使用更适合其数据模型的文档数据库。

这种灵活性使得团队可以为每项工作选择合适的工具，而不是采用一刀切的方法。

并行开发

多个团队可以同时开发不同的服务，互不干扰。这种并行化可以显著加快大型组织的开发速度。

每个团队都可以维护自己的发布计划，制定技术决策，并根据特定服务的需求进行优化，而无需与其他团队协调。我亲眼见证了这种自主性如何减少团队之间的依赖，最大限度地减少瓶颈和等待时间。

组织通常围绕服务或相关服务组来构建团队。你可能知道这个概念，即康威定律：

设计系统的组织被限制于生产出复制其组织通信结构的设计。

 

有针对性的扩展

您可以只扩展需要扩展的服务，而无需扩展整个系统。这可以提高资源利用效率并降低运营成本。

例如，如果您的产品目录需要在销售期间处理高流量，则您可以只扩展目录服务，而无需扩展支付处理服务。

随着系统规模不断扩大，不同组件的性能特征也各有不同，这种精细的扩展能力变得尤为重要。有些服务可能是 CPU 密集型的，而有些则是内存密集型的。借助微服务，您可以根据每项服务的特定需求优化基础架构。

与扩展整体结构相比，这种方法可以节省大量成本，因为在整体结构中，所有组件都必须一起扩展，而不管其各自的要求如何。

组织协调

微服务可以帮助您的技术架构与组织结构保持一致。团队可以根据其业务领域的专业知识，拥有与其对应的特定服务，从而促进更清晰的所有权和责任制。

这种协调减少了团队之间的交接和协调成本，因为每个团队都有明确的职责界限。它以积极的方式支持了康威定律。与其让沟通结构意外地影响你的架构，不如围绕业务能力精心设计团队和服务。

随着时间的推移，这种方法可以带来更稳定的团队结构和软件边界，因为业务领域的发展速度往往比技术实现的速度慢。

微服务需要考虑的挑战

虽然微服务提供了许多好处，但也存在挑战：

分布式系统复杂性

网络通信会带来延迟、可靠性挑战，并使调试更加困难。服务必须妥善处理网络故障，使用退避策略实现重试，并应对请求可能成功但响应可能丢失的现实。

分布式跟踪对于了解请求如何流经系统至关重要。

你需要制定应对部分系统故障的策略。像断路器和隔板这样的概念将成为你日常词汇的一部分。

运营开销

管理许多服务需要强大的部署流水线、监控和调试工具。您需要投资自动化部署、健康检查、扩展以及服务发现。每项服务都需要监控、日志记录和警报。

这种开销可能相当可观。成功运行微服务的组织通常拥有强大的 DevOps 文化和工具来管理这种复杂性。

数据一致性

如果没有数据库事务的安全性，维护跨服务边界的一致性就会变得更具挑战性。

实现跨多个服务的业务流程通常需要最终一致性模型和补偿机制来处理故障。您需要在设计服务时考虑幂等性，并且可能需要实现类似Saga 模式来管理分布式事务。

这些方法增加了复杂性，但如果正确实施，实际上可以使系统更具弹性。

服务协调

协调跨多个服务的工作流需要精心设计。单体架构中的简单流程，在微服务架构中可能会变成复杂的编排。

您需要决定是使用编排（由中央服务指挥流程）还是编舞（服务无需中央协调即可响应事件）。这些模式在耦合度、弹性和可观察性方面各有优劣。

设计这些跨服务工作流程通常会揭示您在初始建模中可能错过的子域边界。

微服务关键要点

根据我的经验，最重要的是要记住，微服务最终会给你带来选择。它们提供了灵活性，但也带来了成本。

这些成本是否值得选？

对于拥有大型工程团队并致力于开发需要快速演进的复杂系统的组织来说，微服务或许值得一些开销。对于规模较小的团队或需求更稳定的系统，精心设计的单体架构可能更合适。暂时忘掉简历驱动的开发模式吧。关键在于如何以可接受的权衡利弊来解决你的具体问题。

在我的工作中，我发现最成功的微服务采用都是从小规模开始的，通常只是从单体架构中拆分出一两个服务。然后，随着组织构建必要的技能和基础设施，再逐步扩展。这种渐进式的方法可以降低风险，并允许团队在实践中学习。

我喜欢思考这些问题：

1. 当前架构的哪些部分最能从独立部署中受益？
2. 组织在采用微服务时可能面临哪些挑战？
3. 当前系统与业务领域的匹配程度如何？

如果您想深入了解微服务的构建，但又想从单体应用入手，不妨看看《模块化单体架构》。本书用整整一章来介绍微服务的开发，包括 API 网关、消息队列的使用以及系统集成测试等高级技术。

感谢大家的阅读!

作者：大雄