websocket - AWS Application Load Balancer 如何在目标组中选择目标？如何对websocket流量进行负载均衡？

Question

我有一个 AWS 应用程序负载均衡器来分配 http(s) 流量。

问题1:

假设我的目标组有 2 个 EC2 实例:micro 和 xlarge。显然他们可以处理不同的流量水平。负载均衡器是否根据实例大小按比例管理流量，还是只是循环管理？如果只使用循环而不考虑其他因素，那么它并不能真正平衡负载，因为在某些时候，micro 实例会受到流量的影响，而 xlarge 则会挨饿。

问题2:

假设我的目标组有 2 个 EC2 实例，两者大小相同。但我的服务没有使用经典的 http 请求/响应流程。它使用 HTTP websockets，即客户端仅发出一次 HTTP 请求来建立套接字，然后保持套接字打开更长时间，发送和接收消息(例如聊天服务)。假设我的负载均衡器使用循环法，并且两个 EC2 实例各自连接了 1000 个客户端。现在假设其中一个 EC2 实例发生故障，并且 1000 个已连接的客户端断开了它们的套接字连接。实例快速恢复并准备好再次接受 websocket 调用。掉线的 1000 个客户端正在尝试重新连接。现在，如果负载均衡器使用纯循环，我最终将有 1500 个客户端连接到实例 #1，500 个客户端连接到实例 #2，因此无法真正正确地平衡负载。

基本上，我试图找出是否使用了一些更高级的逻辑来选择组中的目标，或者这只是一个简单的循环选择。如果只是循环，那么我如何才能真正平衡 websocket 连接负载？

Answer 1

Websockets 以 http 或 https 连接开始，因此负载均衡器可以将它们分派(dispatch)到服务器。一旦服务器接受http连接，服务器和客户端都会“升级”该连接以使用websocket协议(protocol)。然后，他们将连接保持开放状态以用于 Websocket 流量。据负载均衡器所知，该连接只是一个持久的 http 连接。

当服务器与客户端有 Websocket 连接时关闭服务器需要您的应用程序重试丢失的连接。连接失败时重新连接是 websocket 客户端编程中最棘手的部分之一。如果没有重新连接逻辑，您的应用程序就不可能健壮。

AWS 的负载均衡器对其背后服务器的功能没有内置了解。您已经观察到它向大型和小型服务器平等地发送请求。这可能会让 child 子不知所措。

我通过在我的服务器中构建/healthcheck端点来管理这个问题。很简单https://example.com/heathcheck网页。您可以在页面上放置一些内容，宣布当前打开了多少个 Websocket 连接，或者其他任何内容。不要使用密码保护它或需要 session 才能访问它。

我的/healthcheck 端点每当命中时都会测量服务器负载。我只是使用当前 websocket 连接的数量，但您可以使用任何您想要的指标。我将当前负载与为每台服务器配置的负载阈值进行比较。例如，在微型实例上，我可以处理 20 个打开的 Websocket，在生产实例上，我可以处理 400 个。

如果服务器负载太高，我的端点会返回 503 http error status及其内容。 503 通常表示“我重载，请稍后再试”。它也可能意味着“当我的所有连接都关闭时，我将关闭。请不要再使用我进行任何连接。”

然后我 configure the load balancer每隔几分钟对服务器池中的所有服务器执行这些运行状况检查(AWS 将该池称为“目标组”)。运行状况检查操作检测到“不健康”的服务器并暂时将其从轮换中删除。 (健康检查还可以检测到崩溃的服务器，这很好。)

您需要针对大规模生产设置进行此负载均衡器运行状况检查。

尽管如此，如果池中的所有服务器实例的容量大致相同，您将获得最佳结果。