我们的基础架构由
组成我们有一个使用 websockets 的应用程序，所以当用户访问我们的网站时，它会打开一个 websocket 到平衡器，它连接到第一个可用节点，并且它按预期工作。
我们的任务是带着维护任务来的，当我们必须更新我们的软件时，我们需要一次离线 1 个节点，部署新版本，然后再次打开它。执行此任务时，平衡器会断开与节点的打开 websocket 连接，客户端会在几秒钟后重试连接到第一个可用节点，这会给客户端带来不便，因为他可能会错过信号（或更多）。
我们如何保持客户端和平衡器之间的连接，改变后端 websocket 服务器？负载均衡器是否足以实现我们的目标，还是我们需要更改我们的基础架构？
【问题讨论】：
标签： websocket socket.io signalr load-balancing f5
为避免此类问题，我建议阅读Azure SignalR。有了这个，你就不需要处理负载均衡器、redis 背板和其他基础设施等你可能需要WebSockets 连接的东西。
基本上，客户端不会直接连接到您的节点，而是重定向到 Azure SignalR。你可以在这里阅读更多信息：https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-overview
由于保持连接对您的应用程序很重要，因此我看不出有任何其他方法可以存档没有连接到您的节点的断开连接，因为您需要关闭它们。
【讨论】：
了解 F5 是一个完整的 TCP 代理很重要。这意味着 F5 是服务器到客户端，客户端到服务器。如果您使用的是 websockets 协议，那么您必须将 websockets 配置文件应用到 F5 虚拟服务器，以便负载均衡器正确处理 websockets 应用程序。
可以在此处找到 websockets 配置文件的详细信息：https://support.f5.com/csp/article/K14754
如果将 websockets 和 HTTP 配置文件应用于虚拟服务器 - 这意味着您有 websockets 和 web 流量使用相同的端口和 LB 节点 - 那么 F5 将允许 websockets 流量作为直通。另请记住，如果这是一个 HTTPS 虚拟服务器，您需要确保将客户端和服务器端 HTTPS 配置文件（SSL 卸载）应用于虚拟服务器。
【讨论】：
虽然您可以通过多种方式调整负载平衡器以最大程度地减少软件升级导致的停机时间，但它们都不能解决问题，即您的应用层协议似乎无法容忍一些小的网络中断.
即使您有一个完美的负载平衡器并且您的软件部署导致零停机，客户的计算机也可能在不稳定的 wifi 上导致网络中断半秒 - 或者通过以太网并且有人在他们的 LAN 上重新配置了一些路由，等等
我建议让您的服务器为客户端维护一个消息队列（最多有一定大小/时间限制），以便当客户端断开连接时 - 无论是由于负载平衡器/升级 - 还是任何其他原因，它可以继续运行而不会中断。
【讨论】：