使用Azure服务总线的可扩展请求-响应模式

我们正在评估“Azure服务总线”在web服务器和应用服务器之间用于请求-响应模式。我们计划有两个队列：

请求队列

响应队列

Webserver将消息推送到请求队列并订阅响应队列。 通过比较MessageID和CorrelationId，它可以接收返回的响应，并将其发送回浏览器

但在云上，使用弹性伸缩，我们可以增加/减少web服务器（和应用服务器）实例。 我们想知道这种模式是否能在这里发挥最佳作用

为了实现这一点，我们必须有一个请求队列和多个主题（每个web服务器实例一个主题）

这将有两个不利方面：

随着web服务器实例的增加/减少，我们将 创建/删除主题

所有消息将被推送到 所有的话题。因此，每一条信息都将由所有的网络进行处理 服务器。这不是一个有效的方法

请分享你的想法

---

提前感谢

当您扩展端点时，您不希望有实例关联。您希望依赖于竞争的消费者，而不关心端点的哪个实例处理消息

例如，如果您收到响应并将其写入数据库，则很可能您不关心端点的哪个实例写入了数据。但是，如果您有一些内存中的状态或任何其他信息，这些信息仅对发起请求的端点可用，并且处理回复消息需要这些信息，那么您就有实例关联性，需要删除它或使用允许解决该问题的技术。例如，类似于带有背板的信号器，用于向所有web端点实例传递回复消息

---

请注意，理想情况下，您应该尽可能避免实例关联。

我知道这是一个老问题，但我认为我应该注释以完成此线程

我同意肖恩的看法。 原则上，设计时不要考虑实例关联性。 任何设计都应该工作，不管实例的数量如何，也不管哪个实例运行代码。 微软在设计在云中运行的应用程序体系结构时也建议这样做

在你的情况下，我不认为你应该为每一个实例计划一个主题。 您应该将请求消息放在一个主题中，通过订阅允许您的接收应用程序服务处理这些请求消息。 当您的接收应用程序服务扩展时，您的设计需要允许从多个接收器（多个实例）读取订阅中的消息，这在竞争消费者模式中有描述。

请发布您最终实现的内容