微服务中的分布式事务管理 - 2/2 Saga异步模式
转载请注明来源：https://janrs.com/h42y
这篇文章是上一篇文章的延续。
在这篇文章中，我们将看到Saga模式，它是一种异步模式，在每个微服务中执行一连串的事务，并发布消息或事件以进行下一步。如果中间有任何步骤失败，Saga模式将执行补偿步骤以逆转交易。
我们可以从上图中看到，Saga模式在每个服务中执行一连串的本地事务。每个服务更新它的数据库，然后发布一个消息或事件，这将触发下一个本地事务。
因此，我们必须写出提交事务的逻辑，并且当事务中的任何地方出错时，也要有一个机制来逆转流程。所有的事务和补偿性事务都将通过监听器发生，这些监听器监听来自队列的事件或消息。
补偿事务必须是幂等的，并且应该能够在上一次尝试失败时重试。
Saga模式可以使用两种方式实现，即
- Choreography-Based Saga Pattern - 编排模式
- Orchestration-Based Saga Pattern - 编制模式
Choreography-Based Saga Pattern - 编排模式
在Choreography模式中，没有集中的控制点，服务将听从一个消息代理来读取消息，并将事件/消息发射回队列，供其他服务听从和消费。
在编排模式中执行以下步骤
- 订单服务从用户那里得到了创建订单的请求，因此订单在待定状态下被创建。
- 在待定状态下创建订单后，它在订单事件通道或队列中发出一个事件。
- 客户服务部听取了事件的情况，并试图保留信用。
- 然后它向订单服务发出事件。
- 订单服务部现在根据从客户服务部收到的事件结果，批准订单或拒绝订单。
编排模式的优点
- 编排模式很容易实现。
- 这对参与交易的服务较少的用例来说是好的。
- 没有单点故障，因为交易是分布在各个服务中的。
编排模式的缺点
- 当更多的服务被添加到交易中时，那么Choreography模式将变得复杂。
- 例如：如果订单服务需要向客户服务发出事件，而客户服务向支付服务发出事件，以此类推，那么工作流程就会变大，并且难以跟踪和调试。
- 可能有这样的情况：两个服务可能在等待对方的事件，最后陷入僵局状态。
Orchestrator-Based Saga Pattern - 编制模式
在上面的Choreography编排模式中，有一个集中的组件来控制事务，这个组件被称为Orchestrator。它向服务发布命令，并根据从Saga参与者那里得到的结果决定提交或中止事务。
如果任何一个微服务失败，Orchestrator将调用补偿性事务。Orchestrator可以存在于触发事务流的微服务内，或者Orchestrator可以作为服务外的一个独立组件存在。
Orchestrator是一个独立的组件
正如我们在下图中看到的，Orchestrator是一个独立的服务，它与参与事务的其他服务进行交互。每个服务都接收来自Orchestrator的命令，并将事件响应发射回Orchestrator。
Orchestrator作为订单服务中的一个组件
正如我们在下图中看到的，创建订单Saga是驻扎在订单服务中的Orchestrator组件。
在编制模式中执行以下步骤：
- 当用户下订单时，订单控制器的端点被调用，然后调用订单服务。
- 订单服务创建了Create Order Saga Orchestrator，它只不过是一个Orchestrator编制（对象），告诉微服务要执行哪些本地事务。
- Saga Orchestrator在待定状态下创建订单。
- 然后它将向客户服务发送 Reserve Credit 命令。
- 客户服务部尝试保留信用，并将结果发回给Saga编制。
- Saga编制器根据结果批准或拒绝该订单。
编制模式的优点
- 与Choreography模式不同，Orchestrator模式可用于复杂的工作流，任何新的服务都可以作为事务的一部分被添加，并且可以被管理。
- 有一个Orchestrator编制器作为事务协调者，有助于控制事务和活动的流程。
- 没有循环依赖的可能性。
- Saga的参与者，即微服务是独立的，不知道其他服务，因此业务逻辑分离。
编制模式的缺点
- 与Choreography模式相比，有一个设计上的复杂性，因为我们要额外实现一个协调逻辑。
- 这里有一个单点故障，因为Orchestrator编制器管理着整个工作流程。
总结
在这篇文章中，我们看到了什么是微服务中事务管理的异步模式，还探索了Saga模式及其两个变体，即基于Choreography和基于Orchestrator的模式。我们深入了解了这两种模式，然后讨论了它们的好处和坏处。根据用例，我们为你的应用选择了其中一种模式。
Saga模式使应用程序通过使用本地事务而不是分布式事务来保持多个服务之间的数据一致性。但是这种编程模式有点复杂，需要更多的时间，因为我们必须在所有的服务中编写补偿性的事务逻辑。
总的来说，与两阶段提交（2 PC）和三阶段提交（3 PC）等同步模式相比，异步Saga模式对微服务来说更好、更高效。但它也有自己的缺点，在多个微服务中处理分布式事务总是在ACID合规性方面存在问题，因此应尽可能避免分布式事务。
转载请注明来源：https://janrs.com/h42y