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

Posted 2023-03-10

【中文标题】使用 Azure 服务总线的可扩展请求响应模式

【英文标题】：Scalable Request Response pattern using Azure Service Bus

【发布时间】：2018-02-07 22:57:21

【问题描述】：

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

请求队列

响应队列

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

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

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

这将有两个缺点：

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

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

请分享你的想法。

提前致谢

【参考方案1】：

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

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

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

【参考方案2】：

我知道这是旧的，但我认为我应该发表评论以完成此线程。

我同意肖恩的观点。 原则上，不要在设计时考虑实例亲和力。 无论实例的数量和运行代码的实例如何，任何设计都应该有效。 在设计在云中运行的应用程序架构时，Microsoft 确实建议这样做。

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

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