一个存在于现实世界中的Saga例子：买咖啡，包括四步：下单、支付、制作和配送。在正常情况下，顾客付钱，然后会收到所点的咖啡。
买咖啡的过程是有可能出错的！可能是咖啡店的机器出现故障；也可能是咖啡师制作了一杯卡布奇诺咖啡，而顾客想要的是白咖啡；还有可能是服务员将咖啡给了其他顾客等等。如果发生了这种事，咖啡师自然会进行补偿：他可能会给顾客重新制作一杯咖啡，也可能会把钱退给顾客。大部分情况下，顾客最终会拿到他想要的咖啡。
包含补偿动作在内的咖啡购买过程
图中，可以看到每个买咖啡的步骤都有相应的补偿动作，使得咖啡购买最终状态一致性。如果把买咖啡的4步拆分为4个微服务，买咖啡的过程相当于4个微服务在交互。分布式下每个服务可以在不了解整个流程的情况下响应各种事件，独立执行各种操作。只要有一个事务失败了，怎么确保系统最终达到一致的状态呢？有没有机制提供补偿操作来撤销到之前的状态呢？
在微服务方案的概念之前，赫克托尔·加西亚· 莫利纳（Hector Garcia Molina）和肯尼斯·塞勒姆（Kenneth Salem）在1987年论文中提到Saga，它是一种处理数据库系统中那些耗时特别长的事务(long-lived transaction)的方法。在分布式事务中，对耗时特别长的事务加锁会降低系统的可用性——而Saga会通过一连串相互交错的、单个的事务来解决。
虽然每个本地事务都是原子化的——但是Saga作为整体并不是原子化的——即便只有一个事务失败了，开发者也必须自己编写代码来确保系统最终达到一致的状态。帕特·赫兰德（Pat Helland）有一篇著名的论文Life Beyond Distributed Transactions，建议开发者将分布式交互视作一种不确定性——多个服务间交互的结果可能是无法得到保证的。在分布式事务中，开发者通过在数据上加锁来控制不确定性。如果没有了事务，就要按照操作的实际意义来确认、取消或者补偿相应工作流中的这些操作，从而实现对这种不确定性的控制。
在Saga中，会用补偿操作来撤销之前的操作，并让系统恢复到更一致些的状态。系统不保证一定会恢复到最初的状态；具体的操作要依赖于业务含义。这种设计方法会使得编写的业务逻辑更加复杂——因为我们需要考虑更大范围的可能场景——但这也是提高分布式服务间交互的可靠性的重要工具。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论