Azure 中的 SignalR：如何使用特定服务模式进行横向扩展？答案

【问题标题】：SignalR in Azure: how can I scale out with the Specific Service pattern?Azure 中的 SignalR：如何使用特定服务模式进行横向扩展？
【发布时间】：2014-12-03 21:03:57
【问题描述】：

我们正在开发一个系统，该系统使用 SignalR 推送一些业务重要指标的频繁更新。我们将拥有中等数量的连接客户端，从 50 个到 1000 个不等，每个客户端都需要一个唯一的有效负载。

根据 Damian Edwards 的演讲，我们的负载配置文件最符合特定服务器横向扩展模式，在这种模式下，我们基本上分配客户端连接到拓扑中的特定 SignalR 服务器，而不是使用背板。

关于其工作原理的粗略伪代码是，客户端在我们的负载平衡 API URL 上执行 GET，无论哪个服务器被击中，都会使用其 URL 进行响应，然后客户端将 SignalR 客户端库配置为使用该 URL 进行连接。

这看起来可以很好地在本地运行，但现在我们也在计划 Azure 部署。如果没有此要求，Azure 网站非常适合。但是，这种模式要求我们能够可靠地识别网站中的各个实例，而我们认为没有办法做到这一点。

这只是破坏了 Azure 网站提供的抽象吗？我们是否必须使用 VM 或 Web 角色来为每个 SignalR 实例获取可靠、一致的 IP 或可寻址 URL？或者人们是否有另一种方式将 SignalR 与特定服务器部署到 Azure。

【问题讨论】：

使用虚拟机，它将是文件。基于同样的谈话，你的方向是正确的，只需使用虚拟机，它会给你更多的控制权。尝试使用 Azure 分配的 VM url，例如 companyname_node01.cloudapp.net
感谢法鲁克。正如你所说，看起来我们可以使用虚拟机或云服务并获得一个已定义的、可寻址的 URL 以用于特定服务器设计

标签： azure signalr azure-web-roles azure-web-app-service signalr-backplane

【解决方案1】：

默认的 Azure 网站行为实际上可能适合您。

Azure 网站在客户端第一次请求后将关联性令牌保存为 cookie。该关联令牌可确保来自该客户端的所有未来请求都被路由到网站的同一实例。

如果您出于某种原因真的想自己处理负载平衡，那也是可能的。有一个 API 可让您获取所有站点实例的关联令牌。

【讨论】：

Zain，感谢您提供有关亲和力令牌的信息。听起来似乎有道理，但我们对完全依赖亲和力令牌持谨慎态度。似乎是 Azure 实例内负载平衡的实现细节，我们可能会改变。
@PeterM 我的主要观点是，你想要的是 Azure 网站的默认行为，并且它在未来不太可能改变（太多人依赖这种行为来改变它） .我可以看到您可能会发现自己直接处理亲和令牌的风险更大，但是如果您将其作为幕后实现细节而忽略它，并理解默认行为可以满足您的需求，那么您将获得更稳定的情况。
感谢您的澄清。在设计我们的本地系统时，我们通常避免依赖粘性会话，但正如您所说，也许我们会重新考虑 Azure。