WebSockets和负载均衡是一个瓶颈？

Question

当有一堆系统充当WebSocket无人机和负载均衡器在这些无人机前面.当WebSocket请求进入LB时,它选择一个WebSocket无人机,并建立WebSocket.(我在ELB使用SSL ELB tcp SSL终止)

问题: 现在创建的WebSocket是否通过LB,或者LB是否将WebSocket请求转发到WebSocket无人机,因此客户端和WebSocket无人机之间存在直接链接？

如果WebSocket连接通过LB,这将使LB成为一个巨大的瓶颈.

删除LB并向客户端交付WebSocket无人机的直接IP可以绕过这个瓶颈,但需要自己创建这个逻辑,我打算这样做(取决于这个问题的答案).

关于这是如何正确的,我的想法是什么？

Answer 1

AWS ELB 作为 LB

在查看Pavel K建议的可能重复项后，我得出结论，WebSocket 连接将通过 AWS ELB，如下所示：

Browser <--WebSocket--> LB <--WebSocket--> WebSocketServer

这使得 ELB 成为瓶颈，我想要的是：

Browser <--WebSocket--> WebSocketServer

ELB 仅用于为客户端提供可用 WebSocketServer 的主机名/IP。

DNS 作为 LB

上述问题可以通过在 DNS 级别上进行平衡来规避，如可能的重复 中所述。因为这样 DNS 将在请求 ws.myapp.com 时提供可用 WebSocketServer 的 IP。

不利的一面是，这将需要通过向上/向下 WebSocketServer 更改不断更新 DNS（如果您的应用程序具有弹性，这将成为一个更大的问题）。

定制LB

另一种选择可能是创建一个自定义 LB，它不断监视 WebSocketServers 并在客户端请求时返回可用 WebSocketServer 的 IP。

缺点是客户端需要执行单独的 (AJAX) 请求来获取可用 WebSocketServer 的 IP，而使用 AWS ELB 时，负载平衡是隐式发生的。

结论

选择更好的邪恶..