我们有一个 NServiceBus 应用程序在两个 Azure 区域运行：北欧和西欧。我们正在使用 SQL 传输，并且这些区域中的两个应用程序都连接到共享数据库。因此，北节点和西节点都处理来自同一数据库上的单个端点的命令。这是期望的行为，因为两个区域都应该处理命令
在我们需要升级软件之前，此设置效果很好。在引入新命令（及其相应的处理程序）并将这些更改部署到 a 区域后，我们在其他区域遇到了问题：找不到此消息类型的处理程序（因为我们尚未升级其他区域）。出现此问题的原因是我们在每次部署后运行自动化测试，并推迟进一步的部署，直到这些测试通过。
我们考虑了以下选项：
我是 NServiceBus 团队的开发人员。我知道贵公司拥有的许可证可以保证每月收到相当多的开发人员支持请求，因此我建议您向special.net 发送电子邮件以获取支持，因为这样来回更加方便，如果需要，我们甚至可以得到正在通话中。
我在这里做出一些假设，因为我不确定我是否理解“NServiceBus 应用程序”在两个 Azure 区域中运行的所有原因。我假设这两个应用程序是完全相同的应用程序。结果，他们开始竞争消息，因此该模式的名称为：竞争消费者。因此，它们都处理相同的消息并具有相同的消息处理程序。
升级应用程序后，您还可以添加新消息和处理程序。由于您只讨论一个应用程序，因此我假设它不断向自身发送消息。因此，如果 RegionA 中的应用程序已升级并向自身发送名为“DoThis”的NEW命令，那就没问题。但 RegionB 中的同一应用程序正在竞争相同的消息。它也会收到“DoThis”消息。但由于它尚未升级，它开始接收此消息，但没有处理程序。
幸运的是，NServiceBus 并没有丢弃该消息，而是将其发送到错误队列。从那里您可以重试，最好是使用ServicePulse。如果您以前没有使用过 ServicePulse，它需要一个名为 ServiceControl 的中央组件，该组件读取错误队列并为 ServicePulse 提供 API，以便您可以重试消息并监控您的系统。
我希望我的假设是正确的。如果没有，或者您有更多问题，请随时联系我们的支持人员。