《微服务架构设计模式》读书笔记 | 第4章 使用Saga管理事务 #yyds干货盘点#

Posted 2021-12-28 多氯环己烷

@[TOC](第4章 使用Saga管理事务)

---

前言

传统的分布式事务管理方法对于现代应用程序来说不是一个好的选择，跨服务的操作必须使用所谓的Saga（一种消息驱动的本地事务序列）来维护数据一致性，而不是ACID事务（原子性、一致性、隔离性和持久性）。

Saga的一个挑战在于只满足ACD（原子性、一致性和持久性）特性，而缺乏ACID事务的隔离性。因此应用程序必须使用所谓的对策（countermeasure），找到办法来防止或减少由于缺少隔离而导致的并发异常

这是一本关于微服务架构设计方面的书，这是本人阅读的学习笔记。以下对一些符号做些说明：

（）为补充，一般是书本里的内容；
[]符号为笔者笔注；

---

1. 微服务架构下的事务管理

1.1 分布式事务的挑战

分布式事务管理的事实标准是XA标准：

• XA采用两阶段提交来保证事务中所有参与方同时完成提交，或者失败时同时回滚；
• 应用程序中的整个技术栈需要满足XA标准（包括数据库、消息代理、数据库驱动、消息API等）；

其存在的挑战有：

• 许多新技术，包括NoSQL数据库（如MongoDB和Cassandra），不支持XA标准的分布式事务；
• 一些流行的消息代理（如RabbitMQ和Apache Kafka）不支持分布式事务；
• 分布式事务本质都是同步进程间通信，会降低分布式系统的可用性；

1.2 一个Saga的示例

当本地事务完成时，服务会发布消息。然后，此消息将触发Saga中的下一个步骤。

1.3 Saga使用补偿事务来回滚所作出的改变

需要注意不是所有步骤都需要事务补偿，如只读步骤、当某步骤之后的操作总会成功时等。

2. Saga的协调模式

2.1 两种Saga协调模式

• 协同式（choreography）：把Saga的决策和执行顺序逻辑分布在Sage的每一个参与方中，它们通过交换事件的方式来进行沟通；
• 编排式（orchestration）：【推荐】把Saga的决策和执行顺序逻辑集中在一个Saga编排器类中。Saga编排器发出命令式消息给各个Saga参与方，指定这些参与方服务完成具体操作（本地事务）；

2.2 实现协同式的Create Order Saga

图解：

1. Order Service创建一个处于APPROVAL_PENDING状态的Order并发布OrderCreated事件；
2. Consumer Service消费OrderCreated事件，验证消费者是否可以下订单，并发布ConsumerVerified事件；
3. Kitchen Service消费OrderCreated事件，验证Order，创建一个处于CREATE_PENDING状态的后厨工单Ticket，并发布TicketCreated事件；
4. Accounting Service消费OrderCreated事件并创建一个处于PENDING状态的CreditCardAuthorization；
5. Accounting Service消费TicketCreated和ConsumerVerified事件，向消费者的信用卡收费，并发布CreditCardAuthorized事件；
   • 如果失败，则发布CreditCardAuthorizationFailed事件；
6. Kitchen Service消费CreditCardAuthorized事件，将Ticket的状态更改为AWAITING_ACCEPTANCE；
   • 如果失败，则消费CreditCardAuthorizationFailed事件，将Ticket的状态更改为REJECTED；
7. Order Service接收CreditCardAuthorized事件，将Order的状态改为APPROVED，并发布OrderApproved事件；
   • 如果失败，则消费CreditCardAuthorizationFailed事件，将Order的状态更改为REJECTED；

2.3 协同式Sage服务间通信相关的问题

在实现基于协同的Saga时，需要考虑一些与服务间通信相关的问题：

• 确保Saga参与方将更新其本地数据库和发布事件作为数据库事务的一部分；
  • 例如：在Create Order Saga中，Kitchen Service接受CreditCarAuthorized事件，创建Ticket，发布到TicketCreated事件；数据库的更新和事件发布必须是原子的；
  • 解决：Saga参与方必须使用事务性消息；
• 确保Saga参与方必须能够将接受到的每个事件映射到自己的数据上；
  • 例如：当Order Service收到CreditCardAuthorized事件时，它必须能够查找相应的Order；
  • 解决：让Saga参与方发布包含相关性ID的事件；

2.4 协同式Sage的优缺点

好处：

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

弊端：

• 更难理解：协调式Saga的逻辑分布在每个服务的实现中；开发人员有时很难理解特定Saga是如何工作；
• 服务之间的循环依赖关系：Saga参与方订阅彼此事件，通常会导致循环依赖关系；
• 紧耦合的风险：每个Saga参与方都需要订阅所有影响它们的事件；

2.5 实现编排式的Create Order Saga

图解：

Order Service首先创建（实例化）一个Order对象和一个Create Order Saga编排器对象，一切正常后流程如下：

1. Saga编排器向Consumer Service发送Verify Consumer命令；
2. Consumer Service回复Consumer Verified消息；
3. Saga编排器向Kitchen Service发送Create Ticket命令；
4. Kitchen Service回复Ticket Created消息；
5. Saga编排器向Accounting Service发送Authorize Card消息；
6. Accounting Service使用Card Authorized消息回复；
7. Saga编排器向Kitchen Service发送Approve Ticket命令；
8. Saga编排器向Order Service发送Approve Ordere命令（命令式消息）；

2.6 把Saga编排器视为一个状态机

将Saga建模成状态机非常有用，因为它描述了所有可能的场景（可能成功也可能失败）。

• Verifying Consumer：初始状态。当处于此状态时，该Saga正在等待Consumer Service验证消费者是否可以下订单；
• Creating Ticket：该Saga正在等待对Create Ticket命令的回复；
• Authorizing Card：等待Authorizing Service授权消费者的信用卡；
• Order Approved：最终状态，表示该Saga已成功完成；
• Order Rejected：最终状态，表示Order被其中一个参与方拒绝；

2.7 编排式Saga的优缺点

好处：

• 更简单的依赖：不会引入循环依赖关系；
• 较少的耦合：每个服务实现供编排器调用的API，因此它不需要知道Saga参与方发布的事件；
• 改善关注点隔离，简化业务逻辑：Saga的协调逻辑本地化在Saga编排器中；领域对象更简单，并且不需要了解它们参与的Saga；

弊端：

• 在编排器中存在集中过多业务逻辑的风险；
  • 解决办法：可以通过设计只负责排序的编排器来避免此问题，并且不包含任何其他业务逻辑；

3. 解决隔离问题

3.1 Saga只满足ACD

• 原子性：Saga实现确保执行所有事务或撤销所有更改；
• 一致性：服务内的参照完整性（referential integrity）由本地数据库处理；服务之间的参照完整性由服务处理；
• 持久性：由本地数据库处理；

3.2 缺乏隔离导致的问题

• 丢失更新：一个Saga没有读取更新，而是直接覆盖了另一个Saga所做的更改；
• 脏读：一个事务或一个Saga读取了尚未完成的Saga所做的更新；
• 模糊或不可重复读：一个Saga的两个不同步骤读取相同的数据却获得了不同的结果，因为另一个Saga已经进行了更新；

3.3 Saga的结构模型术语

• 可补偿性事务：可以使用补偿事务回滚的事务；
• 关键性事务：Saga执行过程的关键节点。如果关键性事务成功，则Saga将一直运行到完成。关键性事务不见得是一个可补偿性事务，或者可重复性事务。但是它可以是最后一个可补偿的事务或第一个可重复的事务；
• 可重复性事务：在关键性事务之后的事务，保证成功；

3.4 解决隔离问题的对策

• 语义锁：应用程序级的锁；
  • Saga的可补偿性事务会在其创建或更新的任何记录中设置标志，该标志表示该记录未提交且可能发生失败；
  • 如：在可补偿性事务执行时给操作对象添加上*_PENDING状态，以告诉该对象的其他Saga，该对象当前正处于一个Saga的处理过程中；
• 交换式更新：把更新操作设计成可以按任何顺序执行；
  • 将更新操作设计为可交换的；
  • 如：账户的debit()和credit()操作是可交换的；
• 悲观视图：重新排序Saga的步骤，以最大限度地降低业务风险；
  • 重新排序Saga的步骤，以最大限度地降低由于脏读而导致的业务风险；
• 重读值：通过重写数据来防止脏写，以在覆盖数据之前验证它是否保持不变；
  • 使用此对策的Saga在更新之前重新读取记录，验证它是否未更改，然后根性记录；如果记录已更改，则Saga将中止并可能重新启动。此对策是乐观脱机锁模式的一种形式；
  • 如：可以用来处理Order在批准过程中被取消的情况；
• 版本文件：将更新记录下来，以便可以对它们重新排序；
  • 记录对数据执行的操作，以便可以对它们进行重新排序；
  • 如：当Accounting Service先收到Cancel Authorization请求，再收到Authorize Card请求时，它会注意到它已经收到Cancel Authorization请求并跳过授权信用卡；
• 业务风险评级（by value）：使用每个请求的业务风险来动态选择并发机制；
  • 使用此对策的应用程序使用每个请求的属性来决定使用Saga和分布式事务；

4. Order Service和Create Order Saga的设计

4.1 Order Service的设计及其Saga

• 服务的业务逻辑由传统的业务逻辑类组成，与传统业务一样，业务核心由OrderService、Order和OrderRepository类实现；
• 还有一些Saga编排器类，包括CreateOrderSaga类，它可以编排Create Order Saga；
• Order Service即是一个Saga编排器，也是一个Saga参与方；Order Service参与它自己的Saga，它有一个OrderCommandHandlers适配器类，该适配器类通过调用Order Service来处理命令消息；

4.2 OrderService类

OrderService的UML类图：

OrderService类及其createOrder()方法：

4.3 Create Order Saga的实现

OrderService的Saga UML类图：

• CreateOrderSaga：定义Saga状态机的单例类；它调用CreateOrderSagaState来创建命令式消息，并使用Saga参与方代理类（如KitchenServiceProxy）指定的消息通道将它们发送给参与方；
• CreateOrderSagaState：一个Saga的持久化状态，用于创建命令式消息；
• Saga参与方的代理类（如KitchenServiceProxy）：每个代理类定义一个Saga参与方的消息API，它由命令通道、命令式消息和回复类型组成。

4.4 CreateOrderSaga编排器

4.5 CreateOrderSagaState类

4.6 KitchenServiceProxy类

4.7 Eventuate Tram Saga框架

Eventuate Tram Saga框架：

OrderService创建Create Order Saga实例时的事件序列：

当SagaManager收到来自Saga参与方的回复消息时的事件序列：

4.8 OrderCommandHandlers类

OrderCommandHandlers UML类图：

Order Service的命令处理程序：

4.9 OrderServiceConfiguration类

5. 本章小结

• 某些系统操作需要更新分散在多个服务中的数据。传统的基于XA / 2PC的分布式事务不适合现代应用。更好的方法是使用Saga模式。Saga是使用消息机制协调的一组本地事务序列。每个本地事务都在单个服务中更新数据。由于每个本地事务都会提交更改，因此如果由于违反业务规则而导致Saga必须回滚，则必须执行补偿事务以显式撤销更改；
• 可以使用协同或编排协调Saga的步骤。在基于协同的Saga中，本地事务发布触发其他参与方执行本地事务的事件。在基于编排的Saga中，集中式Saga编排器向参与方发送命令式消息，告诉它们执行本地事务。可以通过将Saga编排器建模为状态机来简化开发和测试，简单的Saga可以使用协同式，但编排式通常是复杂Saga的更好选择；
• 设计基于Saga的业务逻辑可能具有挑战性，因为与ACID事务不同，Saga不是彼此孤立的。你必须经常使用各种对策，即防止ACD事务模型引起的并发异常的设计策略。应用甚至可能需要使用锁来简化逻辑，即使这样会导致死锁。

---

最后

::: hljs-center

新人制作，如有错误，欢迎指出，感激不尽！

:::

::: hljs-center

欢迎关注公众号，会分享一些更日常的东西！

:::

::: hljs-center

如需转载，请标注出处！

:::

::: hljs-center

:::