嘿，这个问题问到点子上了——WebSocket的长连接特性确实给服务器滚动升级带来了不小的挑战，我来给你拆解下AWS ALB和NLB在这方面的实际能力：

ALB的行为 #

ALB是七层负载均衡，它不支持主动迁移已建立的WebSocket连接。当你把实例A从目标组中移除后，ALB会立刻停止将新的客户端请求转发给A，但已经存在的WebSocket连接会保持在客户端和A之间，直到连接自然关闭、超时，或者实例主动断开。ALB并没有接管这些连接的能力，所以没法把它们“转移”到实例B上。

NLB的行为 #

NLB作为四层负载均衡，逻辑更偏向于IP层的转发，同样无法迁移已有的TCP（包括WebSocket）连接。当实例A被移出目标组后，NLB会停止将新连接导向A，但已建立的连接会直接在客户端和A之间维持，直到某一端主动断开。NLB同样没有连接迁移的功能。

可行的替代方案 #

既然ELB没法帮你迁移连接，那可以结合以下方案实现无感知升级：

• 服务器端优雅下线逻辑：在你的应用里实现优雅关闭机制。当要升级实例A时，先把它从ELB目标组移除（停止接收新连接），然后让实例A主动向所有连接的客户端发送“即将下线，请重新连接”的通知。客户端收到后发起新连接，这时ELB会自动转发到正常运行的实例B。等实例A上的所有连接都断开后，再进行升级操作。
• 进程级连接托管：就是你之前提到的，在应用里实现将现有连接委托给子进程的逻辑。比如在升级主进程前，把当前持有的WebSocket连接传递给一个守护子进程，让它继续维持连接；等主进程升级完成后，再把连接迁回主进程。这种方式需要你在应用层面做定制开发，但能实现真正的无中断升级。
• 客户端重连机制：无论用哪种方案，客户端都最好实现自动重连逻辑。毕竟网络环境复杂，偶尔的断开重连是正常的，这也能提升整体服务的鲁棒性。

总结 #

你的思路里，ELB可以帮你控制新连接的路由，但没法迁移已有的WebSocket连接。结合ELB的实例上下线能力，再加上服务器端的优雅下线和客户端的重连逻辑，就能实现用户无感知的滚动升级了。

备注：内容来源于stack exchange，提问作者cifer