架构模式: Saga
上下文
您已应用每服务数据库模式。每个服务都有自己的数据库。但是，某些业务事务跨越多个服务，因此您需要一种机制来确保服务之间的数据一致性。例如，假设您正在建立一个客户有信用额度的电子商务商店。申请必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中，因此应用程序不能简单地使用本地ACID事务。
问题
如何跨服务维护数据一致性？
要点
- 可以不选择2PC
结论
实现跨越多个服务的每个业务事务作为传奇。传奇是一系列本地交易。每个本地事务都更新数据库并发布消息或事件以触发saga中的下一个本地事务。如果本地事务因违反业务规则而失败，则saga会执行一系列补偿事务，以撤消先前本地事务所做的更改。
协调sage有两种方式：
- Choreography - 每个本地事务发布触发其他服务中的本地事务的域事件
- Orchestration - 一个orchestrator（上帝对象）告诉参与者要执行的本地事务
例子: Choreography-based saga
使用此方法的电子商务应用程序将使用基于 Choreography-based saga创建订单，包含以下步骤：
- Order Service创建处于挂起状态的订单并发布OrderCreated事件
- Customer Service收到事件尝试为该订单保留信用。它发布Credit Reserved事件或CreditLimitExceeded事件。
- Order Service接收事件并将订单状态更改为已批准或已取消
例子: Orchestration-based saga
使用此方法的电子商务应用程序将使用基于Choreography-based saga创建订单，包含以下步骤：
- Order Service创建处于暂挂状态的订单并创建CreateOrderSaga
- CreateOrderSaga向Customer Service 发送ReserveCredit命令
- Customer Service尝试为该订单保留信用额并发回回复
- CreateOrderSaga接收回复并向Order Service发送ApproveOrder或RejectOrder命令
- Order Service将订单状态更改为已批准或已取消
结论上下文
这种模式具有以下好处：
- 它使应用程序能够跨多个服务维护数据一致性，而无需使用分布式事务
该解决方案具有以下缺点：
- 编程模型更复杂。例如，开发人员必须设计补偿事务，以明确撤消先前在saga中所做的更改。
还有以下问题需要解决：
- 为了可靠，服务必须以原子方式更新其数据库并发布消息/事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。相反，它必须使用下面列出的模式之一。
关联模式
- 每个服务独立数据库模式创建了对此模式的需求
- 以下模式是以原子方式更新状态和发布消息/事件的方法：
- 事件溯源
- 交易发件箱
- 基于Choreography可以使用聚合和域事件发布事件