面向微服务型消费者的 Azure 服务总线主题和订阅设计
Azure Service Bus topic and subscription design for microservice-type consumers
我正在研究将 Azure 服务总线用于我们应用程序中不同服务之间的 publishing/delivering 消息，并试图为服务总线命名空间内的主题和订阅找到一个合适的设计。
系统的目的是 service-a 将类型为 service-a.test-event 的消息发布到总线，并让任何侦听该事件类型的服务接收消息。这将是一个相当低的音量
我对使用以下哪种设计有点纠结：
- 服务总线命名空间有一个主题
events，所有服务的所有消息都在其中传递。订阅来自任何其他服务的事件的任何服务使用过滤器在该主题中创建订阅以获取他们想要的消息类型 - 每种消息类型一个订阅（例如 service-b-service-a-test-event）。
- 服务总线命名空间每个发布者有一个主题（例如
events-service-a）。任何订阅此服务事件的服务都会使用过滤器在主题中创建一个订阅，以获取他们想要的消息类型 - 每个消息类型一个订阅（例如 service-b-test-event）。
Service Bus 似乎对每个主题有 2000 个订阅的限制，据我所知这对我们来说已经足够了。如果我有其他怀疑，选项 #2 可能是最佳选择（因为每个名称空间可以有 10.000 个主题）。 None 服务总线的其他限制，据我所知，确实影响了我应该选择这些选项中的哪一个。
一个额外的要求是，出于记录的原因，我想要一个订阅任何服务的任何事件的服务。如果我选择选项 #1，那将非常容易实现。然而，对于选项 #2，该服务需要以某种方式确保它在命名空间中的任何事件主题中都有订阅 - 并在添加新主题和删除旧主题后重新配置自身。这超出了这个问题的范围，但是对设计的要求 none 越少。
在决定拓扑时，请考虑对您最重要的事情。 pub/sub 的原则之一是发布者和订阅者之间的解耦。对于拓扑#2（每个发布者的主题），这个原则是违反的，因为每个订阅者都必须知道发布者的名字。 如果 事件的发布者发生变化，您的所有订阅者都必须了解该信息才能重新订阅。拓扑 #1 通过使用单个主题将发布者抽象出来解决了该问题。
此外，您的第二个要求（审核所有事件）使用此拓扑会更容易实现，因为您只需维护一个关于该主题的窃听订阅。
您关于每个主题 2000 个订阅的限制是正确的。这么说吧，2000个订阅量已经不少了。一旦您的系统达到该订阅者数量，您可能仍想查看您的 architecture/topology。
这两种拓扑结构听起来与 Azure 服务总线上的 NServiceBus 非常相似，作为一种相互传输 topologies. You could have a look to see some of the other ideas you could use for your topology, including benefits。
免责声明：我正在处理 NServiceBus Azure 服务总线传输。您不必使用 NServiceBus，尽管很多问题（例如您在此处发布的问题）在您这样做时都不是问题。
我正在研究将 Azure 服务总线用于我们应用程序中不同服务之间的 publishing/delivering 消息，并试图为服务总线命名空间内的主题和订阅找到一个合适的设计。
系统的目的是 service-a 将类型为 service-a.test-event 的消息发布到总线，并让任何侦听该事件类型的服务接收消息。这将是一个相当低的音量
我对使用以下哪种设计有点纠结：
- 服务总线命名空间有一个主题
events，所有服务的所有消息都在其中传递。订阅来自任何其他服务的事件的任何服务使用过滤器在该主题中创建订阅以获取他们想要的消息类型 - 每种消息类型一个订阅（例如service-b-service-a-test-event）。 - 服务总线命名空间每个发布者有一个主题（例如
events-service-a）。任何订阅此服务事件的服务都会使用过滤器在主题中创建一个订阅，以获取他们想要的消息类型 - 每个消息类型一个订阅（例如service-b-test-event）。
Service Bus 似乎对每个主题有 2000 个订阅的限制，据我所知这对我们来说已经足够了。如果我有其他怀疑，选项 #2 可能是最佳选择（因为每个名称空间可以有 10.000 个主题）。 None 服务总线的其他限制，据我所知，确实影响了我应该选择这些选项中的哪一个。
一个额外的要求是，出于记录的原因，我想要一个订阅任何服务的任何事件的服务。如果我选择选项 #1，那将非常容易实现。然而，对于选项 #2，该服务需要以某种方式确保它在命名空间中的任何事件主题中都有订阅 - 并在添加新主题和删除旧主题后重新配置自身。这超出了这个问题的范围，但是对设计的要求 none 越少。
在决定拓扑时，请考虑对您最重要的事情。 pub/sub 的原则之一是发布者和订阅者之间的解耦。对于拓扑#2（每个发布者的主题），这个原则是违反的，因为每个订阅者都必须知道发布者的名字。 如果 事件的发布者发生变化，您的所有订阅者都必须了解该信息才能重新订阅。拓扑 #1 通过使用单个主题将发布者抽象出来解决了该问题。
此外，您的第二个要求（审核所有事件）使用此拓扑会更容易实现，因为您只需维护一个关于该主题的窃听订阅。
您关于每个主题 2000 个订阅的限制是正确的。这么说吧，2000个订阅量已经不少了。一旦您的系统达到该订阅者数量，您可能仍想查看您的 architecture/topology。
这两种拓扑结构听起来与 Azure 服务总线上的 NServiceBus 非常相似，作为一种相互传输 topologies. You could have a look to see some of the other ideas you could use for your topology, including benefits。
免责声明：我正在处理 NServiceBus Azure 服务总线传输。您不必使用 NServiceBus，尽管很多问题（例如您在此处发布的问题）在您这样做时都不是问题。