我们正在评估" Azure Service Bus"，以在Web服务器和App Server之间用于请求响应模式。我们计划有两个队列：
请求队列
响应队列
Web服务器将推出一条消息以请求队列并订阅响应队列。通过比较MessageID和CORTERELATIONID，它可以接收回响应，可以将其发送回浏览器。
但是，在云上，使用弹性缩放，我们可以增加/减少Web服务器（和应用程序服务器）实例。我们想知道这种模式在这里是否最佳起作用。
要使这项工作，我们将必须有一个请求队列和多个主题（每个Web服务器实例一个）。
这将有两个下降：
以及增加/减少Web服务器实例，我们将拥有 也创建/删除主题。
所有消息将被推到 所有主题。因此，所有网络都会由所有网络处理 服务器。这不是一种有效的方法。
请分享您的想法。
预先感谢
缩放端点时，您不想具有实例亲和力。您想依靠竞争的消费者，而不在乎端点处理消息的哪个实例。
例如，如果您收到响应并将其写入数据库，则很可能您不在乎端点的实例已写入数据。但是，如果您有一些内存状态或仅适用于端点的任何其他信息，这些信息始于请求和处理答复消息需要该信息，那么您具有实例亲和力，并且需要将其删除或使用允许解决该信息的技术。例如，像带有背板的信号一样，将回复消息传达给您所有的Web端点实例。
请注意，理想情况下，您应该尽可能避免实例亲和力。
我知道这是旧的，但是我认为我应该评论以完成此线程。
我同意肖恩。原则上，不要考虑实例亲和力设计。任何设计都不论实例数量以及运行代码的哪个实例，任何设计都应有效。在设计用于在云中运行的应用程序体系结构时，Microsoft确实推荐了相同的建议。
在您的情况下，我认为您不应该计划每个实例有一个主题。您应该只将请求消息放入一个主题，并订阅以允许您的接收应用服务处理这些请求消息。当您的接收应用服务缩放时，您的设计需要允许从多个接收器（多个实例）中读取订阅消息的地方，这在竞争消费者模式中进行了描述。https://learn.microsoft.com/en-us/azure/architecture/patterns/competing-consumers
请发布您最终实施的内容。