4. Saga模式概述：定义与两种协调方式

Saga模式是分布式事务领域最成熟的补偿型解决方案之一。它通过将一个大事务拆分为一系列本地事务（每个本地事务对应一个服务操作），并为每个本地事务定义对应的补偿操作，从而在保证数据最终一致性的同时，避免使用传统XA协议的全局锁和两阶段提交。

4.1 Saga模式的核心定义

Saga模式由Hector Garcia-Molina和Kenneth Salem在1987年提出，其核心思想可概括为：

特性	说明
事务粒度	每个参与者只执行本地数据库事务，不涉及全局锁
一致性模型	最终一致性（Eventual Consistency），非强一致性
隔离性	标准Saga不提供全局隔离，需通过语义锁或幂等设计补偿
适用场景	跨服务长事务、微服务编排、异步消息驱动的业务流程
失败处理	通过补偿事务回滚，而非全局回滚

4.2 两种协调方式：Choreography vs Orchestration

Saga模式根据协调逻辑的归属，分为编排（Choreography）和编舞（Orchestration）两种实现方式。两者在架构风格、控制流和运维复杂度上有本质区别。

4.2.1 编排（Choreography）—— 去中心化的事件驱动

编排模式下，每个服务在完成本地事务后，通过发布事件来触发下一个服务的操作。没有中央协调器，所有服务通过事件总线（如Kafka、RabbitMQ）进行异步通信。

• 工作流：服务A完成 → 发布事件 → 服务B监听并执行 → 发布事件 → 服务C执行
• 补偿触发：服务B失败 → 发布失败事件 → 服务A监听并执行补偿操作
• 优点：去中心化、高可扩展性、服务间解耦
• 缺点：业务流程隐式分布在事件处理逻辑中，调试和监控困难

4.2.2 编舞（Orchestration）—— 中央协调器驱动

编舞模式下，引入一个Saga协调器（Orchestrator）作为中央控制器，负责向各个参与者发送指令、接收响应，并在失败时触发补偿流程。协调器通常以状态机或工作流引擎的形式实现。

• 工作流：协调器 → 调用服务A → 收到响应 → 调用服务B → 收到响应 → 调用服务C
• 补偿触发：服务B失败 → 协调器主动调用服务A的补偿接口
• 优点：业务流程显式集中、易于监控和调试、补偿逻辑清晰
• 缺点：协调器成为单点瓶颈、服务与协调器耦合增加

4.3 两种协调方式的对比

对比维度	编排（Choreography）	编舞（Orchestration）
控制流	隐式，分散在各服务的事件处理器中	显式，集中在协调器状态机中
服务耦合	低耦合，仅依赖事件结构	中等耦合，服务需实现协调器定义的接口
可观测性	困难，需追踪跨服务事件链	容易，协调器日志包含完整执行轨迹
补偿复杂度	高，需在多个服务中维护补偿事件逻辑	低，补偿逻辑集中在协调器
单点风险	无单点	协调器可能成为瓶颈或单点故障
扩展性	高，服务可独立扩缩	中等，协调器需额外扩展策略
典型实现	Axon Framework + Kafka	Camunda、Temporal、Eventuate Tram

4.4 选择建议