用于处理公共共享服务事件的NServiceBus模式

Question

我们有一种情况，我们的几个服务在我们的系统中共享。例如，一个跟踪股票走势的工具。每当文章的库存水平发生变化时，就会引发一个事件。

我们遇到的问题是，虽然有时另一个服务可能对所有股票变化事件感兴趣(例如，进行一些聚合)，但在大多数情况下，只有作为特定操作的结果的股票变化才是有趣的。

我们现在面临的问题是这样的。假设有一个包含文章编号、股票变更和请求变更的ProcessId的IArticleStockChangedEvent事件。对于文章库存中的每个更改，都会引发此事件。

现在，一些外部服务有了更改10篇文章的传奇，并命令股票服务这样做。它还实现了IHandleMessages来跟踪进度。这在理论上运行良好，但在实践中，这意味着包含此saga的服务将被不相关的IArticleStockChangedEvent消息淹没，它将无法找到对应的saga实例。虽然从技术上讲它不会破坏任何东西，但它会导致系统中不必要的延迟。

我并不是真的期待为每一个可能导致股票变化的传奇故事创建一种新的IArticleStockChangedEvent。处理此问题的推荐方法是什么？

谢谢

Answer 1

关于需要传递给服务的IArticleStockChangedEvent事件的知识存在于“外部”服务中，并且是动态变化的，因此不可能(或复杂且不可伸缩)在股票服务或传输级别(例如，服务总线订阅过滤器)。

为了进行优化，即避免IArticleStockChangedEvent的反序列化，您可以考虑自定义Behavior<IIncomingPhysicalMessageContext>，您可以从消息标头和查找数据库中读取Stock项的Id，以查看该库存项是否有任何传奇，如果没有，则缩短消息处理。

更好的解决方案可能是使用Reply并使用来自Stock服务的消息进行回复。