我正在尝试弄清楚 Amazon Web Services Elastic Load Balancing 如何不会造成停机。
Elastic Load Balancing 会每隔一段时间（通常为几秒钟）对您的服务器路径进行 ping 操作。如果它在规定的时间内（通常为一两秒）没有收到响应，它将使服务器脱机，并且不会再向该服务器发送任何流量，直到它重新上线为止。
我感到困惑的是，尽管该服务器将脱机，但 AWS Elastic Load Balancing 需要几秒钟才能 ping 到它，然后它才能真正脱机。我假设有一种方法可以消除需要 ping 的差距，只向真正活动的服务器发送流量，并消除 Elastic Load Balancing 向出现问题的服务器发送流量的可能性。我如何才能实现这一点并在我的应用程序中实现 0 停机时间？
答案1
网上对此存在矛盾的信息。一些资源说，如果在收到服务器响应之前超过默认的 60 秒超时，ELB 会重试请求，但这些只是少数。有人说 ELB 不会重试请求。AWS 文档没有说明 ELB 超时时会发生什么情况 - 这是一个相当重要的遗漏。根据我所读的内容，我倾向于认为，如果您的后端服务器超时，客户端会收到错误代码，可能是 408 超时。您应该对此进行测试，我下面的建议是基于此假设的。如果 ELB 重试，那么我下面的建议就是错误的。
由于缺乏重试，我认为使用 ELB 无法实现标准 Web 应用程序的预期。从更大的角度来看，您无法保证 100% 的可用性，这几乎是不可能的。您需要将可用性设置为现实水平，然后设计系统以实现此目标。例如，您可能有两个活跃区域，Route 53 进行具有故障转移的地理负载平衡。但是，您无法获得 100% 的可用性，因为它设置为测试并将请求发送到被认为健康的实例，而不是在请求失败时重试请求。
如果服务器宕机或超时，ELB 将不会重试请求。您必须放入自己的逻辑或负载均衡器，而这本身也可能会失败。AWS 之外的硬件可能有效，但不是一个好主意，而 AWS 内部的自己的负载均衡器则是一个坏主意，因为您不太可能创建像 ELB 一样可靠的负载均衡器。
我建议您集中精力使您的 Web / 应用程序服务器稳定、可扩展且无状态，以便可以根据需要进行扩大或缩小。