将NServiceBus与Azure服务结构一起使用

我已经阅读了StackOverflow上关于在SF上使用NSB的其他问题，以及github上的示例（过时），我仍然不确定如何为此平台正确配置NServiceBus

我希望设置一个只发送发布/订阅工作流。通过我的研究，我无法确定的是如何设置它，以便只有一个特定服务的实例响应消息

例如：在标准的5个节点上运行3个服务（假设3个服务中的每一个都有5个实例）

现有负载平衡器将http请求路由到服务a的特定实例

服务A发布“OrderComplete”事件

服务B和C都订阅该活动

如何确保只有服务B和C的一个实例响应，而不是服务B的所有5个实例和服务C的所有5个实例响应

所有服务当前都是无状态服务

---

我正在考虑使用AzureServiceBus或AzureStorageQueue传输。

在github上的NSB/SF示例中，有一个处理命令的有状态服务。重要的是，在应用程序中，它有一个

PartitionCount=1

。我见过的所有其他NSB解决方案也是如此，每个服务只有一个分区或实例来处理消息。否则，按照您所描述的，每个消息的每个实例都会有一个订阅

也许您可以采用分发服务器来实现同一服务的多个实例之间的负载平衡，但afaik分发服务器仅与MSMQ配合使用，因此您必须重写它以与SF和Azure服务总线配合使用

---

如果您坚持使用单个实例，它应该对您很好。您仍然可以从SF中获得一些好处，因为它可以确保您的服务正常运行，但多个实例之间的负载平衡需要您做一些工作。

无状态方法很好。您不需要使用单个分区进入有状态服务，除非您希望为您的服务利用可靠的集合。但让我们看看这两种选择

使用无状态服务

您的服务可以有多个实例。是的，它们都将创建订阅。我认为这正是你想要的-。您拥有的服务实例越多，您将获得更多的吞吐量，即处理更多的消息

通过我的研究，我无法确定的是如何设置它，以便只有一个特定服务的实例响应消息

由于竞争性消费者运输的性质（和），这将自动发生

使用有状态服务

对于有状态的服务，您需要非常小心。是的，您可以为每个服务使用一个分区，因此有一个主副本来处理您的消息。但是，可以说，您没有将集群资源用于并发处理许多消息，这是在浪费集群资源。如果您决定对服务进行分区，那么您将无法使用可靠的集合作为服务的副本不要在它们之间共享可靠的集合。如果您选择使用不带可靠集合的分区有状态服务，那么您最好使用无状态对等服务

---

注意：NSB将支持使用有状态服务运行，以利用可靠的集合满足持久性需求，但即使如此，分区也需要完成，以符合业务需求。如果你没有这样的需求，我建议你坚持使用无状态服务。

你有没有以某种方式得到过答案？@CrusherJoe我相信它的主要部分是使用主题。为服务a创建一个主题订阅，然后处理该订阅事件的第一件事就赢了，除非您创建了单独的订阅，否则所有实例都没有机会处理该消息。总之，多个订阅支持多个东西来处理单个消息（主题）。正如下面的回答所述，服务的所有实例都将充当竞争消费者。NServiceBus SF persistence repo：