数据：Saga模式

背景

你已经采用了每服务每数据库模式。每个服务都有独自的数据库。然而，一些业务事务跨越了多个服务，因此你需要一个机制确保跨服务的数据一致性。比如，设想下你构建一个电商应用，客户拥有信用额度。应用程序必须确保一个新订单没有超出客户的信用额度。由于订单和顾客数据在不同的数据库，应用程序无法简单的采用一个本地的ACID事务。

问题

怎么跨服务管理数据一致性？

限制

• 2PC不是个可选项

解决方案

用Saga来实现跨越多个服务的业务事务。Saga代表着一系列本地事务。每个本地事务更新数据库，发布消息或事件来触发Saga里的下一个本地事务。如果一个本地事务由于违反了业务规则而失败，Saga执行一系列补偿事务以撤回被前面事务产生的更改。

Saga模式代替两阶段提交

有两种方式可以协调Saga：

• Choreography - 每个本地事务发起领域事件，触发其他服务里的本地事务
• Orchestration - Orchestrator 对象告诉参与者执行哪个本地事务

示例：基于Choreography的Saga

Choreography

电商应用采用choreography为基础的方法创建订单，将按照以下步骤：

1. Order Service创建一个pending状态的订单，并发布OrderCreated事件
2. Customer Service收到事件，尝试验证订单的信用。它发起Credit Reserved事件或者Credit Limit Exceeded事件
3. Order Service收到事件，将订单状态修改为approved或者cancelled

示例：基于Orchestration的Saga

Orchestration

电商应用采用orchestration为基础的方法创建订单，将按照以下步骤：

1. Order Service创建一个pending状态的订单，并创建一个CreateOrderSaga
2. CreateOrderSaga往Customer Service发送ReserveCredit命令
3. Customer Service尝试验证订单信用，并发送一个回复
4. CreateOrderSaga接收回复，往Order Service发送ApproveOrder或者RejectOrder命令
5. Order Service修改订单的状态为approved或者cancelled

结果

这个模式有如下优势：

• 允许应用跨越多个服务管理市局一致性，而不使用分布式事务

这个解决方案有如下弊端：

• 编程模型更加复杂。比如，开发人员必须设计补偿事务，明确撤回Saga早些时候做出的更改。

还有如下问题需要解决：

• 为了可靠，服务必须原子的更新数据库和发布事件。不能使用跨越数据库和消息队列的传统分布式事务的机制。相反，必须采用如下列出的一种模式。

相关模式

• 每服务每数据库产生了对这个模式的需求
• 如下模式是原子性的更新状态和发布事件的方法：
  • Event sourcing
  • Application events
  • Database triggers
  • Transaction log tailing

参见

• 作者的书 Microservices patterns 从更多细节介绍了这个模式. 这本书的 示例应用 采用 Eventuate Tram Sagas framework 来实现了Saga
• 作者的 MicroXchg 2018 presentation (幻灯片和视频)
• 以下例子用不同方式实现了客户和订单的例子：
  • Choreography-based saga，服务用Eventuate Tram framework发布领域事件
  • Orchestration-based saga，Order Service使用 Eventuate Tram Sagas framework 实现的orchestrator Saga
  • Choreography and event sourcing-based saga，服务使用 Eventuate event sourcing framework 发布领域事件
  • 作者的两篇InfoQ文章 Developing Transactional Microservices Using Aggregates, Event Sourcing and CQRS 介绍了如何使用 event sourcing 来实现 choreography Saga