使用Azure Service Bus

Question

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

请求队列

响应队列

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

但是通过云，使用弹性扩展，我们可以增加/减少Web服务器（和应用服务器）实例。 我们想知道这种模式是否能在这里得到最佳效果。

为了使这项工作，我们必须有一个请求队列和多个主题（每个Web服务器实例一个）。

这将有两个不利方面：

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

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

请分享您的想法。

提前致谢

Answer 1

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

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

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

Answer 2

我知道这已经很老了，但我想我应该发表评论以完成此话题。

我同意肖恩的观点。 原则上，不要在设计时考虑实例相似性。 任何设计都应工作，而与实例数量无关，无论哪个实例运行代码。 在设计用于在云中运行的应用程序体系结构时，Microsoft确实建议这样做。

就您而言，我不认为您应该为每个实例计划一个主题。 您应该将请求消息放到一个主题中，并进行订阅以允许您的接收应用程序服务处理这些请求消息。 当您的接收应用程序服务扩展时，这是您的设计需要允许从多个接收者（多个实例）的订阅中读取消息的方式，这在“竞争消费者”模式中进行了描述。 https://docs.microsoft.com/en-us/azure/architecture/patterns/competing-consumers

请发布您最终实现的内容。