4. Saga事务边界定义：事务边界的识别原则、微服务中如何划定Saga边界
Saga事务边界是分布式系统中局部事务的起止范围。边界定义错误会导致补偿逻辑混乱、数据不一致或死锁。本节从识别原则和微服务划定方法两个维度展开。
4.1 事务边界的识别原则
正确的Saga边界应遵循以下五项核心原则：
| 原则 | 说明 | 反例 |
|---|---|---|
| 1. 原子性边界 | 一组必须全部成功或全部回滚的操作应划入同一个Saga | 订单创建与库存扣减分属不同Saga，导致超卖 |
| 2. 服务自治边界 | 边界不应跨越微服务的内部模块，每个服务只暴露一个Saga参与接口 | 在用户服务内部将“扣积分”和“发优惠券”拆成两个Saga步骤 |
| 3. 补偿可行性边界 | 边界内的每个步骤必须有可执行的补偿操作 | “发送邮件”作为Saga步骤，但邮件发送后无法撤回 |
| 4. 幂等性边界 | 边界内的每个操作（含补偿）必须支持幂等重试 | 扣减余额接口未做幂等，重试导致重复扣款 |
| 5. 隔离性边界 | 边界应尽量短，减少未提交数据的暴露窗口 | 一个Saga包含10个步骤，中间状态长时间可见 |
实践建议：在识别边界时，先列出所有需要保证原子性的业务操作，再按服务归属分组，最后检查每组是否满足补偿可行性和幂等性要求。不满足的组需要进一步拆分或引入补偿适配层。
4.2 微服务中划定Saga边界的步骤
在微服务架构中，划定Saga边界通常遵循以下四步流程：
- 业务场景分解：将端到端业务流程拆解为不可再分的业务原子操作。
- 服务归属映射：将每个原子操作映射到对应的微服务，标记跨服务调用点。
- 补偿策略设计：为每个跨服务操作设计补偿逻辑，确认补偿的可行性。
- 边界收敛与合并：将相邻且属于同一服务、同一事务语义的操作合并为一个Saga步骤。
案例：以“电商下单”流程为例，原始操作包括：创建订单（订单服务）、扣减库存（库存服务）、扣减余额（账户服务）、发送通知（通知服务）。按上述步骤划定后，Saga边界为：
[创建订单 → 扣减库存 → 扣减余额]，发送通知因无法补偿被排除在Saga之外，改为异步最终通知。
4.3 常见边界划定模式
根据业务场景的不同，微服务中常见的Saga边界划定模式有三种：
| 模式 | 适用场景 | 边界特征 | 示例 |
|---|---|---|---|
| 链式Saga | 严格顺序执行的业务流程 | 步骤线性排列，前一步成功才能执行下一步 | 下单 → 支付 → 发货 |
| 扇出Saga | 一个主操作依赖多个子操作 | 主步骤后并行执行多个子步骤，全部成功才算成功 | 创建订单后，同时扣库存、扣余额、扣优惠券 |
| 混合Saga | 复杂业务流程，包含串行和并行 | 部分步骤串行，部分步骤并行，边界内包含子Saga | 先校验用户（串行），再并行扣库存+扣余额，最后串行发货 |
边界划定陷阱：不要将“查询类操作”或“无状态校验”划入Saga边界。这些操作不改变数据状态，不需要补偿，划入边界只会增加Saga协调器的负担和事务时长。
4.4 边界定义的最佳实践
- 每个Saga步骤对应一个微服务的一个接口，避免在一个步骤中调用同一服务的多个接口。
- 边界内步骤数控制在3~7个，超过7个应考虑拆分为子Saga或调整业务设计。
- 为每个边界定义明确的超时阈值，超时后触发补偿或人工介入流程。
- 使用边界版本号，当服务接口变更时，边界定义随之升级，避免旧Saga实例执行错误的补偿逻辑。
- 边界定义文档化，包含：步骤ID、服务名、接口名、补偿接口名、幂等键字段、超时时间、重试策略。
4.5 边界与鉴权拦截的关联
Saga边界定义直接影响鉴权拦截策略的设计：
- 边界入口鉴权：在Saga协调器入口处进行统一鉴权，确保发起Saga的调用方有权限执行整个事务链。
- 边界内步骤鉴权：每个步骤对应的微服务接口仍需独立鉴权，防止绕过协调器直接调用。
- 补偿操作鉴权：补偿接口必须与正向接口使用相同的鉴权机制，避免补偿时因权限不足而失败。
- 边界上下文传递：鉴权令牌（Token）必须在Saga边界内所有步骤间透传，确保每个步骤都能验证调用方身份。
关键结论：Saga边界是分布式事务的“法律管辖范围”。边界定义得越清晰，鉴权拦截、补偿逻辑、幂等控制就越容易实现。反之，边界模糊会导致补偿遗漏、鉴权漏洞和数据不一致。建议在项目初期使用边界定义模板进行评审，将边界定义作为架构设计文档的必选项。