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 as LB

查看possible duplicate建议的Pavel K后，我得出结论，WebSocket连接将通过AWS ELB，如：

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

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

Browser <--WebSocket--> WebSocketServer

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

DNS为LB

如possible duplicate中所述，可以通过在DNS级别上进行平衡来规避上述问题。从那时起，当请求ws.myapp.com时，DNS将提供可用WebSocketServer的IP。

缺点是，这需要不断更新DNS，同时上调/下调WebSocketServer更改（如果您的应用程序具有弹性，这将成为一个更大的问题）。

自定义LB

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

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

<强>结论

选择更好的邪恶..