3. Saga 执行模型：Choreography（编排）与 Orchestration（协调）
Saga 模式的核心在于将一个分布式长事务拆解为一系列本地事务，并通过补偿机制保证最终一致性。根据事务决策与执行流程的控制方式，Saga 分为两种主流模型：Choreography（编排）与Orchestration（协调）。理解两者的原理与适用场景，是设计可靠 Saga 补偿方案的前提。
3.1 Choreography（编排）模型
编排模型采用去中心化的设计思想。每个参与 Saga 的微服务在完成本地事务后，通过事件总线（如 Kafka、RabbitMQ）发布领域事件。其他服务监听这些事件，并根据事件内容决定是否触发下一步操作或补偿操作。整个流程由事件驱动，没有中央控制器。
核心特征：服务间通过事件进行“对话”，每个服务只关心自己需要响应的事件，流程逻辑分散在各个服务中。
3.1.1 编排模型工作流程
以经典的“订单-库存-支付” Saga 为例，编排模型的执行流程如下：
- 订单服务创建订单（状态：待支付），并发布“订单已创建”事件。
- 库存服务监听该事件，执行库存预扣，成功后发布“库存已预扣”事件；若失败，则发布“库存预扣失败”事件。
- 支付服务监听“库存已预扣”事件，执行扣款，成功后发布“支付成功”事件；若失败，则发布“支付失败”事件。
- 订单服务监听“支付成功”事件，将订单状态更新为“已完成”。
- 补偿流程：若支付服务失败并发布“支付失败”事件，库存服务需监听该事件并执行库存回滚（补偿事务）。
3.2 Orchestration（协调）模型
协调模型引入一个中央协调器（Orchestrator）。协调器负责管理整个 Saga 的执行流程，它向各个参与服务发送命令（Command），并收集响应结果。协调器根据响应状态决定下一步是执行正向事务还是触发补偿。该模型将流程控制逻辑集中在一个地方，便于管理和监控。
类比理解：编排模型像一场“即兴爵士乐”，乐手们互相倾听并即兴配合；协调模型像一场“交响乐”，由指挥（Orchestrator）统一控制每个乐章的起承转合。
3.2.1 协调模型工作流程
- 协调器收到“创建订单”请求，向订单服务发送“创建订单”命令。
- 订单服务执行成功，回复协调器；协调器记录当前步骤状态。
- 协调器向库存服务发送“预扣库存”命令。
- 库存服务执行成功，回复协调器。
- 协调器向支付服务发送“执行扣款”命令。
- 支付服务执行成功，回复协调器；协调器标记整个 Saga 为“已完成”。
- 补偿流程：若支付服务返回失败，协调器立即向库存服务发送“补偿预扣库存”命令，并向订单服务发送“取消订单”命令。
3.3 两种模型对比分析
选择哪种模型取决于系统的复杂度、团队对流程可见性的要求以及服务间的耦合度。下表从多个关键维度进行对比：
| 对比维度 | Choreography（编排） | Orchestration（协调） |
|---|---|---|
| 控制方式 | 去中心化，事件驱动 | 中心化，命令驱动 |
| 服务耦合度 | 低耦合，服务仅需了解事件 | 高耦合，服务需响应协调器命令 |
| 流程可见性 | 弱，流程分散在各服务日志中 | 强，协调器集中记录所有步骤状态 |
| 复杂度 | 服务内部逻辑简单，但整体流程调试困难 | 协调器逻辑复杂，但服务逻辑简单 |
| 补偿管理 | 每个服务需监听失败事件并自行触发补偿 | 协调器统一触发补偿，顺序可控 |
| 单点故障 | 无单点，事件总线高可用即可 | 协调器可能成为瓶颈或单点故障 |
| 适用场景 | 流程简单、服务数量少、团队对事件驱动熟悉 | 流程复杂、服务数量多、需要严格监控和治理 |
3.4 模型选择建议
避坑指南：不要因为“编排模型看起来更酷”而盲目选择。在涉及 5 个以上服务、存在复杂条件分支或需要严格审计追踪的场景中，编排模型的事件流会变得难以追踪和调试，此时协调模型是更稳妥的选择。
在实际项目中，可以参考以下决策路径：
- 优先选择编排模型：当 Saga 步骤少于 4 个，服务间依赖简单，且团队已经具备事件驱动架构经验时。编排模型能减少中心化组件的开发和运维成本。
- 优先选择协调模型：当 Saga 步骤超过 5 个，存在条件分支（如根据库存结果决定支付方式），或业务要求对每一步进行精确监控和重试时。协调模型通过状态机实现，流程清晰可控。
- 混合模型：在大型系统中，可以将一个复杂的 Saga 拆分为多个子 Saga，子 Saga 内部使用协调模型，子 Saga 之间通过事件进行编排。
实战要点：无论选择哪种模型，都必须为每个参与服务定义清晰的补偿接口（Compensation Interface）。在协调模型中，补偿接口由协调器调用；在编排模型中，补偿接口由服务监听失败事件后自行调用。补偿接口必须是幂等的，以应对网络重试和消息重复消费。