换句话说，如果我创建使用相当大量的消息传递实体（例如几千个）的消息传递布局，而不是更小的数量，那么Azure ServiceBus中的某些内容会因此而烦恼，并使其性能低于理想状态，或产生显着不同的成本。让我们假设两种情况下的消息数量大致保持不变。
因此，要明确我并不是要问从应用程序的角度来看，具有许多实体的消息传递布局是否合理，而是在Azure中有些在这种情况下表现不佳。如果它有优点（也许Azure可以更容易地扩展它），那也很有趣。
我知道单个ServiceBus命名空间中有10000个entites限制。
答案 0 :(得分：2)
我认为解决方案的编程和架构更重要 - 例如，我们看到了ACS（身份验证机制）的问题 - 当有很多请求时，SB开始限制客户端。 Take a look at the guidance about SB high availability - 列出了一些问题，当您有大量负载时，应该考虑这些问题。
而且，您总是有其他选项可以更适合高负载方案 - 例如，Azure事件中心，更轻量级的队列机制，旨在为极大量的消息提供服务。