当有一堆充当 WebSocket 无人机的系统和这些无人机前面的负载均衡器时。当 WebSocket 请求进入 LB 时，它会选择一个 WebSocket 无人机，并建立 WebSocket。 （我在 ELB 上使用 AWS ELB tcp SSL 终止）
问题：现在创建的WebSocket是经过LB，还是LB将WebSocket请求转发给WebSocket无人机，从而客户端和WebSocket无人机之间有直接链接？
如果WebSocket连接经过LB，这将使LB成为一个巨大的瓶颈。
删除 LB 并为客户端提供 WebSocket 无人机的直接 IP 可以绕过这个瓶颈，但需要我自己创建这个逻辑，我打算这样做（取决于这个问题的答案）。
那么我对它的工作原理的想法是否正确？
AWS ELB 作为 LB
看完之后可能重复 https://stackoverflow.com/questions/15266702/proxying-websockets-with-tcp-load-balancer-without-sticky-sessions建议来自Pavel K https://stackoverflow.com/users/1948038/pavel-k我得出的结论是，WebSocket 连接将通过 AWS ELB，如下所示：
Browser <--WebSocket--> LB <--WebSocket--> WebSocketServer
这使得ELB成为瓶颈，我想要的是：
Browser <--WebSocket--> WebSocketServer
其中 ELB 仅用于为客户端提供可用 WebSocketServer 的主机名/IP。
DNS 作为负载均衡
上述问题可以通过 DNS 级别的平衡来规避，如可能重复 https://stackoverflow.com/questions/15266702/proxying-websockets-with-tcp-load-balancer-without-sticky-sessions。这样，当 ws.myapp.com 被请求时，DNS 将给出可用 WebSocketServer 的 IP。
缺点是，这需要通过上/下 WebSocketServer 更改不断更新 DNS（如果您的应用程序具有弹性，这将成为一个更大的问题）。
定制LB
另一种选择是创建一个自定义 LB，持续监视 WebSocketServer，并在客户端请求时返回可用 WebSocketServer 的 IP。
缺点是客户端需要执行单独的 (AJAX) 请求来获取可用 WebSocketServer 的 IP，而使用 AWS ELB 时，负载平衡会隐式发生。
结论
选择更好的邪恶..
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
