azureservicebus - 设计 Azure 服务总线主题 - 您应该倾向于使用更多主题还是更多过滤器？

Question

我正处于设计高级结构的早期阶段，我们的两个企业应用程序将如何广播到 Azure 服务总线中的主题。我是这项技术的新手用户，在初步阅读文档后，我很想使用一个简单的解决方案:为我们想要广播的每种不同的事件类型使用单独的主题。

我喜欢这个解决方案(而不是使用过滤器)，因为它提供了对共享访问 key 的最精细的控制、最少的消息吞吐量，并且还允许在每个主题的基础上轻松添加删除订阅。

替代解决方案是使用较少的主题(将多个事件发送到单个主题)，然后配置过滤器来确定每条消息是否应发送到订阅。从维护的角度来看，这似乎不必要地更复杂并且更不方便。当我可以创建数千个主题时，为什么还要费心使用过滤器呢？

任何人都可以提供有关最佳方法的反馈吗？

Answer 1

拓扑是一个有趣的话题(没有双关语)。

说到Azure Service Bus，我非常习惯消息分为两大类的概念

1. 命令
2. 事件

命令有一个单一的目的地和工作期望。它们携带足够的信息来执行工作，并且发送者通常希望看到响应。

事件旨在向N个订阅者通知所发生的事实，而不携带太多信息或对接收者抱有任何期望。 N 可以是一个或多个(甚至没有)订户。对于订阅者应该如何处理事件没有期望，因此发布者和订阅者是解耦的。

对于命令，我更喜欢队列。队列只能由单个逻辑接收者使用。无法将同一命令传递给多个逻辑接收者。这也有助于根据接收器预期处理的负载/工作来扩展/扩展接收器。这并不意味着它必须必须以这种方式实现。您可以通过单个订阅来完成一个主题并达到相同的效果。但这意味着消息需要在内部从主题“传输”到订阅(也是队列)。这种方法的好处可能是插入额外的订阅者，但随后我会问这是否不是 YAGNI场景。

对于事件，一个或多个具有多个订阅的主题。单个主题减少了耦合量 - 订阅者只需要知道该主题而不是多个主题。

希望这些信息有帮助。

Can anyone provide feedback on the best approach?

将总结为听取所有建议，但根据您的需求验证这些建议。没有最好的方法，有一些选项可以帮助您找到满足系统需求的方法。

免责声明:我所描述的内容与 topologies 非常一致由 NServiceBus 实现，我添加了一些变体。