Event-Driven Architecture

在传统的整体应用程序中，维护多个实体之间的数据一致性非常简单。关系数据库引擎提供封装在本地 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 保证了强一致性，但由于几个架构缺陷，它在云原生微服务环境中崩溃了：

在现代分布式微服务架构中，事件驱动架构 (Event-Driven Architecture) 已经成为实现系统解耦与高扩展性的核心基石。微服务会定期触发领域事件（如 OrderCreated、PaymentProcessed）以同步状态变更。 然而，如何保证事件发布的绝对可靠性却是一个关键挑战：如何确保数据库更新与对应的事件发布要么同时成功，要么同时失败？ 如果微服务先更新本地数据库（如 PostgreSQL 或 MySQL），再通过网络将消息发送至消息中间件（如 Apache Kafka 或 RabbitMQ），一旦发生网络抖动或服务崩溃，就会导致数据不一致。 为彻底解决这一难题，系统架构师普遍采用 Transactional Outbox 模式。 核心痛点：双写问题 (Dual-Write Problem) 在传统的双写实现中，微服务按顺序执行两个独立操作： 将业务数据写入本地数据库。 将事件消息发送至 Kafka 消息队列。 如果数据库事务提交成功，但随后由于网络故障导致 Kafka 发送失败，数据库中保存了订单，但下游服务却永远无法收到通知。结果：数据严重不一致。 什么是 Transactional Outbox 模式？ 该模式充分利用了关系型数据库原生的 ACID 局部事务 特性。 微服务不再在 HTTP 请求生命周期内直接向网络发送消息，而是将事件 Payload 写入同一个数据库中的 Outbox 表，该写入操作与业务实体的更新处于 同一个本地事务 中。 数据库 ACID 机制保证了：业务数据与 Outbox 事件记录要么同时提交成功，要么同时回滚。