Azure Signal R如何处理应用程序服务器扩展？

Question

我们有一个正在修改的现有Web服务，以便当服务中发生某些事件时，可以将它们发布给感兴趣的用户。我们使用Azure Signal R Service作为将消息从我们的服务中继到感兴趣的用户的机制。当前，我们的架构如下所示：

• 我们的Signal R应用程序服务器只有一个集线器，我们目前正在运行该应用程序服务器的三个实例。在上面的图中，我已经标记了这些 Hub实例01 ， Hub实例02 和 Hub实例03 。
• 我们现有Web服务的每个实例都打开一个与Azure Signal R服务的连接。阅读Azure SignalR Service internals文档之后，我了解到与Azure Signal R服务的每个客户端连接都通过一次性映射到应用程序服务器（在这种情况下为集线器实例）。在图中，我通过显示来自现有Web服务实例或用户的彩色链接以及来自Azure Signal R服务并进入单个集线器实例的具有相同颜色和样式的另一个链接来建模。

我们主要担心的是，如果我们尝试从现有Web服务实例到Azure Signal R服务（图中的绿色和蓝色实心链接）的连接可能会饱和。发送太多事件。我们减轻这种担忧的计划是打开从每个Web服务实例到Azure Signal R服务的多个连接。然后，在我们的代码中，我们将在发送消息时简单地遍历每个连接。

我们对该方法的关注在于，我们不知道与Azure Signal R服务的那些连接将如何映射到集线器实例。我们最终可能会遇到以下情况，其中一个或两个集线器实例最终会受到我们流量的冲击。

在此图中，我们可以看到：

• 现有Web服务的每个实例都打开了与Azure Signal R服务的多个连接。不幸的是，已为集线器实例01 和集线器实例03 分配了大多数连接。这意味着他们将首当其冲地吸引我们的流量，并最终开始火爆。

这使我想到以下问题：

1. 在现有的Web服务中我们可以做些什么以确保我们与Azure Signal R服务建立的连接均匀地分布在Hub实例上吗？
2. 如果我们的一个集线器实例开始运行时该怎么办？似乎仅添加另一个集线器实例将无济于事，因为只会将新客户端分配给该实例。当新的集线器实例上线时，是否可以使Azure Signal R服务重新平衡连接？
3. 如果应用程序服务器实例出现故障（即用于部署更新），客户端连接将受到什么影响？客户端连接是否终止，然后应该重新连接客户端？
4. 在Azure Signal R服务中，如果Signal R Service群集本身需要扩大或缩小，连接如何平衡？

Answer 1

我们正面临一个类似的问题，根据我在the Microsoft docs中所读到的内容，他们建议使用Redis或服务总线将背板整合到体系结构中以管理连接。