面向微服务类型消费者的 Azure 服务总线主题和订阅设计

Question

我正在考虑使用 Azure 服务总线在应用程序中的不同服务之间发布/传递消息，并尝试为服务总线命名空间内的主题和订阅找到合适的设计。

系统的目的是让 service-a 将类型为 service-a.test-event 的消息发布到总线，并让任何服务监听该事件类型获取消息传递。这将是一个相当低的体积

我对使用以下哪种设计有点犹豫:

1. 服务总线命名空间有一个主题事件，来自所有服务的所有消息都会传递到该主题。订阅来自任何其他服务的事件的任何服务都会使用过滤器在此主题中创建订阅，以获取所需的消息类型 -​​ 每种消息类型一个订阅(例如，service-b-service-a-test-event) >).
2. 服务总线命名空间为每个发布者分配一个主题(例如events-service-a)。从此服务中订阅事件的任何服务都会使用过滤器在主题中创建订阅，以获取所需的消息类型 -​​ 每种消息类型一个订阅(例如 service-b-test-event)。<

服务总线似乎每个主题有 2000 个订阅的限制，据我所知，这对我们来说已经足够了。如果我有其他怀疑，选项 #2 可能是最好的选择(因为每个命名空间可以有 10,000 个主题)。据我所知，服务总线的其他限制都不会真正影响我应该选择哪些选项。

一个额外的要求是，出于记录原因，我希望有一个服务从任何服务订阅任何事件。如果我选择选项#1，那么实现起来会非常简单。然而，对于选项#2，该服务需要以某种方式确保它在命名空间中的任何事件主题中都有订阅，并在添加新主题和删除旧主题后重新配置自身。这超出了这个问题的范围，但仍然是设计的要求。

Answer 1

在决定拓扑时，请考虑对您最重要的事情。发布/订阅的原则之一是发布者和订阅者之间的解耦。对于拓扑 #2(每个发布者有一个主题)，这个原则被违反了，因为每个订阅者都必须知道发布者的名称。 如果事件的发布者发生变化，所有订阅者都必须了解该信息才能重新订阅。拓扑 #1 通过使用单个主题将发布者抽象出来解决了这个问题。

此外，您的第二个要求(审核所有事件)使用此拓扑会更容易实现，因为您只需维护该主题的单个窃听订阅。

您关于每个主题 2000 个订阅的限制是正确的。这么说来，2000个订阅已经不少了。一旦您的系统达到一定数量的订阅者，您可能无论如何都需要检查您的架构/拓扑。

这两种拓扑听起来与 Azure 服务总线上作为传输的 NServiceBus 极其相似 topologies 。您可以查看可用于拓扑的其他一些想法，包括 benefits一个比另一个。

免责声明:我正在研究 NServiceBus Azure 服务总线传输。您不必使用 NServiceBus，尽管当您使用 NServiceBus 时，许多问题(例如您在此处发布的问题)就不再是问题了。