一、事务难题
事务是每个企业级应用的基本要素，如何实现跨多个的服务的是事务一直是行业的一个炙热话题也是难题之一。
二、使用saga管理事务
saga是一种在微服务架构中维护数据一致性的机制，它可以避免分布式事务所带来的问题。saga由一连串的本地事务组成，每一个本地事务负责更新它所在服务的私有数据库，这些操作仍旧依赖于我们所熟悉的ACID事务框架和函数库。saga通过使用异步消息来协调一系列本地事务，从而维护多个服务之间的数据一致性。
小马之前分析过分布式事务的集中解决方案（点这里），其中的补偿事务TCC就是和saga差不多的原理。Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
小马理解为，tcc需要先操作锁资源如果失败回滚释放资源；而saga先用着如果失败再作补偿回去。
三、saga的协调模式
saga的实现包含协调saga步骤的逻辑。当通过系统命令启动saga时，协调逻辑必须选择并通知第一个saga参与方执行本地事务。一旦事务完成，saga协调选择并调用下一个saga参与方。这个过程一直持续到saga执行完成所有步骤。如果任何本地事务失败，则saga必须以相反的顺序执行补偿事务（已执行完的事务越长回滚的链条越长）。以下几种不同的方法可以用来构建saga的协调逻辑。
协同式：把saga的决策和执行顺序逻辑分布在saga每一个参与方中，它们通过交换事件的方式来进行沟通。
编排式：把saga的决策和执行顺序逻辑集中在一个saga编排器中。saga编排器发出命令消息给各个saga参与方，指示这些参与方服务完成具体操作（本地事务）。
以下是两个模式的图解，来自《微服务架构设计模式》，书内也有详细的步骤说明，有兴趣的可以自行翻阅，小马就不在这赘述了。
小马来以通俗的语言分享下自己的理解。从图示我们可以很容易地看出两种模式最大的区别在于，协同式是参与方之间自己协调的通信（失败/成功消息），而编排式都是编排器在统一作消息的协调，可以把编排器视为一个状态机。编排器依赖于各参与方，参与方不依赖于编排器。而协同式会存在循环依赖的问题。因此，编排式被书中作者所推荐。
四、没有隔离性
使用saga的挑战在于它们缺乏CAID事务的隔离属性。这是因为一旦事务提交，每个saga的本地事务所作的更新都会立即被其他sagas看到。你可以认为saga只满足了事务的三个属性。
小马理解为其中之一就是使用逻辑上的状态锁来解决隔离性问题。看起来似乎相对麻烦，但技术没有“银弹”不是么？
参考文献：
《微服务设计模式》
