跨服务幂等补偿编排（Idempotent Compensation Orchestration）—— 构建真正可恢复的业务流程

前言：为什么“补偿”比“幂等”更难？

• 幂等保证不会重复执行
• 补偿保证失败后能恢复
• 分布式环境中，补偿 = 真正的一致性挑战

为什么跨服务需要补偿？

• 服务 A 成功
• 服务 B 成功
• 服务 C 失败
  → 整体流程如何回滚？如何自愈？谁来 orchestrate？

补偿不是“逆向操作”，而是“可逆行为设计”

• 不同业务行为不是对称的
• 例如：扣钱和退款不是可逆
• 必须设计“补偿行为 / 恢复行为”

跨服务补偿的三种模式

1. Saga Pattern（编排式补偿）
2. Choreography（事件式补偿）
3. 状态机补偿（State Machine Based）

补偿执行引擎的核心能力

• 执行日志（Execution Log）
• 幂等记录（Idempotent Record）
• 状态回溯（State Snapshot）
• 补偿序列（Compensation Chain）
• 超时与死信补偿
• 部分补偿（Partial Recovery）

补偿失败怎么办？（高级难点）

• 多次补偿失败 → 人工介入
• 条件满足才可补偿
• 组合补偿（多个服务需同进同退）
• 黑名单补偿（不可补偿项）

补偿 DSL（Compensation DSL）

• 定义动作
• 定义依赖
• 失败策略
• 重试策略
• 完整补偿链声明

企业级落地方案

• 通过 Scheduler + Event Bus + Saga Orchestrator 实现
• 补偿任务持久化
• 可视化补偿状态
• 自动补偿 + 手动强制补偿

案例：跨服务订单流程的补偿编排

• 创建订单 → 扣库存 → 扣余额 → 发券 → 最后一步失败

• Saga 补偿执行：

  • 退款
  • 返库存
  • 回滚订单状态
  • 撤回赠券

• 最终系统成功恢复一致性

总结