DDD 中的编排 Sagas - 集成事件链？
Choreography Sagas in DDD - Chain of Integration Events?
我目前正在研究 Saga 模式。大多数示例似乎都集中在 Orchestration Sagas 上，我们有一个中央 saga 执行协调器服务来发送和接收 messages/events。不幸的是，关于如何实现 Choreography Sagas 的信息似乎有点缺乏。
在领域驱动设计中，我们有多个限界上下文，理想情况下，每个限界上下文都是一个独立的微服务。如果微服务 A 想要与另一个微服务 B 通信，我们使用 Integration Events。使用一些异步通信发布和订阅集成事件 - RabbitMQ、Azure 服务总线。
假设我们想要启动一些 Saga，例如，我们必须在订单服务和客户服务上进行 运行 交易 - 服务之间究竟如何通信？它只是常规的集成事件还是完全不同的东西？
我看到它的方式和下面给出的图片 (source)，Saga 将以这种方式执行：
- 新订单已创建。状态设置为“待定”并且发出 OrderSubmittedDomainEvent 域事件。
- 域事件处理程序接收 OrderSubmittedDomainEvent 域事件，然后创建并调度 ReserveCreditIntegrationEvent 集成事件。
- 客户服务收到 ReserveCreditIntegrationEvent 集成事件。
- 它试图保留客户信用。
- 如果成功预留信用，则发出 CustomerCreditReservedDomainEvent 域事件。
- 域事件处理程序收到 CustomerCreditReservedDomainEvent 域事件，它创建并调度 CreditReservedIntegrationEvent 集成事件。
- 订单服务接收 CreditReservedIntegrationEvent 集成事件并将订单状态设置为“已确认”。
- 传奇故事完成。
这是正确的方法吗？
我认为使用 Choreography 而不是 Orchestration 如果您出于正确的原因选择分布式事务，那么它是有意义的。例如，如果您需要省去实施中央编排通常更高的工作量，因为您 不需要知道事务处于什么状态 直到结束。或者因为您知道交易工作流的顺序是稳定的并且不太可能改变，这也对编排有利。但是，如果顺序经常更改，这将是编排的一个缺点，因为在这种情况下，您需要调整 所有微服务...
所以你需要了解这两种方法的优缺点。
如果您出于正确的原因选择编排，我会说我在您的考虑中缺少 补偿逻辑。如果预留信用但订单服务中订单失败怎么办？在这种情况下也需要考虑补偿事件...
除此之外还有常见的嫌疑人：
- 例如确保每个服务在处理接收到的事件后可靠地发送下一个事件。为此，您可以查看 Transactional Outbox 模式。
- 或者确保您在每个服务中实现了事件重复数据删除，以便跨分布式事务可靠地发送事件，您不能百分百确定一个事件只会发送一次。
如果您甚至对 Saga 模式的替代方案感兴趣，您可以查看 Routing Slip 模式。它非常适合分布式事务工作流，这些工作流将根据当前用例而有所不同，避免每个服务需要知道每个路由。工作流的顺序附加到事务的初始消息和所有后续消息。然后，每个接收带有路由单的消息的服务都会执行其任务，并将包含路由单的下一条消息传递给列表中的下一个站点（服务）。
注意：我不确定您所说的 ...IntegrationEvent 到底是什么意思。我不会区分 domain 和 integration 事件，从您的示例中的业务角度来看，所有事件都是相关的，否则它们将与其他微服务无关.
我目前正在研究 Saga 模式。大多数示例似乎都集中在 Orchestration Sagas 上，我们有一个中央 saga 执行协调器服务来发送和接收 messages/events。不幸的是，关于如何实现 Choreography Sagas 的信息似乎有点缺乏。
在领域驱动设计中，我们有多个限界上下文，理想情况下，每个限界上下文都是一个独立的微服务。如果微服务 A 想要与另一个微服务 B 通信，我们使用 Integration Events。使用一些异步通信发布和订阅集成事件 - RabbitMQ、Azure 服务总线。
假设我们想要启动一些 Saga，例如，我们必须在订单服务和客户服务上进行 运行 交易 - 服务之间究竟如何通信？它只是常规的集成事件还是完全不同的东西？
我看到它的方式和下面给出的图片 (source)，Saga 将以这种方式执行：
- 新订单已创建。状态设置为“待定”并且发出 OrderSubmittedDomainEvent 域事件。
- 域事件处理程序接收 OrderSubmittedDomainEvent 域事件，然后创建并调度 ReserveCreditIntegrationEvent 集成事件。
- 客户服务收到 ReserveCreditIntegrationEvent 集成事件。
- 它试图保留客户信用。
- 如果成功预留信用，则发出 CustomerCreditReservedDomainEvent 域事件。
- 域事件处理程序收到 CustomerCreditReservedDomainEvent 域事件，它创建并调度 CreditReservedIntegrationEvent 集成事件。
- 订单服务接收 CreditReservedIntegrationEvent 集成事件并将订单状态设置为“已确认”。
- 传奇故事完成。
这是正确的方法吗？
我认为使用 Choreography 而不是 Orchestration 如果您出于正确的原因选择分布式事务，那么它是有意义的。例如，如果您需要省去实施中央编排通常更高的工作量，因为您 不需要知道事务处于什么状态 直到结束。或者因为您知道交易工作流的顺序是稳定的并且不太可能改变，这也对编排有利。但是，如果顺序经常更改，这将是编排的一个缺点，因为在这种情况下，您需要调整 所有微服务...
所以你需要了解这两种方法的优缺点。
如果您出于正确的原因选择编排，我会说我在您的考虑中缺少 补偿逻辑。如果预留信用但订单服务中订单失败怎么办？在这种情况下也需要考虑补偿事件...
除此之外还有常见的嫌疑人：
- 例如确保每个服务在处理接收到的事件后可靠地发送下一个事件。为此，您可以查看 Transactional Outbox 模式。
- 或者确保您在每个服务中实现了事件重复数据删除，以便跨分布式事务可靠地发送事件，您不能百分百确定一个事件只会发送一次。
如果您甚至对 Saga 模式的替代方案感兴趣，您可以查看 Routing Slip 模式。它非常适合分布式事务工作流，这些工作流将根据当前用例而有所不同，避免每个服务需要知道每个路由。工作流的顺序附加到事务的初始消息和所有后续消息。然后，每个接收带有路由单的消息的服务都会执行其任务，并将包含路由单的下一条消息传递给列表中的下一个站点（服务）。
注意：我不确定您所说的 ...IntegrationEvent 到底是什么意思。我不会区分 domain 和 integration 事件，从您的示例中的业务角度来看，所有事件都是相关的，否则它们将与其他微服务无关.