微服务火了十年，Saga 几乎成了分布式事务的标准答案。但 2026 年，越来越多的架构师开始重新审视这个模式。
Saga 解决什么问题
单体时代，数据库事务（ACID）天然保证一致性。拆成微服务后，一个业务操作可能跨越多个服务和数据库——没有全局事务了。
Saga 的思路：把一个大事务拆成多个本地事务，每个本地事务有对应的补偿操作。失败了就逆序执行补偿。
订单服务 (创建订单) → 库存服务 (扣库存) → 支付服务 (扣款)
↓ ↓ ↓
(取消订单) ←──────── (回滚库存) ←────── (退款)
Saga 的问题
用着用着就会发现几个坑：
1. 补偿逻辑不总是可行。 发出去的短信能撤回吗？送出去的优惠券能收回吗？很多业务操作是不可逆的。
2. 复杂度爆炸。 N 个服务的 Saga，失败场景的组合是指数级的。测试覆盖几乎没办法做全。
3. 中间状态暴露给用户。 订单创建了但库存还没扣，用户看到的是半成品——然后一刷新，订单没了。
4. 成为技术债放大器。 Saga 把业务逻辑跟协调逻辑耦合在一起。业务一变，补偿逻辑也得跟着改，而且是连锁反应。
2026 年的新思路：动态一致性边界
AxonIQ 提出了一个概念叫 Dynamic Consistency Boundaries（DCB）。
核心理念：不要在设计阶段就把数据归属定死。 传统领域驱动设计的 Aggregate 在定义的那一刻就固化了对业务的理解——而业务是会变的。
DCB 的思路是： - 通过事件流统一管理状态变化 - 一致性规则由「标签」动态定义，而非编译时确定 - 需要一致性时再决定边界，而不是提前切分
| 维度 | Saga | DCB |
|---|---|---|
| 数据边界 | 编译时固化 | 运行时动态 |
| 补偿复杂度 | 高（指数级组合） | 低（事件流天然可追溯） |
| 业务变更成本 | 高（改协调逻辑） | 低（改标签规则） |
| 中间状态 | 用户可见 | 事件流隔离 |
不是说 Saga 就死了
Saga 在一些场景下仍然合适： - 服务数量少、流程简单（2-3 个步骤） - 补偿操作清晰且可靠（比如纯金融场景） - 团队对 Saga 框架已经很熟悉
但在复杂业务流程中，如果你发现 Saga 越写越痛苦——那不是你用得不好，是这个模式本身就有天花板。
2026 年，把「需要 Saga」当成一个 code smell 来看待，可能会让你少走很多弯路。
参考来源：
评论
评论已关闭。