SignalR 横向扩展与 Azure 的聊天场景

Question

对于聊天应用程序，我使用带有 SignalR 的 Azure 架构，网络角色充当 SignalR 服务器（消息不是广播类型，而是针对特定用户/客户端）。

我想将 SignalR 服务器与 Web 角色一起横向扩展，以处理繁重的用户负载。虽然，SignalR 文档不建议在消息数量随着更多用户连接（或在用户事件驱动的场景中）增加的情况下使用使用背板（Redis、服务总线）的预烘焙 SignalR 横向扩展方法。它明确指出：“客户端到客户端（例如，聊天）：在这种情况下，如果消息数量与客户端数量成比例，那么背板可能会成为瓶颈；也就是说，如果消息的速率增长随着更多客户的加入，成比例地增加。”

问题： 有谁知道针对这种高频情况的任何自定义横向扩展解决方案，它不会将消息推送到每个服务器实例或其他横向扩展解决方案？

已经在 SignalR 文档和相关视频中到处寻找，但找不到任何东西，除了一个词“filtered-bus”，没有解释它是什么以及应该如何使用它。

Answer 1

我自己想通了：基本概念是服务器关联/粘性会话。

每个 web-role 实例都充当独立的 SignalR 服务器。在第一次连接时，我让 Azure 负载均衡器选择任何 web-role 实例，并将该 web-role 实例的 IP 地址与客户端标识符一起保存在映射中。如果有来自同一个客户端的另一个连接请求（例如在页面刷新后），那么我检查当前角色实例的 IP 地址，如果它与映射中的条目匹配，那么我让它继续，否则我断开客户端并将其连接到正确的网络角色实例。

工作角色的每个实例还充当 SignalR .net 客户端，并连接到所有可用的 SignalR 服务器（所有 Web 角色实例）。在向 SignalR 服务器（网络角色）发送消息之前，我在地图中查找以确定正确的 SignalR 服务器实例（取决于预期的 JS 接收者）。

好处：

• 不需要背板技术（因此不会延迟消息传递）。

• 每个 web 角色实例都关心连接到它的客户端，并且不必在每个 SignalR 服务器上复制每条消息。因此它可以很好地扩展。

• 易于实施。