「微服务架构」Saga 模式 如何使用微服务实现业务事务-第二部分

「微服务架构」Saga 模式 如何使用微服务实现业务事务-第二部分

在上一篇文章中，我们看到了实现分布式事务的一些挑战，以及如何使用Event / Choreography方法实现Saga的模式。在本文中，我们将讨论如何通过使用另一种类型的Saga实现（称为Command或Orchestration）来解决一些问题，如复杂事务或事件的循环依赖性。

Saga的命令/编曲序列逻辑

在编曲方法中，我们定义了一项新服务，其唯一责任是告诉每个参与者该做什么以及何时做什么。saga orchestrator以命令/回复方式与每个服务进行通信，告诉他们应该执行哪些操作。

让我们看一下使用我们之前的电子商务示例的样子：

订单服务保存挂起的定单并要求Order Saga Orchestrator（OSO）启动创建订单交易。OSO向付款服务发送执行付款命令，并回复付款已执行消息OSO向库存服务发送准备订单命令，并回复订单准备消息OSO向Delivery Service发送Deliver Order命令，并以Order Delivered消息回复

在上面的例子中，Order Saga Orchestrator知道执行“创建订单”事务所需的流程是什么。如果有任何失败，它还负责通过向每个参与者发送命令以撤消先前的操作来协调回滚。

为saga协调器建模的标准方法是状态机，其中每个转换对应于命令或消息。状态机是构建定义明确的行为的极好模式，因为它们易于实现，特别适合测试。

在Saga的命令/编曲中回滚

当你有一个协调器来协调所有事情时，回滚会容易得多：

使用Saga命令/编曲设计的好处和缺点

基于编排的传奇有各种好处：

避免服务之间的循环依赖，因为saga orchestrator调用saga参与者但参与者不调用orchestrator

集中分布式事务的编排降低参与者的复杂性，因为他们只需要执行/回复命令。更容易实施和测试添加新步骤时，事务复杂性保持线性回滚更容易管理如果您有第二个愿意更改同一目标对象的事务，您可以轻松地将其保留在协调器上，直到第一个事务结束。

然而，这种方法仍然存在一些缺点，其中之一是在协调器中集中过多逻辑的风险，最终导致智能协调器告诉哑巴服务该做什么的架构。

Saga的Orchestration模式的另一个缺点是它会略微增加您的基础架构复杂性，因为您需要管理额外的服务。

Saga(传奇)模式提示

为每个事务创建唯一ID

为每个事务提供唯一标识符是可追溯性的常用技术，但它也有助于参与者以标准方式相互请求数据。例如，通过使用交易ID，交付服务可以询问库存服务在哪里提取产品，如果订单已付款，则可以使用支付服务仔细检查。

在命令中添加回复地址

不要将参与者设计为回复固定地址，而是考虑在消息中发送回复地址，这样您就可以让参与者回复多个协调者。

幂等运算

如果您使用队列进行服务之间的通信（如SQS，Kafka，RabbitMQ等），我个人建议您使您的操作具有幂等性。大多数队列可能会两次传递相同的消息。

它还可能会增加您的服务的容错能力。通常，客户端中的错误可能会触发/重放不需要的消息并弄乱您的数据库。

避免同步通信

随着事务的进行，不要忘记将每个要执行的操作所需的所有数据添加到消息中。整个目标是避免服务之间的同步调用只是为了请求更多的数据。即使其他服务处于脱机状态，它也可以使您的服务执行本地事务。

缺点是您的协调器会稍微复杂一些，因为您需要操纵每个步骤的请求/响应，因此请注意权衡。

谢谢大家关注，转发，点赞。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。