微服务框架下的事务--Saga介绍

Saga为分布式事务解决方案的一种，常用于微服务框架。通过使用异步消息来协调一系列本地事务，从而维护多个服务之间的数据一致性 。Saga的一个挑战在于只满足 ACD (原子性、一致性和持久性)特性，而缺乏传统 ACID 事务的隔离性 。Saga的实现方案有两种：

• 协同式 (choreography)
• 编排式 (orchestration)

协同式 (choreography) :

把 Saga 的决策和执行顺序逻辑分布在 Saga 的每一个参与方中，它们通过交换事件的方式来进行沟通 。

协同式Saga

协同式的 Saga优点:

• 简单: 服务在创建、更新或删除业务对象时发布事件。
• 松耦合: 参与方订阅事件并且彼此之间不会因此而产生耦合 。

协同式的 Saga缺点:

• 这种方式如果涉及比较多的业务参与方，则比较容易失控。各业务参与方可随意监听对方的消息，以至于最后没人知道到底有哪些系统在监听哪些消息。更悲催的是，这个模式还可能产生环形监听，也就是两个业务方相互监听对方所产生的事件。
• 更难理解: 与编排式不同，代码中没有一个单 一 地方定义了 Saga。 相反，协调式Saga 的逻辑分布在每个服务的实现中 。 因此，开发人员有时很难理解特定的 Saga是如何工作的 。
• 服务之间的循环依赖关系 : Saga 参与方订阅彼 此的 事件，这通常会导致循环依赖关系 。 例如，如果仔细检查图 4-4, 你将看到存在循环依赖关系，例如 OrderService---+Accounting Service-Order Service。 虽然这并不 一定是个 问题，但循环依赖性被认为是一种不好的设计风格 。

协同式的 Saga适用场景

协同式的 Saga比较适合整个分布式事务只有2-4个步骤的情形。

编排式 (orchestration):

把 Saga 的决策和执行顺序逻辑集中在 一个 Saga 编排器类中 。Saga编排器发出命令式消息给各个 Saga参与方，指示这些参与方服务完成具体操作(本地事务) 。

编排式Saga

编排式Saga优点

• 更简单的依赖关系: 编排的一个好处是它不会引入循环依赖关系 。 Saga 编排 器调用Saga 参与方，但参与方不 会调用编排器 。 因此，编排器依赖于参与方，但反之则不然，因此没有循环依赖 。
• 减少了业务参与方的复杂度:将分布式事务的管理交由协调中心管理，协调中心对整个逻辑非常清楚。这些业务参与方不再需要监听不同的消息，只是需要响应命令并回复消息。
• 简化业务逻辑: Saga 的协调逻 辑本地化在 Saga 编排器中 。 领域对象更简单，并且不需要了解它们参与的 Saga。 例如，当使用编排式 Saga 时， Order类不知道任何 Saga, 因此它具有更简单的状态机模型 。 在执行 Create OrderSaga期间，它直接从 APPROVAL_PEND工NG状态转换到 APPROVED状态。 Order类没有与 Saga 的步骤相对应的任何中间状态 。 因此，业务更加简单

编排式缺点

需要维护协调中心，而这个协调中心并不属于任何业务方。