我正在考虑使用Azure Service Bus在我们的应用程序中的不同服务之间发布/传递消息，并且正在尝试为Service Bus命名空间中的主题和订阅找到合适的设计 .
系统的目的是 service-a 将类型为 service-a.test-event 的消息发布到总线，并且监听该事件类型的任何服务都会传递消息 . 这将是一个相当低的量
我对使用以下哪种设计感到有些不满：
-
Service Bus命名空间有一个主题
events，其中传递了来自所有服务的所有消息 . 订阅来自任何其他服务的事件的任何服务都使用过滤器在此主题中创建订阅以获取他们想要的消息类型 - 每个消息类型一个订阅（例如service-b-service-a-test-event） . -
Service Bus命名空间每个发布者有一个主题（例如
events-service-a） . 对来自此服务的事件的任何订阅服务使用过滤器在主题中创建订阅以获取他们想要的消息类型 - 每个消息类型一个订阅（例如service-b-test-event） .
Service Bus似乎每个主题限制2000个订阅，据我所知，这对我们来说已经足够了 . 如果我有其他怀疑，选项＃2可能是最好的选择（因为每个命名空间我可以拥有10.000个主题） . 据我所知，服务总线的其他限制没有真正影响我应该选择哪些选项 .
另外一个要求是，我希望有一个服务订阅来自任何服务的任何事件，以便记录原因 . 如果我选择＃1选项，那么实现起来非常简单 . 但是，对于选项＃2，该服务需要以某种方式确保它在命名空间中的任何事件主题中都有订阅 - 并在添加新主题并删除旧主题后重新配置自身 . 这超出了这个问题的范围，但对设计的要求也是如此 .
1 回答
在决定拓扑时，请考虑最重要的事情 . pub / sub的一个原则是在发布者和订阅者之间分离 . 对于拓扑＃2（每个发布者的主题），这个原则是违反的，因为每个订阅者都必须知道发布者的名称 . 如果某个活动的发布者会发生变化，那么您的所有订阅者都必须获得该知识才能重新订阅 . 拓扑＃1通过使用单个主题抽象出版商来解决该问题 .
此外，您拥有的第二个要求（审核所有事件）将更容易实现此拓扑，因为您只需要在该主题上维护单个窃听订阅 .
你对每个主题2000个订阅的限制是正确的 . 说，2000订阅是相当多的 . 一旦您的系统达到了这个数量的订户，您可能想要检查您的架构/拓扑 .
这两种拓扑与Azure Service Bus上的NServiceBus非常相似，作为传输topologies . 您可以查看一些可用于拓扑的其他想法，包括benefits之一 .
免责声明：我正在开发NServiceBus Azure Service Bus传输 . 您不必使用NServiceBus，但是当您执行此操作时，许多问题（例如您在此处发布的问题）都不会成为问题 .