c# - 微服务架构中的Saga业务流程可伸缩性问题

我需要在微服务架构中处理分布式事务。从理论上讲，最好的方法之一是使用Saga Orchestration模式。问题是我找不到有关如何提供可伸缩性的任何详细信息。

让我们使用下面的示例。如果我有多个OrderService.API，则可以有许多CreateOrderSaga，情况会如此。因为我可以拥有多个OrderService.API。然后，如果CreateOrderSaga是一种状态机，那么是否意味着它应该自行处理其中的所有步骤，否则其他协调员可以执行其工作？

然后，如果一个API在运行saga进程时崩溃，那么其他saga协调器可以继续以崩溃的API离开的相同状态运行吗？处理这种情况的最佳方法是什么？事件存储如何提供帮助？

让我详细解释

在Order.API之一中的

Coordinator1中，启动CreateOrderSaga

Coordinator1中的

CreateOrderSaga创建一个具有以下内容的订单
暂挂状态

然后，由于某些原因Coordinator1崩溃了。 (也许没电了)订单保持待处理状态，现在没有人对此感兴趣。有人应继续处理它或将其标记为失败(由谁负责)，也许还需要进行一些补偿交易。

因此，让传奇协调员启动流程，其他人也可以继续进行流程可以吗？

如何扩展传奇故事协调器？





解决方案:

我确实选择了Masstransit来管理分布式交易

最佳答案

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

您单击“下订单”按钮，CreateOrder消息被发送到消息队列中，OrderService从队列中接收此消息。它可以扩展，因为您可以创建许多OrderService实例。

然后我们有两种情况:
1. 基于业务流程的saga :OrderService接收消息，实例化协调器，协调器使用CustomerService。如果OrderService在完成消息处理之前失败，则不会在消息队列中确认CreateMessage消息。随后，OrderService的另一个实例将接收到该消息并尝试对其进行处理。如果在调用过程中CustomerService失败:您可以使整个CreateOrder消息失败，然后稍后重试，或者重试对CustomerService的特定调用。
2. 基于编排的saga :OrderService接收一条消息并尝试处理该消息。如果失败，则情况相同:该消息将不会被确认，并将重新发送给以后的下一次重试。这种方法是关于发出OrderCreated，CustomerCreated等事件(即面向事件)

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

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

进一步阅读:overview of sagas，coordinating sagas，choreography-based sagas:



要获得更多有关如何正确实现它的想法，请阅读NServiceBus sagas framework是如何实现的。它是.NET的sagas框架，但概念与语言无关。

关于c# - 微服务架构中的Saga业务流程可伸缩性问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/59141487/