3. Saga事务的两种协调方式：编排(Choreography)与协调(Orchestration)模式详解
Saga事务的核心在于如何协调多个本地事务（子事务）的执行顺序以及异常时的补偿逻辑。根据控制流的归属，业界将Saga的实现分为两种经典模式：编排(Choreography)与协调(Orchestration)。理解两者的差异是设计高可用分布式事务系统的基石。
3.1 编排模式(Choreography)
编排模式是一种去中心化的协调方式。每个参与Saga的微服务在完成本地事务后，通过事件(Event)触发下一个服务的执行。没有中央协调器，服务之间通过事件总线（如Kafka、RabbitMQ）进行异步通信，形成一条事件驱动的执行链。
核心思想：服务之间“相互通知”，每个服务只知道自己下一步该通知谁，但不知道全局流程。
3.1.1 编排模式工作流程
以经典的“订单-库存-支付”Saga为例，编排模式的执行流程如下：
- 订单服务创建订单（状态：待处理），并发布“订单已创建”事件。
- 库存服务监听该事件，扣减库存，并发布“库存已扣减”事件。
- 支付服务监听“库存已扣减”事件，执行扣款，并发布“支付已完成”事件。
- 订单服务监听“支付已完成”事件，将订单状态更新为“已完成”。
如果任意一步失败（例如库存不足），则触发反向补偿事件链：
- 库存服务发布“库存扣减失败”事件。
- 订单服务监听该事件，执行补偿事务（取消订单）。
关键特征：事件驱动、无中心节点、服务间高度解耦、异步通信。
3.1.2 编排模式SVG流程图
3.2 协调模式(Orchestration)
协调模式是一种中心化的协调方式。引入一个独立的协调器(Orchestrator)，负责管理整个Saga的执行流程。协调器以命令(Command)的方式通知各个参与服务执行本地事务，并根据执行结果决定下一步是继续执行还是触发补偿。
核心思想：协调器“发号施令”，所有服务听从协调器的指挥，协调器掌握全局状态。
3.2.1 协调模式工作流程
同样以“订单-库存-支付”为例，协调模式的执行流程如下：
- 协调器向订单服务发送“创建订单”命令。
- 订单服务执行成功，回复协调器。
- 协调器向库存服务发送“扣减库存”命令。
- 库存服务执行成功，回复协调器。
- 协调器向支付服务发送“执行扣款”命令。
- 支付服务执行成功，回复协调器。
- 协调器向订单服务发送“确认订单”命令，完成Saga。
如果库存服务失败，协调器直接向订单服务发送“取消订单”补偿命令，无需等待其他服务。
关键特征：命令驱动、有中心节点、流程控制集中、同步/异步通信皆可。
3.2.2 协调模式SVG架构图
3.3 两种模式对比分析
选择哪种模式取决于系统的复杂度、团队技术栈以及对事务一致性的要求。下表从多个维度进行详细对比：
| 对比维度 | 编排模式(Choreography) | 协调模式(Orchestration) |
|---|---|---|
| 控制中心 | 无中心，服务间通过事件驱动 | 有中心，由协调器统一指挥 |
| 通信方式 | 异步事件（消息队列） | 同步/异步命令（RPC/消息） |
| 服务耦合度 | 低耦合，服务只感知事件 | 高耦合，服务依赖协调器 |
| 流程可观测性 | 弱，需追踪事件链 | 强，协调器集中管理状态 |
| 复杂度 | 服务内部逻辑复杂（需处理事件订阅与发布） | 协调器逻辑复杂，但服务逻辑简单 |
| 错误恢复 | 通过反向事件链补偿，调试困难 | 协调器直接触发补偿，易于控制 |
| 适用场景 | 服务数量少、流程简单、团队对事件驱动熟悉 | 服务数量多、流程复杂、需要强管控 |
| 典型实现 | Axon Framework、Eventuate Tram | Camunda、Temporal、Seata AT/TCC |
3.4 模式选择建议
避坑提示：不要因为编排模式“看起来更酷”就盲目选择。如果团队对事件溯源(Event Sourcing)不熟悉，编排模式中的事件风暴和调试成本会急剧上升。对于大多数企业级分布式事务场景，协调模式是更稳妥的选择。
- 优先选择编排模式：当业务流程简单（2-3个服务）、服务间天然存在事件订阅关系、且团队具备事件驱动架构经验时。
- 优先选择协调模式：当业务流程复杂（超过3个服务）、需要严格的执行顺序控制、需要审计日志、或者团队希望将事务逻辑与业务逻辑分离时。
- 混合使用：在大型系统中，可以针对不同子域混合使用两种模式。例如，核心交易链路使用协调模式保证强管控，非核心通知链路使用编排模式降低耦合。
架构决策要点：协调模式牺牲了一定的服务自治性，换来了流程的可控性和可观测性。在分布式事务鉴权拦截场景中，协调模式更容易在协调器层面统一注入鉴权逻辑，而编排模式则需要每个服务独立实现鉴权拦截，增加了重复代码和安全漏洞风险。