asp.net - ASP.NET 应用程序可以处理 NServiceBus 事件吗？

Question

大多数(如果不是全部)ASP.NET(或 MVC)的 NSB 示例都有 Web 应用程序使用 Bus.Send 发送消息。并且可能注册一个简单的回调，这基本上就是我在我的应用程序中使用它的方式。

我想知道是否有可能和/或在同一个 ASP.NET 应用程序中处理消息是否有意义。

我问的主要原因是缓存。这个过程可能是这样的:

用户从 Web 应用程序发起请求。

Web 应用程序向独立的应用程序服务器发送消息，并将更改记录在本地数据库中。

在来自同一用户的 future 页面请求中，Web 应用程序会知道更改并将其列为“待处理”状态。

后端发生了一堆事情，最终请求被批准或拒绝。引用原始请求发布事件。

此时，Web 应用程序应开始显示最新信息。

现在，在一个真正的 Web 应用程序中，几乎可以肯定的是，这个待处理的请求将被缓存，很可能会被缓存很长时间，因为否则应用程序必须在每次用户请求时查询数据库以获取待处理的更改当前信息。

因此，当请求最终在后端完成时(可能需要一分钟或一天)，Web 应用程序至少需要使此缓存条目无效并进行另一次数据库查找。

现在我意识到这可以通过 SqlDependency 进行管理对象等等，但让我们假设它们不可用 - 也许它不是 SQL Server 后端，或者可能当前信息查询转到 Web 服务，等等。问题是，Web 应用程序如何意识到状态的变化？

如果可以在 ASP.NET 应用程序中处理 NServiceBus 消息，那么处理程序的上下文是什么？换句话说，IoC 容器将不得不注入(inject)一堆依赖项，但它们的作用域是什么？这一切都在 HTTP 请求的上下文中执行吗？还是消息处理程序的所有内容都需要是静态/单例的？

对于此类问题，是否有更好/推荐的方法？

Answer 1

我自己也想知道同样的事情——Web 应用程序与 NServiceBus 基础设施的适当耦合级别是多少？在我的领域中，我有一个类似的问题需要解决，涉及使用 SignalR 代替缓存。和你一样，我没有找到很多关于这个特定模式的文档。但是，我认为可以通过遵循它的一些含义进行推理，然后确定它在您的环境中是否有意义。

简而言之，我会说我相信完全有可能让 Web 应用程序订阅 NServiceBus 事件。我不认为会有任何技术障碍，尽管我不得不承认我没有真正尝试过——如果你有时间，一定要试一试。我只是有一种强烈的感觉，如果一个人开始需要这样做，那么可能会有更好的整体设计等待被发现。这就是为什么我认为是这样的:

要问的一个相关问题与您的缓存实现有关。如果它是分布式或集中式模型(想想 SQL、MongoDB、Memcached 等)，那么 @Adam Fyles 建议的方法听起来是个好主意。您不需要通知每个 Web 应用程序 - 可以通过不属于您的 Web 应用程序的单个 NServiceBus 端点来更新您的缓存。换句话说，您的 Web 应用程序的每个实例和“缓存更新”端点都将访问相同的共享缓存。但是，如果您的缓存是进程中的，例如 Microsoft 的 Web 缓存，那么您当然会遇到一个更棘手的问题要解决，除非您可以按照建议依赖最终一致性。

如果您的 Web 应用程序订阅了特定的 NServiceBus 事件，那么您有必要为您的 Web 应用程序的每个实例拥有一个唯一的输入队列。由于最佳实践是考虑使用负载均衡器横向扩展您的 Web 应用程序，这意味着您最终可能会得到 N 个队列和至少 N 个订阅，这比固定数量的订阅更令人担忧。再说一次，不是技术障碍，只是让我挑眉的事情。

链接的 David Boike 文章提出了一个关于应用程序池以及它们的生命周期如何不确定的有趣观点。此外，如果您在服务器上为同一个应用程序同时运行多个应用程序池(常见场景)，它们都将尝试从同一个消息队列中读取，并且没有好的方法来确定哪个将实际处理消息.更多时候，这很重要。相反，根据 this post by Udi Dahan，发送命令不需要输入队列。 .这就是为什么我认为 Web 应用程序发送的单向命令在实践中更为常见。

这里有很多关于单一职责原则的内容。总的来说，我会说，如果您可以将发送和接收消息的“专业知识”尽可能委派给 NServiceBus 主机，那么您的整体架构将更加简洁和易于管理。通过经验，我发现如果我将我的网络农场视为一个单一的实体，即去掉对单个网络服务器身份的所有确认，我往往不必担心。让每个 Web 服务器成为总线上的一个端点就打破了这个概念，因为现在“哪个服务器”以消息队列的形式再次出现。

这有助于澄清事情吗？