Saga Pattern

在传统的整体应用程序中，维护多个实体之间的数据一致性非常简单。关系数据库引擎提供封装在本地 SQL 事务中的 ACID（原子性、一致性、隔离性、持久性）保证。如果下单、付款扣除或库存储备中途失败，调用 ROLLBACK 会立即恢复每个数据库修改。 然而，当迁移到现代微服务架构时，数据管理发生了根本性的变化。为了保证域自治和独立的可扩展性，每个微服务都拥有自己的私有数据库。单个业务操作（例如处理电子商务结帐）现在跨越多个服务边界和数据库引擎（例如，用于订单的 PostgreSQL、用于支付的 DynamoDB、用于库存的 Redis）。 由于分布式微服务不能依赖于单个数据库事务，因此维护跨网络边界的数据一致性成为分布式系统工程中最具挑战性的问题之一。 为了在不牺牲系统可用性或性能的情况下解决这个问题，软件架构师依赖 Saga 模式。 在本次深入研究中，我们将探讨传统分布式事务失败的原因，分解 Saga 模式的核心机制，比较 C​​horeography 与 Orchestration，分析隔离对策，检查 Go 和 Java 中的生产代码实现，并学习如何安全地处理现实世界的故障回滚。 根本问题：为什么微服务中的两阶段提交 (2PC) 失败 在采用 Saga 模式之前，工程师经常会问：为什么我们不能在微服务中使用传统的两阶段提交（2PC / XA）？ 2PC 的机制 两阶段提交使用中央事务管理器分两个阶段协调跨多个数据库节点的分布式事务： 准备阶段：事务管理器要求所有参与的数据库节点准备并锁定所需的行。参与者投票 YES 或 NO。 提交阶段：如果所有参与者都投票了 YES，则管理器向所有节点发出 COMMIT 命令。如果任何节点投票 NO 或超时，它会发出 ROLLBACK。 Client ----> Transaction Manager | +-------------+-------------+ | (Prepare) | (Prepare) | (Prepare) v v v Order DB Payment DB Inventory DB 为什么 2PC 是微服务的反模式 虽然 2PC 保证了强一致性，但由于几个架构缺陷，它在云原生微服务环境中崩溃了：

在 Web 开发的早期，构建软件应用程序非常简单：编写代码，将其打包到单个可执行或可部署的存档中，然后在服务器上运行。这种方法被称为单体架构，几十年来一直很好地服务于该行业。 然而，随着应用程序发展成为拥有数百名开发人员和数百万并发用户的大型企业平台，单体应用程序开始显示出其局限性。部署变得缓慢且危险，数据库成为瓶颈，代码库变得过于复杂，任何单个开发人员都无法理解。 为了解决这些扩展瓶颈，行业转向微服务架构。开发人员不是构建单个巨型应用程序，而是将系统分解为一组小型、独立且松散耦合的服务，这些服务通过 HTTP/REST、gRPC 或消息代理等轻量级协议进行通信。 在本文中，我们将分析微服务为现代应用程序带来的主要优势、它们带来的严峻挑战，以及如何确定该架构是否适合您的下一个项目。 1. 单体架构与微服务架构 在深入讨论细节之前，让我们先形象地了解这两种设计范式之间的根本区别。 在单体中，所有模块（例如，用户管理、产品目录、订单处理）共享相同的执行空间并写入单个共享数据库。在微服务设置中，每个服务都在自己的进程中运行，管理自己的私有数据库，并公开一个干净的 API。 API 网关 充当客户端的单一入口点，将请求路由到适当的后端服务。 2. 微服务的好处 采用微服务架构具有几个引人注目的优势，使其成为大规模现代系统的首选： A. 独立部署性和发布速度 在整体应用程序中，对结账系统进行微小的更改需要重建和重新部署整个应用程序。如果一个团队的功能被破坏，整个版本就会被阻止。 通过微服务，每个服务都有自己独立的 CI/CD 管道。运输服务团队每天可以部署更新十次，而无需与库存或支付团队协调，从而大大提高了功能交付速度。 B. 细粒度可扩展性 在单体应用程序中，如果结帐流程在黑色星期五期间遇到巨大的流量峰值，则必须水平扩展整个应用程序。这会为空闲模块消耗不必要的 CPU 和内存。 微服务允许有针对性的扩展。您可以启动 50 个订单和付款服务实例来处理负载，同时保持用户或通知服务以最少的资源运行，从而节省大量云托管成本。 C. 技术灵活性（多语言编程） 由于微服务通过标准化 API 协议（REST、gRPC）进行通信，因此团队不会被锁定在单一技术堆栈中： 用户服务可以用Go编写，以实现高性能的内存管理。 推荐引擎可以使用Python来获取其丰富的机器学习库。 支付网关可以用Java编写，以实现企业稳定性。 每个团队都可以为他们的具体问题选择最好的工具。 D. 故障隔离和系统弹性 如果单体应用程序中发生内存泄漏，整个进程就会崩溃，从而导致整个系统中断。 在微服务架构中，如果推荐服务由于错误而崩溃，应用程序的其余部分仍保持完整功能。用户仍然可以浏览产品、将商品添加到购物车并完成付款。故障是孤立的。 E. 团队协调和自治（康威定律） 康威定律指出，组织设计的系统模仿其通信结构。大型庞然大物通常会导致庞大的跨职能团队互相踩踏。 微服务允许组织将工程部门分解为小型、自治的“双比萨团队”。每个团队都拥有一个端到端的服务——从设计和编写代码到部署和数据库维护。