Saga模式对比：Golang编排与协同选择

本文深入剖析了Go语言中Saga模式的两种核心编排方式——Orchestration与Choreography的本质差异与落地陷阱：前者依赖中央协调器（SagaCoordinator）实现强一致性、可追踪、易调试的事务流程，强调状态持久化与断点续跑能力，推荐使用Temporal等成熟SDK而非手写；后者以事件驱动实现松耦合协作，但必须严守“本地落库+幂等补偿+全局saga_id关联”三原则，否则极易陷入事件丢失难追溯、补偿失控的困境；文章指出性能瓶颈、可观测性设计及责任边界划分才是选型关键——Saga不是技术银弹，真正决定成败的是团队间对失败传播成本的清晰共识与契约约定。

Go 里 Saga 模式该用 Orchestration 还是 Choreography？看失败恢复路径

Orchestration 更适合需要强一致性、可追踪、易调试的业务流程；Choreography 更适合高内聚、低耦合、事件驱动的松散服务协作。选错会导致补偿逻辑失控或事务链路不可观测。

orchestration 的核心：必须有一个中央协调器 SagaCoordinator

它不是“调度器”，而是状态机 + 补偿指令分发器。没有它，Compensate() 就会变成无头苍蝇。

• SagaCoordinator 必须持久化每一步执行状态（比如用 pgx 存 saga_id、step、status），否则重试时不知道该从哪补
• 每个子服务只和协调器通信，不感知其他服务——这是避免循环依赖的关键
• 推荐用 go.temporal.io/sdk 而非手写：它的 ExecuteActivity + ContinueAsNew 天然支持断点续跑，手写容易漏掉幂等或超时重试

choreography 的陷阱：事件丢失 ≠ 事务失败，但开发者常当成一回事

用 github.com/segmentio/kafka-go 或 redis streams 发布事件时，90% 的问题出在“以为发出去就成功了”。

• 发布事件前必须先本地落库（比如写入 saga_events 表，status = 'pending'），再异步投递；投递成功后才更新为 'published'
• 消费者必须实现至少一次语义（AtLeastOnce），且 Compensate() 本身要幂等——因为同一条事件可能被消费两次
• 没有全局 saga_id 关联所有事件？查故障时你会在日志里找不到上下游关系

性能与可观测性差异：Orchestration 写多读少，Choreography 读多写少

Orchestration 的瓶颈在协调器单点写入（如 PostgreSQL update），Choreography 的瓶颈在事件广播延迟和消费者堆积。

• Orchestration 下，GetSagaState(ctx, sagaID) 是高频查询，建议加 Redis 缓存，但注意缓存与 DB 状态一致（用 Cache-Aside + 延迟双删）
• Choreography 下，每个服务都要监听多个 topic/stream，别把所有 saga 事件塞进一个 order-events topic——按业务域拆分，否则消费者无法独立扩缩容
• 两者都必须打结构化日志：至少含 saga_id、step_name、attempt、error，否则 jaeger 链路里看不到补偿跳转

最常被忽略的是：Saga 不是银弹。跨数据库、跨网络、跨团队的服务，用 Choreography 很难对齐补偿语义；而纯内部微服务链路，硬套 Orchestration 又会把简单流程搞重。关键不在模式本身，而在谁承担失败传播成本——这个责任边界，代码写不出来，得靠上下游一起签清楚。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。