戏说领域驱动设计（廿七）： Saga设计模型是如何构建的？

本文共计3877个文字，预计阅读时间需要16分钟。

上一节我们讲解了常用事务，并提到了Saga。这是在分布式环境下经常使用的一种处理复杂业务和分布式事务的设计模式。本章的主要目标是编写一个简易版本的Saga处理器。

　　上一节我们讲解了常用的事务，也提及了Saga，这是在分布式环境下被经常使用的一种处理复杂业务和分布式事务的设计模式。本章我们的主要目标是编写一个简单版本的Saga处理器，不同于Seata框架中那种可独立部署的事务服务，我们所编写的Saga和业务集成在一起也不支持通过手画流程的方式实现，因为我们的目标是将Saga作为一种设计模式（不是框架）来使用，类似于您经常使用的“工厂”、“策略”等，重点学习它的思想，在真实项目中使用肯定是需要根据需求做二次加工的。而且，简单版本的优势就是足够简单，投入虽然不多但能从中获取的收益却很大。在代码演示后我们还会重点描述一下如何解决Saga事务的隔离性问题。

一、Saga种类说明

　　常用的Saga包含两类：协同式和编排式。前者把流程的走向与协调全盘由事务的参考者来完成，比如最简单的场景：下单同时对库存进行扣减，订单服务本地事务完成后就把事件消息发送给库存服务，库存服务如果本地事务处理失败则由它将回滚的消息发送给订单服务。虽然整个流程当中订单服务与库存服务并没有产生耦合，但由于没有一个总的事务协调者，一旦服务参与者多起来那业务流程的可理解性就非常差，出了问题也不好定位。第二类为编排型事务也是我们本章要主要介绍的，通过把Saga的执行顺序交由一个集中的Saga编排器，由它指挥并决策业务的流向，相对于协同式整个流程要清晰很多。除非您使用的是足够成熟的第三方的框架，要不然集中式Saga也可能会存在事务参与者不清晰的问题，比如本文我们要介绍的Saga就会有类似的问题，毕竟以个人的精力很多事情的确无法做到极致，有牺牲也很正常。