背景
你已经采用了每服务每数据库模式。每个服务都有独自的数据库。然而，一些业务事务跨越了多个服务，因此你需要一个机制确保跨服务的数据一致性。比如，设想下你构建一个电商应用，客户拥有信用额度。应用程序必须确保一个新订单没有超出客户的信用额度。由于订单和顾客数据在不同的数据库，应用程序无法简单的采用一个本地的ACID事务。
问题
怎么跨服务管理数据一致性？
限制
- 2PC不是个可选项
解决方案
用Saga来实现跨越多个服务的业务事务。Saga代表着一系列本地事务。每个本地事务更新数据库，发布消息或事件来触发Saga里的下一个本地事务。如果一个本地事务由于违反了业务规则而失败，Saga执行一系列补偿事务以撤回被前面事务产生的更改。
Saga模式代替两阶段提交
有两种方式可以协调Saga：
- Choreography - 每个本地事务发起领域事件，触发其他服务里的本地事务
- Orchestration - Orchestrator 对象告诉参与者执行哪个本地事务
示例：基于Choreography的Saga
Choreography
电商应用采用choreography为基础的方法创建订单，将按照以下步骤：
-
Order Service创建一个pending状态的订单，并发布OrderCreated事件 -
Customer Service收到事件，尝试验证订单的信用。它发起Credit Reserved事件或者Credit Limit Exceeded事件 -
Order Service收到事件，将订单状态修改为approved或者cancelled
示例：基于Orchestration的Saga
Orchestration
电商应用采用orchestration为基础的方法创建订单，将按照以下步骤：
-
Order Service创建一个pending状态的订单，并创建一个CreateOrderSaga -
CreateOrderSaga往Customer Service发送ReserveCredit命令 -
Customer Service尝试验证订单信用，并发送一个回复 -
CreateOrderSaga接收回复，往Order Service发送ApproveOrder或者RejectOrder命令 -
Order Service修改订单的状态为approved或者cancelled
结果
这个模式有如下优势：
- 允许应用跨越多个服务管理市局一致性，而不使用分布式事务
这个解决方案有如下弊端：
- 编程模型更加复杂。比如，开发人员必须设计补偿事务，明确撤回Saga早些时候做出的更改。
还有如下问题需要解决：
- 为了可靠，服务必须原子的更新数据库和发布事件。不能使用跨越数据库和消息队列的传统分布式事务的机制。相反，必须采用如下列出的一种模式。
相关模式
- 每服务每数据库产生了对这个模式的需求
- 如下模式是原子性的更新状态和发布事件的方法：
参见
- 作者的书 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
