Saga Orchestration Scability Issue in Microservice Architecture

Question

I need to handle distributed transactions in a microservice architecture. In theory, one of the best ways of doing that is using the Saga Orchestration pattern. The problem is I could not find any detailed information about how to provide scalability.

Let's use the example below. There can be many CreateOrderSaga, if I have multiple OrderService.API and it will be the case. Because I can have more than one OrderService.API. Then if CreateOrderSaga is kind of a state machine, then does it mean it should handle all the steps in it by itself or other coordinators can take its job?

Then what if that one API crashes while running the saga process, can other saga coordinators continue to run with the same state where the crashed API left? What's the best way of handling this situation? How an event storing can help ?

Let me explain in detail

1. Coordinator1 in one of the Order.APIs, starts the CreateOrderSaga

2. CreateOrderSaga in Coordinator1 creates an order which has pending state

3. 然后 Coordinator1 由于某种原因崩溃了。（可能没电了）订单一直处于待处理状态，现在没有人感兴趣。有人应该继续处理它或应该将其标记为失败（谁有责任） 也许还需要一些补偿交易。

那么是否可以让 saga 协调器启动一个进程，但其他人也可以继续处理它？

如何扩大 saga 协调器的规模？

解决方案：

我确实选择了 Masstransit 来管理分布式事务

Answer 1

Saga 模式应该作为异步过程来实现。在这种情况下asynchronous意味着基于消息。大多数类型的消息队列都有确认功能（对于rabbitmq）。这里我将描述无状态服务（即可以处理CreateOrder不同实例中的请求OrderService）。

\n\n

您点击“下单”按钮，CreateOrder消息被发送到消息队列，并OrderService从队列中接收该消息。它是可扩展的，因为您可以创建许多OrderService.

\n\n

那么我们有两种情况：

\n\n

1. 基于编排的传奇：OrderService接收消息，实例化协调器，协调器消费CustomerService。如果OrderService在消息处理完成之前失败，CreateMessage消息将不会在消息队列中得到确认。随后， 的另一个实例OrderService将接收该消息并尝试处理它。如果CustomerService在调用过程中失败：您可以使整个CreateOrder消息失败并稍后重试，或者重试对 的特定调用CustomerService。

\n\n

2. 基于编排的传奇：OrderService接收消息并尝试处理该消息。如果失败，则情况相同：消息将不会被确认，并将在稍后重试时重新传递。这种方法是关于发出诸如等的事件OrderCreated（CustomerCreated即它是面向事件的）

\n\n

当然，您应该为您的服务配置监视和警报，以确保系统处于活动状态并且能够处理消息。

\n\n

您还应该考虑是否需要实施一些补偿逻辑或检查。想象一下：在处理一条消息时，您向不同的服务发出两个 HTTP POST 请求，第一个服务调用成功完成，但第二个服务调用失败。如果您重试整个CreateOrder消息 - 您不应再次调用第一个服务。

\n\n

进一步阅读：传奇故事概述、协调传奇故事、基于编排的传奇故事：

\n\n

\n

为了使通信可靠，传奇参与者必须使用保证至少一次传送并具有持久订阅的消息代理。\xe2\x80\x99s 因为至少一次传送和持久订阅可确保即使参与者暂时不可用，传奇也能完成。消息将位于消息代理\xe2\x80\x99s 通道（例如队列或主题）中，直到参与者\n 能够成功处理它。

\n

\n\n

要了解如何正确实现它的更多想法，请阅读NServiceBus sagas 框架的实现方式。它是用于传奇的 .NET 框架，但概念与语言无关。

\n