NServiceBus saga-to-saga通信是否是一种反模式？

我们有两个长期运行的传奇故事，它们都运行了无限长的时间并响应超时。第一个订阅每15分钟一次超时，第二个订阅每24小时一次。每个传奇都记录自己的执行时间，并在开始运行和完成时通知其他传奇。由于数据库争用，这些SAGA负责的大容量数据加载无法同时运行

当第一个传奇（

saga A

-15分钟）开始时，它首先检查（使用内部变量）第二个传奇（

saga B

-24小时）当前是否正在运行。如果没有，它将开始其处理步骤（跳转到另一个进程，并随着时间的推移轮询它以查看它何时完成）。这两个传奇通过发送消息进行通信，在启动或完成时相互通知

出于某种原因，我觉得这在两个层面上都很难闻：

我们基本上有一个从未完成的单身传奇。这本身就是一种反模式吗

我们双向发送消息的唯一目的是修改状态。似乎应该有更好的方法来处理这种情况。随着NSB 4.0的发布，我们开始在

发送

命令时出错。当我们使用pub-sub方法时，错误就消除了

---

这被认为是一种NServiceBus实现反模式吗？对于这种需求，有更好的模式吗？

一般来说，我不认为sagas相互通信是一种反模式。然而，在你的特殊情况下，它听起来确实很臭

从你所说的行为来看，这似乎是一个单一的传奇。一个传奇可以请求不同类型的多次超时。因此，您可以有效地合并这些传奇，但这样您就可以删除所有存在的消息，这些消息仅仅是为了修改同级中的状态，因为状态是共享的

然而，从一般意义上讲，这是一个很好的沟通传奇。通过命令执行此操作应谨慎处理，因为这会在两者之间创建直接耦合，尽管这仍然是可能的。一个例子是父子saga对，其中父工作流命令子工作流开始，但子工作流是独立的，直到它向父工作流答复它已经完成。我们刚刚意识到，这些流程在同一个服务边界内是紧密耦合的。我们这样做可能只是为了让每一个故事更加集中，或者是因为父母用不同的数据开始了多个子故事

---

一个更好的例子是通过事件进行的传奇传播。一个传奇将发布一个事件，而另一个传奇将以其自身的长期运行过程作出响应。这一切都是解耦的，很好。然而，如果第二个传奇发布了第一个传奇响应的事件，那么即使您使用事件，您也创建了一个循环，因此在这一点上它与命令没有太大的不同，尽管它仍然与任何其他外部订阅者解耦。

我同意它有点异味。我认为，saga可以管理ETL过程运行的工作流以及何时运行，并将其发送到外部端点来处理实际工作。这给我带来了另一个问题：单例/永久运行的传奇是反模式吗？不，传奇永远不会结束是完全可以接受的。虽然如果你只是想找一个简单的日程安排，但还是要看看这一点。在我们的例子中，我们实际上有一个逻辑，它保持了独立过程的互斥性。因为这也包括国家，我认为一个简单的传奇故事是最好的选择。计划程序仅适用于计划的火灾和遗忘消息。听起来你走对了！