性能与架构：杜亦舒
原文：https://mp.weixin.qq.com/s/An6QbAOw6jhWxg7GDT56Ug
本文目的是讲清楚 SAGA 这种分布式事务解决方案的实现思路，不包括具体实现代码，具体实现推荐使用阿里的 Seata 框架。
内容包括：
- 分布式事务问题描述
- SAGA - Choreography 策略
- SAGA - Orchestration 策略
补充：
常用的分布式事务解决方案还包括 TCC、可靠消息模式。
1. 分布式事务问题描述
比如说电商系统中，用户下单了，后端需要调用：
- 订单服务，创建订单
- 库存服务，改商品的库存
- 物流服务，创建物流单，准备发货
在分布式的微服务架构中，每个服务都会有自己独立的数据库，那么，这个下单的动作就涉及到了向多个数据库中写入数据。
因为不是在同一个数据库中，所以就不能依赖数据库的事务机制了，但是在业务逻辑中，这几个写库操作就应该是一个事务。
比如订单服务、库存服务中都写入成功了，但物流系统出现异常了，那么订单服务、库存服务就应该进行回滚，来保证整体数据的一致性。
如何在跨数据库的情况下实现事务呢？这就是分布式事务问题。
SAGA 就是一种老牌的分布式事务解决方案，已经有20来年了，其实现方式主要有两种：
- Choreography
- Orchestrator
下面介绍一下各自的实现思路。
2. SAGA - Choreography 策略
Choreography 是编舞的意思，就是把舞者之间的动作配合都编排好。
对应到分布式事务，就可以把各个服务理解为舞者，SAGA 的 Choreography 策略就是要定义好先执行哪个服务，根据执行结果再触发哪些服务的执行。
如上图，整体分布式事务处理流程为：
- 订单服务写自己的业务数据，并在数据库中记录一下订单的整体状态，比如记为 "已下单"。
- 订单服务发布【订单创建成功】事件，库存服务会监听此事件。
- 库存服务收到事件通知后，写自己的业务数据，然后发布【库存修改成功】事件。
- 订单服务会监听此事件，收到事件通知后，修改订单状态，比如 "待发货"。
- 物流服务也会监听此事件，收到事件通知后，写自己的业务数据，然后发布【物流处理成功】。
- 订单服务会监听此事件，收到通知后，修改订单状态，改为 "已发货"。
这样，通过事件机制，各个服务之间完成协同配合，实现了分布式事务。
下面看异常情况的处理，比如物流服务异常了，如下图。
重点看异常处理流程：
- 物流服务会发布事件【物流处理异常】。
- 订单服务、库存服务都监听此事件，所以会收到物流异常的通知。图中（8）、（9）。
- 订单服务执行自己的回滚逻辑。图中（10）。
- 库存服务执行自己的回滚逻辑。图中（11）。
这样就实现了分布式事务的异常处理。
SAGA Choreography 策略是通过【事件机制】实现的，各个服务都定义好正常、异常的处理方法，然后监听目标事件，根据不同的事件来调用不同的处理方法。
此策略好处是实现简单，坏处是整体事件逻辑会比较复杂，比如有10个服务参与其中，那么整体事件订阅关系就会很凌乱。
3. SAGA - Orchestration
Orchestration 是乐队编排的意思。
对应到分布式事务，各个服务就是乐队中的各个演奏者，还需要一个【总指挥】，所以在 SAGA - Orchestration 策略中会单独创建一个此角色。
如上图，正常处理流程：
- 订单服务写自己的业务数据
- 订单服务向总指挥报告自己完成了
- 总指挥向库存服务发送执行指令
- 库存服务写数据
- 库存服务报告自己完成了
- 总指挥向订单服务发送指令
- 订单服务更新订单状态
- 总指挥向物流服务发送指令
......
后面的就不细说，都是一个思路。
异常处理的思路也是一样的，还是假设物流服务异常了，那么它会向总指挥报告，总指挥就会向订单服务、库存服务发送回滚的指令。
所以 Orchestration 策略的重点在于总指挥，需要为其定义指挥手册，以便总指挥在不同的时刻向相应的服务发送对应的指令。
这个总指挥实际上是通过【状态机】来实现的。
此策略好处是服务之间没有关联了，整体结构清晰。坏处是都了一个总指挥的角色，增加了复杂度。
4. 小结
Choreography 策略是通过事件机制实现的，每个服务都监听自己所关心的事件，每个服务执行后会发送相应的事件，监听此事件的服务执行相应的处理逻辑。
Orchestration 是通过状态机来实现的整体控制，定义还整体的处理流程，不同状态下需要触发的动作。
目前 Orchestration 是主流的策略，阿里的 Seata 分布式事务框架中实现了此策略，有兴趣可以去了解下。
Happy Learning ヾ(￣▽￣)Bye~Bye~
注意：本文归作者所有，未经作者允许，不得转载
