Azure服务总线-多主题与筛选主题

我已经使用许多应用程序订阅的主题将azure service bus的实现写入了我们的应用程序中。我们团队讨论的一个问题是，我们是坚持使用单个主题并通过消息的属性进行过滤，还是为我们的特定需求创建一个主题

我们的场景是，我们希望通过优先级和环境变量进行过滤（测试和uat环境共享一个连接）

那么我们有没有主题（比如）：

• 测试高
• 试验介质
• 测试流
• 乌塔赫
• 乌塔中
• 阿塔洛

或，只是将这些值设置为两个属性的单个主题

我的偏好是我们创建单独的主题，因为我们将利用可用的功能，我想在高负载下，这会更好地扩展？我读过，偷看大队的人效率很低。订阅一个主题似乎也更干净

---

任何建议都将不胜感激。

任何一种方法都有效。更多的主题和订阅意味着您在部署时要管理更多的实体。如果高/中/低反映优先级，那么多个主题可能是更好的选择，因为您可以首先从优先级最高的订阅中提取

从可伸缩性的角度来看，您不会注意到有太大的差异，因为服务总线已经在内部将负载分散到多个日志中，所以如果您使用六个主题或两个主题，将不会产生实质性的差异

---

影响性能可预测性的是服务类别的选择。如果选择“标准”，则吞吐量和延迟是共享多租户基础架构上的最佳选择。同一群集上的其他租户可能会影响您的吞吐量，您可以获得可预测性能的环网资源，并且您的两个或六个主题可以从该资源池中得到处理

我会针对每个环境分别讨论不同的主题。它更干净。可以针对每个环境分别监控主题中的消息计数。它的可伸缩性稍高一些（例如，主题大小限制不会被共享），但这些限制非常宽泛，在测试中也不会有多大影响

但我的主要论点是：这就是生产（希望）的方式。和中一样，生产将在ASB中有自己的连接（和名称空间），并且将有单独的主题。因此，您不会在生产中通过属性过滤消息，那么为什么在测试中会有不同的做法呢

---

最后一个提示：为了使主题设置更容易，我建议让你的应用程序在启动时自动创建它们。这很容易做到——检查它们是否存在，如果不存在则创建。

我们最终决定走这条路。您关于跨环境过滤相同内容的观点是正确的。另外，我们已经根据应用程序启动时的配置生成了主题，这使得测试更容易，因为我们可以根据需要删除订阅。