Saga模式下微服务补偿事件监听及事件命名咨询

一、Shipment失败后的事件流转选择 #

这得看你采用的是编排式Saga还是协调式Saga：

• 如果是无中心协调者的编排式：
  建议Inventory Service执行库存回滚后，抛出Stock Rollback Completed这类补偿完成事件，而非Stock Update Failed（回滚是主动执行的补偿动作，不属于失败范畴）。然后Order Service监听这个补偿完成事件，再执行自身的补偿逻辑（比如取消订单）。
  要是让Order直接监听Shipment Failed，虽然能跑通流程，但会让Order和多个服务的失败事件强绑定——以后新增Payment Service，Order又得额外监听Payment的失败事件，耦合性太高，扩展性差。
• 如果是有中心协调者的协调式：
  Shipment抛出Shipment Failed后，由协调者主动触发Inventory的回滚逻辑；Inventory完成回滚后给协调者反馈，再由协调者通知Order执行补偿，这种场景下Inventory不需要额外抛出事件。

二、故障发生时的事件抛出策略 #

核心原则是解耦优先：

• 编排式Saga里，故障服务抛出对应的失败事件（比如Shipment Failed），每个需要补偿的服务监听该事件，执行完自身补偿动作后，抛出专属的补偿完成事件，下一个服务再监听这个补偿完成事件启动自己的补偿流程。
  举个实际流程例子：Shipment抛Shipment Failed → Inventory监听后回滚库存，抛Stock Rollback Completed → Order监听后取消订单，抛Order Cancelled。这样每个服务只关心自己的触发事件，新增或修改服务时不会影响其他服务的监听逻辑。
• 不要让所有服务都直接监听故障服务的失败事件——这种方式仅适合极简单的短链路场景，一旦链路变长或新增服务，维护成本会急剧上升。

三、事件命名规范建议 #

给你几个实用的命名原则：

• 结构清晰：采用[服务/资源]_[动作]_[状态]的格式，比如：
  • 正常流程事件：Order_Created、Inventory_Reserved、Shipment_Initiated
  • 故障/补偿事件：Shipment_Failed、Stock_Rollback_Initiated、Stock_Rollback_Completed、Order_Cancelled
• 用事实性表述：事件是对已发生事实的记录，所以用过去式或被动式，比如Inventory_Reserved（库存已预留），别用Reserve_Inventory（这是指令，不是事件）。
• 区分故障与补偿：故障事件要明确是“动作失败”（比如Shipment_Failed），补偿事件要明确是“补偿完成”（比如Stock_Rollback_Completed），别用模糊的Inventory_Updated这类名字，谁也没法直接判断是正常更新还是回滚操作。
• 避免歧义：比如别用Stock_Failed，要明确写成Shipment_Failed或Stock_Rollback_Failed，让其他服务一眼就能理解事件的具体含义。

内容的提问来源于stack exchange，提问作者Arabaaa