什么是微服务设计模式？

这些架构模式为开发团队在实施分布式计算系统时面临的日常挑战提供了标准化的解决方案，包括服务通信、数据一致性、容错和系统可扩展性。

当今世界依赖的诸多数字化体验，正是借助微服务设计模式得以实现，这一点在众多实际应用案例中得以印证。例如，当您在 Netflix 上观看流媒体节目时，实则是数百个独立服务协同工作的结果，这些服务共同负责内容传输、用户档案管理及观看推荐等功能。

同样，亚马逊通过不同的服务协调库存、支付和运输。在金融行业，银行和其他机构也依靠微服务设计模式来分离风险管理和客户服务，确保资金安全便捷。

根据 IBM 2021 年《企业微服务调研报告》，88% 的企业表示微服务为开发团队带来了多重效益。这些效益包括：得益于更优的代码组织、更便捷的维护和更快的部署周期，开发人员生产效率提升了 20% 至 50%。

微服务架构是一种云原生方法，它将应用程序拆分为松耦合的独立服务，这些服务部署在容器中（由 Kubernetes 等编排平台管理）。

每项服务都以自己的科技堆栈（包括专用数据库和数据管理模型）独立运行。服务之间的通信通过 REST API、事件流平台，如 Kafka 和消息代理进行，而团队设计服务围绕业务功能，具有明确的边界，称为边界上下文。

这种现代化的软件开发方法支持现代数字化转型行动所需的操作灵活性，如开发运维 (DevOps) 自动化和 CI/CD 管道、云迁移、应用程序现代化和人工智能 (AI) 整合。

尽管微服务为现代应用程序带来显著优势，但何时选择该架构仍需通过与传统单体架构对比方能决策。

单体架构将应用程序构建为单个可部署单元，其中所有业务功能都集成并共享相同的代码库、数据库和运行时。微服务架构将应用程序分解为更小的、独立的微服务，这些微服务通过明确定义的应用程序编程接口进行通信，每个微服务可能都有自己的数据库和部署周期。

这两种设计方法的核心差异在于耦合度，即系统各组成部分之间的连接紧密程度。单体架构内部耦合度高，但微服务部署简单；微服务架构服务之间耦合度低，但对 IT 基础设施的要求比较复杂。

软件工程师通常为小型简单应用选择单体架构，例如控制成本并加速开发的小型企业或初创公司。在需要高度可扩展性、弹性和灵活性的复杂场景中（例如社交媒体平台、银行应用程序），微服务是更好的选择。

在决定采用哪种方法时，组织应根据其具体要求对每种方法进行评估，包括团队规模、应用程序复杂性、可扩展性需求和 DevOps 成熟度。

了解更多关于单体架构与微服务的信息。

微服务设计模式涵盖五个关键领域，这些领域提供了经过测试的解决方案，帮助团队解决分布式架构挑战：

1. 服务通信和发现
2. 数据和事务管理
3. 应变能力和故障处理
4. 架构和整合
5. 事件与通信

服务注册模式

服务注册模式创建了一个中心化目录，服务在此注册其端点与健康状态，从而消除了固定地址的需求。当服务间需通信时，会查询注册中心以发现可用服务实例。例如当支付服务需要联系库存服务时，会查询注册中心以定位健康的库存服务实例。

API 网关模式

API 网关模式在客户端和多个后端微服务之间创建单个入口点。API 网关不是客户端单独调用不同的服务，而是接收一个请求，将其路由到适当的微服务并将响应组合成结果。

例如，在加载产品页面时，网关可以同时从不同的服务获取产品详细信息、定价、库存和评论。然后，它会在对客户端的单个合并响应中返回所有这些信息。

服务发现模式

服务发现模式解决了服务在动态环境中相互定位的挑战。随着微服务扩大规模或更新到新版本，其网络位置会不断变化。服务发现模式为服务提供了自动化机制，以便服务自行注册并查找需要与之通信的其他服务，从而无需硬编码地址。

每个服务模式的数据库

每个微服务的数据库模式可确保每个微服务拥有并管理自己的数据库，从而消除微服务之间的共享数据依赖关系。这种方法防止了服务之间的数据访问，降低了耦合度；不过，这种方法要求服务在需要从其他信息源获取信息时必须通过 API 进行通信。例如，在企业资源规划 (ERP) 系统中，会计服务独立于人力资源服务的员工数据库管理财务数据。

Saga 模式

Saga 模式通过将跨多个微服务的事务分解为协调的步骤来管理这些事务。每个服务都完成其本地事务并触发链中的后续步骤。如果任何步骤失败，该模式会自动运行操作以撤销之前的步骤。例如，在处理在线订单时，如果预留库存后付款失败，saga 会自动释放预留的商品。

CQRS（命令查询职责分离模式）

CQRS 模式通过为数据修改（命令）和数据检索（查询）分别使用专用模型，实现二者的职责分离。这种分离使系统能够独立优化每条路径，在命令端最小化写入争用，在读端降低查询延迟。在电子商务系统中，下订单使用写入优化的命令模型，而生成销售报告则充分利用读取优化的查询模型。

断路器模式

断路器模式通过监视对下游服务的调用并在检测到故障时停止请求，防止一个服务中的故障扩散到整个系统。当服务变得无响应时，断路器会“跳闸”并阻止进一步的调用，从而保护系统资源并防止级联故障。

例如，如果库存服务出现故障，断路器会阻止订单服务发出重复失败的请求。这允许系统的其余部分继续运行，同时为客户提供回退响应。

隔板模式

隔板模式隔离系统资源，以防止一个区域的故障影响整个系统。就像船体中的隔间一样，舱壁将不同的功能分开，因此如果一个出现故障，其他舱壁仍能运行。该模式限制分配给特定服务的并发请求或资源的数量。

服务于前端的后端 (BFF) 模式

服务于前端的后端 (BFF) 模式创建针对每个特定前端接口定制的专用后端服务。由于移动应用程序具有与 Web 应用程序不同的要求（例如，较小的屏幕、有限的带宽、不同的性能），因此开发人员可以利用 BFF 模式针对特定前端来优化每个后端。

实体与聚合模式

实体和聚合模式根据领域驱动设计 (DDD) 概念将相关数据组织成逻辑单元。一个实体表示具有唯一标识的独特对象，例如通过电子邮件地址标识的客户帐户。聚合将必须一起更新的相关实体组合为一个单元。

例如，在电子商务系统中，订单汇总包括订单详细信息、订单项和运输信息，当发生变化时，所有这些都需要保持同步。

扼杀者模式

扼杀者模式能有效协助将单体应用重构为更易维护的微服务架构。新的微服务与现有单体系统并行构建，逐步接管功能模块，直至旧系统被完全取代。这个名字来源于一个比喻，即藤蔓（微服务）随着时间的推移逐渐生长并最终扼杀一棵树（应用程序）。

事件驱动模式

事件驱动模式使微服务能够通过发布和使用事件而不是直接进行服务调用来进行异步通信。当服务完成操作时，它会广播一个事件，其他感兴趣的服务可以侦听并做出相应响应。这种方法在服务之间创建了松耦合，允许它们独立运行，同时仍然通过共享事件系统协调它们的活动。

边车模式

边车模式指在同一个运行环境中，将辅助容器（即“边车”）与主应用或服务并行部署的实现方式。该边车容器负责处理横切关注点（例如日志记录、监控、安全性和可观测性），无需修改主应用代码即可扩展其功能。

适配器微服务模式

适配器微服务模式支持不兼容的系统或接口之间的通信。正如旅行转换器能让您的设备接入不同国家/地区的电源插座，适配器模式可实现不同数据格式、协议或 API 之间的转换。当与使用不同通信标准的旧版系统或第三方服务集成时，此模式大有裨益。

在需要高可扩展性、复杂业务逻辑和可靠系统性能的行业中，微服务设计模式尤其有价值。主要用例包括：

• 电子商务平台依靠微服务设计模式来处理销售活动期间的负载均衡，并管理多个仓库中的复杂库存。他们还协调不同系统之间的支付、运输和客户服务运营，以改善业务成果和改善客户体验。
• 流媒体服务使用微服务模式在全球范围内交付内容，同时管理用户偏好和推荐，使它们能够以最小的缓冲和个性化体验处理大量并发用户负载。
• 金融服务实施这些模式来分离交易、风险管理、身份验证和面向客户的操作，同时保持金融机构所需的严格监管合规性和安全标准。
• 医疗保健系统使用这些模式来集成患者记录、预约安排和计费系统，同时保持 HIPAA 合规性，并与不同医疗保健提供方的各种医疗设备 API 连接。
• 社交媒体平台使用微服务设计模式来独立扩展消息传递、内容提要和媒体处理，从而使它们能够每天处理数十亿次用户交互，同时保持所有功能的响应微服务性能。

微服务设计模式提供了管理当今复杂分布式系统的最佳实践，并提供了以下广泛的优点：

• 降低复杂性：针对通用挑战的标准化、经过验证的解决方案，能够带来更可预测的结果、更简便的故障排查以及更快的团队技术融入速度。
• 敏捷性和更快的上市时间：团队可以独立开发、部署和扩展服务，减少协调瓶颈并加速功能交付。
• 增强容错能力：隔离技术可防止整个系统出现级联故障，从而显著减少停机时间并提高整体系统可靠性。
• 提高的可扩展性和灵活性：企业能够将资源精准分配到所需之处，并能快速适应不断变化的业务需求，无需进行大规模系统重构。团队可以根据特定需求使用不同的编程语言（例如 Java™ 或 Python）开发服务。
• 成本效益：针对性扩展与资源优化，结合为特定服务选择最优技术堆栈的能力，可构建更具经济性的系统架构。
• 技术多样性优势：团队可根据各服务的具体需求选择最合适的工具与框架，从而构建更高效且更易维护的解决方案。例如：可选择 Java Spring Boot 相关的企业级微服务用于数据库即服务 (DBaaS)，或为数据分析场景选用 Python。

选择适当的模式取决于系统的具体要求和组织功能。使用系统方法可以指导这些架构决策。

建议先部署 API gateway 与服务发现机制，再实施事件溯源或 CQRS 等复杂架构模式。这些核心模式为更复杂的实施方案奠定了必要的通信基础设施基础。

请综合评估您在分布式系统领域的实践经验、运维成熟度及 DevOps 实践能力。微服务新团队可从基础模式入手获得初期收益，而经验丰富的团队则可攻克需要更深入运维知识的高级协调模式。

每种模式都会带来复杂性，您的团队必须对其进行长期管理。每项服务的数据库需要数据同步战略。事件驱动模式需要消息代理基础设施。确保您有能力支持自己选择的模式。

建议从少量服务开始采用基础模式，积累实践经验后，再随专业能力提升逐步扩展。这种渐进式方法可避免过度工程化，并能从早期实践中持续汲取经验。