Saga模式：解决分布式服务交互难题
1. 问题提出
在处理服务请求时，事务性服务模式能让服务可靠地处理请求，但它只能解决部分问题。以电商场景中的订单服务为例，前端向订单服务发送订单，订单服务在处理请求的内部事务中，需要与内部的计费服务和外部的供应商系统进行交互。具体流程如下：
1. 前端发送订单请求（步骤1.0）。
2. 订单服务接收消息（步骤2.1），开始处理订单（步骤2.2），向供应商系统下订单（步骤2.3），向计费服务请求计费（步骤2.4），最后提交事务（步骤2.5）。
这里存在两个主要问题：
-事务回滚问题：如果订单服务在步骤2.5不提交内部事务而是中止，会产生什么影响？
-服务承诺问题：订单服务如何从其他服务获得承诺，以便继续工作？例如，在向客户确认订单之前，需要获得供应商关于所订物品已确保供应的确认。
一种明显的解决方案是将订单服务的内部事务扩展到其他服务，形成分布式事务。使用分布式事务时，订单服务需将计费服务和供应商系统的调用作为单个事务的一部分，如果所有服务都同意提交，整个事务才会提交完成。然而，这种方法存在诸多问题：
-服务操作不确定性：无法对其他服务的操作方式做出假设，尤其是非自有服务。例如，供应商可能需要高级经理授权才能完成交易，等待过程中会持有内部资源锁，可能影响业务。
-长事务问题：服务间交互越复杂，原子事务的弊端越明显。大量消息在服务间来回传递会增加延迟和失败的可能性，但交互过少又不现实，因为服务间需要互操作性。
