我正在研究使用Azure Service Bus在我们的应用程序中的不同服务之间发布/传递消息，并且正在尝试为Service Bus命名空间中的主题和订阅找到一个不错的设计。
系统的目的是让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个主题）。据我所知，服务总线的其他限制没有真正影响我应该采用哪些选项。
另外一个要求是我希望有一个服务订阅来自任何服务的任何事件，以便记录原因。如果我选择＃1选项，那么实现起来非常简单。但是，对于选项＃2，该服务需要以某种方式确保它在命名空间中的任何事件主题中都有订阅 - 并在添加新主题并删除旧主题后重新配置自身。这不在这个问题的范围之内，但对设计的要求也是如此。
答案 0 :(得分：3)
在决定拓扑时，请考虑最重要的事情。 pub / sub的一个原则是在发布者和订阅者之间分离。对于拓扑＃2（每个发布者的主题），这个原则是违反的，因为每个订阅者都必须知道发布者的名称。并且如果事件的发布者会发生变化，那么所有订阅者都必须获得该知识才能重新订阅。拓扑＃1通过使用单个主题抽象出版商来解决该问题。
此外，您拥有的第二个要求（审核所有事件）将更容易实现此拓扑，因为您只需要对该主题维护一个窃听订阅。
您对每个主题的2000个订阅的限制是正确的。说，2000订阅是相当多的。一旦您的系统达到了这个数量的用户，您可能还是想要检查您的架构/拓扑结构。
这两种拓扑与Azure Service Bus上的NServiceBus非常相似，是一种传输topologies。您可以查看一下您可以用于拓扑的其他一些想法，包括benefits一个在另一个上面。
免责声明：我正在开发NServiceBus Azure Service Bus传输。你不必使用NServiceBus，尽管很多像你在这里发布的那样的问题在你这么做时都不会成为问题。