我正处于设计我们的两个企业应用程序如何向 Azure 服务总线中的主题广播的高级结构的早期阶段。我是这项技术的新手，在初步阅读文档后，我很想使用一个简单的解决方案：为我们想要广播的每种不同的事件类型使用一个单独的主题。
我喜欢这个解决方案（而不是使用过滤器），因为它提供了对共享访问密钥的最精细控制、最少的消息吞吐量，并且还允许在每个主题的基础上轻松添加订阅删除。
另一种解决方案是使用更少的主题（向单个主题发送多个事件），然后配置过滤器来确定每条消息是否应该发送到订阅。从维护的角度来看，这似乎不必要地更复杂，也更不方便。当我可以创建数千个主题时，为什么还要使用过滤器？
任何人都可以就最佳方法提供反馈吗？
拓扑是一个有趣的话题（不是双关语）。
说到Azure Service Bus，我很习惯将消息分为两大类的概念
命令有一个单一的目的地和对工作的期望。它们携带足够的信息来执行工作，并且发送者通常希望看到响应。
事件旨在通知 N 个订阅者发生的事实，而无需携带太多信息或对接收者有任何期望。N 可以是一个或多个（甚至没有）订阅者。没有关于订阅者应该如何处理事件的期望，因此发布者和订阅者是分离的。
对于命令，我更喜欢队列。队列只能由单个逻辑接收者使用。没有机会将同一命令传递给多个逻辑接收者。这也有助于根据预期处理的负载/工作扩展/缩小接收器。这并不意味着它必须以这种方式实施。您可以通过单个订阅来完成一个主题并实现相同的目标。但这意味着消息需要在内部从主题“旅行”到订阅，这也是队列。这种方法的好处可能是插入额外的订阅者，但我会问这是否不是YAGNI场景。
对于事件，一个或多个具有多个订阅的主题。单个主题减少了耦合量——订阅者只需要知道那个主题而不是多个主题。
希望这些信息有所帮助。
任何人都可以就最佳方法提供反馈吗？
将其总结为听取所有建议，但根据您的需求验证这些建议。没有一种最好的方法，有一些选项可以帮助您获得满足系统需求的方法。
免责声明：我所描述的与NServiceBus 实现的拓扑非常一致，并添加了一些变体。