C# 针对聊天场景的Azure信号器扩展

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

我想扩展SignalR服务器和web角色，以处理沉重的用户负载。尽管如此，当连接更多用户时（或在用户事件驱动场景中），消息数量增加时，信号器文档不建议使用使用背板（Redis，Service bus）的预烘焙信号器横向扩展方法。它明确指出：“客户端到客户端（例如，聊天）：在这种情况下，如果消息数量随着客户端数量的增加而增加，则背板可能成为瓶颈；也就是说，如果消息的速率随着更多客户端的加入而成比例地增加。”

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

---

已经在信号器文档和相关视频中到处找过了，但除了一个词“filtered bus”（过滤总线）之外，什么都找不到。这个词没有解释它是什么以及应该如何使用。

我自己找到了：基本思想是服务器关联/粘性会话

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

worker角色的每个实例还充当signer.net客户端，并连接到所有可用的signer服务器（web角色的所有实例）。在向SignalR服务器（web角色）发送消息之前，我在映射中查找以确定正确的SignalR服务器实例（取决于预期的JS收件人）

好处：

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

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

• 易于实现

“断开客户端连接，并将其连接到正确的web角色实例。”您是如何在Azure中实现这一点的？假设您有4个角色实例，如何重定向客户端以连接到正确的实例？这些实例只有一个私有IP，因此我们不能基于公共IP重定向。此外，如果IP地址不匹配，我们也不能一直拒绝对其他实例的请求。如果服务器重新启动或更糟，重新映像，会发生什么情况？如果您能提供更多的细节，我将不胜感激。