我正处于设计高级结构的早期阶段，我们的两个企业应用程序将如何广播到 Azure 服务总线中的主题。我是这项技术的新手用户，在初步阅读文档后，我很想使用一个简单的解决方案：为我们想要广播的每种不同的事件类型使用单独的主题。
我喜欢这个解决方案（而不是使用过滤器），因为它提供了对共享访问密钥的最精细的控制、最少的消息吞吐量，并且还允许在每个主题的基础上轻松添加和删除订阅。
另一种解决方案是使用较少的主题（将多个事件发送到单个主题），然后配置过滤器来确定每条消息是否应发送到订阅。从维护的角度来看，这似乎不必要地更复杂并且更不方便。当我可以创建数千个主题时，为什么还要费心使用过滤器呢？
任何人都可以提供有关最佳方法的反馈吗？
拓扑是一个有趣的话题（没有双关语）。
说到Azure Service Bus，我非常习惯消息分为两大类的概念
- Commands
- Events
命令有单一的目的地和工作期望。它们携带足够的信息来执行工作，并且发送者通常希望看到响应。
事件旨在向N个订阅者通知所发生的事实，而不携带太多信息或对接收者抱有任何期望。 N 可以是一个或多个（甚至没有）订户。对于订阅者应该如何处理事件没有期望，因此发布者和订阅者是解耦的。
对于命令，我更喜欢队列。队列只能由单个逻辑接收者使用。无法将同一命令传递给多个逻辑接收者。这也有助于根据接收器预期处理的负载/工作来扩展/扩展接收器。这并不意味着has以这种方式实施。您可以通过单个订阅来完成一个主题并达到相同的效果。但这意味着消息需要在内部从主题“传输”到订阅（也是队列）。这种方法的好处could正在插入更多订阅者，但随后我会问这是否不是YAGNI https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it设想。
对于事件，一个或多个具有多个订阅的主题。单个主题减少了耦合量 - 订阅者只需要知道该主题而不是多个主题。
希望这些信息有帮助。
任何人都可以提供有关最佳方法的反馈吗？
将总结为听取所有建议，但根据您的需求验证这些建议。没有最好的方法，有一些选项可以帮助您找到满足系统需求的方法。
免责声明：我所描述的内容与拓扑结构 https://docs.particular.net/transports/azure-service-bus/legacy/topologies由 NServiceBus 实现，我添加了一些变体。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
