我们有一个我们正在修改的现有 Web 服务，以便当服务中发生某些事件时，它们可以发布给感兴趣的用户。我们使用 Azure Signal R 服务作为将消息从我们的服务中继到感兴趣的用户的机制。目前，我们的架构如下所示：
- 我们的 Signal R 应用程序服务器只有一个集线器，我们目前正在运行应用程序服务器的三个实例。我在上图中标记了这些Hub Instance 01、Hub Instance 02和Hub Instance 03 。
- 我们现有 Web 服务的每个实例都会打开一个与 Azure Signal R 服务的连接。在阅读了Azure SignalR 服务内部文档后，我了解到每个与 Azure Signal R 服务的客户端连接都通过一次性映射到应用程序服务器（或本例中的集线器实例）。在图中，我通过显示来自现有 Web 服务实例或用户的彩色链接以及来自 Azure Signal R 服务并进入单个集线器实例的相同颜色和样式的另一个链接来建模。
我们主要担心的是，如果我们尝试发送太多事件，从现有 Web 服务实例到 Azure Signal R 服务的连接（图中的纯绿色和纯蓝色链接）可能会变得饱和。我们减轻这种担忧的计划是打开从每个 Web 服务实例到 Azure Signal R 服务的多个连接。然后，在我们的代码中，我们将在发送消息时简单地循环遍历每个连接。
我们对这种方法的担忧是，我们不知道这些与 Azure Signal R 服务的连接将如何映射到 Hub 实例。我们最终可能会遇到如下情况，其中一两个 Hub 实例最终会首当其冲地占用我们的流量。
在这张图中，我们可以看到：
- 现有 Web 服务的每个实例都打开了与 Azure Signal R 服务的多个连接。不幸的是，已经为Hub Instance 01和Hub Instance 03分配了这些连接的大部分。这意味着他们将在我们的流量中首当其冲，最终将开始火爆。
这导致我提出以下问题：
- 我们可以在现有的 Web 服务中做些什么来确保我们与 Azure Signal R 服务建立的连接均匀分布在 Hub 实例中吗？
- 如果我们的 Hub 实例之一开始热运行，我们该怎么办？似乎只是添加另一个 Hub 实例并没有帮助，因为只会将新客户端分配给该实例。有没有办法在新的 Hub 实例上线时让 Azure Signal R 服务重新平衡连接？
- 如果应用服务器实例出现故障（即部署更新），客户端连接会受到怎样的影响？客户端连接是否终止，然后客户端应该重新连接？
- 在 Azure Signal R 服务中，如果 Signal R 服务集群本身需要扩展或缩减，如何平衡连接？