在 Amazon 上选择正确的负载均衡器： AWSapplication负载均衡器与 NGINX 增强版

2016 年 8 月，亚马逊网络服务 (AWS)推出了application负载均衡器，用于对 HTTP 和 HTTPS 流量进行第 7 层负载均衡。 新产品增加了AWS现有的第4层和第7层负载均衡器Elastic Load Balancer（正式更名为Classic Load Balancer）所缺少的几个功能。

一年后，AWS推出了网络负载均衡器，以改进第 4 层负载均衡，因此在 AWS 上运行高可用性、可扩展应用的用户可以选择以下选项：

• NGINX 开源和NGINX Plus
• 传统负载均衡器
• application负载均衡器(ALB)
• 网络负载均衡器(NLB)

在这篇文章中，我们回顾了 ALB 的功能，并将其价格和功能与 NGINX Open Source 和 NGINX Plus 进行了比较。

注意事项 –

 

• 有关支持的功能的信息截至 2020 年 7 月都是准确的，但可能会发生变化。
• 有关 NGINX Plus 和 Classic Load Balancer (以前称为 Elastic Load Balancer 或 ELB) 的直接比较，以及有关一起使用它们的信息，请参阅我们之前的博客文章。
• 有关使用 NLB 实现高可用性 NGINX Plus 部署的信息，请参阅我们之前的博客文章。

 

application负载均衡器的功能

ALB 与 Classic Load Balancer 或 NLB 一样，与 AWS 紧密集成。 亚马逊将其描述为第 7 层负载均衡器——尽管它不提供独立第 7 层反向代理和负载均衡器可以提供的全部功能、调整和直接控制。

ALB 提供了 Classic Load Balancer 所缺少的以下功能：

• 基于内容的路由。 ALB 支持基于请求 URL、主机标头以及请求中的字段（包括标准和自定义 HTTP 标头和方法、查询参数和源 IP 地址）进行基于内容的路由。 （请参阅ALB 文档中的“从 Classic Load Balancer 迁移的好处”。）
• 支持基于容器的应用。 ALB 改进了对托管在 Amazon EC2 容器服务 (ECS) 上的容器的现有支持。
• 更多指标。 您可以根据每个微服务收集指标。
• WebSocket 支持。 ALB 支持客户端和服务器之间的持久 TCP 连接。
• HTTP/2 支持。 ALB 支持 HTTP/2，这是传递受 SSL/TLS 保护的内容时更好的替代方案。

（有关 ALB 和 Classic Load Balancer 的完整功能比较，请参阅AWS 文档中的“产品比较”。）

对于那些苦苦挣扎于 Classic Load Balancer 有限功能集的 AWS 用户来说，ALB 是一个重要的更新，它在某种程度上满足了需要能够保护、优化和控制其 Web应用流量的高级用户的需求。 但是，它仍然没有提供专用反向代理（如 NGINX）和负载均衡器（如 NGINX Plus）的所有功能。

控制 AWS 流量的更好方法

用户可以在 AWS 上部署 NGINX Open Source 或 NGINX Plus 来控制和负载平衡流量，而不是使用 Amazon ALB。 他们还可以部署 Classic Load Balancer 或 Network Load Balancer 作为前端，以实现跨多个可用区域的高可用性。 该表比较了 ALB、NGINX 和 NGINX Plus 支持的功能。

笔记： 下表中的信息截至 2020 年 7 月是准确的，但可能会发生变化。

* NGINX 控制器现在是F5 NGINX 管理套件。

当然，您不应该通过功能清单来评估您的负载均衡选择，而应该通过评估您需要的功能来完美地交付您的应用，并具有高安全性、最大可用性和完全控制。

处理流量高峰

亚马逊的 Classic Load Balancer (以前称为 ELB) 对流量高峰的响应不佳。 负载均衡器实例会根据当前流量水平自动调整大小，当出现峰值时，ELB 可能需要几分钟才能做出响应并部署额外容量。 用户必须采用手动、基于表单的流程来在流量高峰到来之前请求额外资源（称为“预热”）。 由于 ALB 基于 NGINX，因此 ALB 实例可以处理更多的流量，但您仍可能会观察到响应流量高峰的扩展事件。 此外，流量激增会自动导致负载均衡器容量单元 (LCU) 的消耗增加，从而导致成本更高。

如果您自行部署和扩展负载平衡代理，则可以完全控制容量和成本。 NGINX 和 NGINX Plus 部署在标准的 Amazon 实例中，我们的尺寸指南给出了不同容量的实例类型的潜在峰值性能。 NGINX Plus 的定价对于所有实例大小都是相同的，因此部署多余容量来处理峰值是经济高效的，而且当需要更多容量时，可以快速部署更多实例 - 无需填写表格。

使用健康检查检测故障服务器

我们对 Amazon ALB 的测试表明它没有实施“被动”健康检查。 仅当异步测试验证服务器未返回预期的状态代码时，才会检测到服务器失败。

我们通过创建 ALB 实例对实例集群进行负载平衡发现了这一点。 我们配置了最低频率为 5 秒、最低阈值为 2 次失败检查的健康检查，并向 ALB 发送了稳定的请求流。 当我们停止其中一个实例时，对于某些请求，ALB 返回502坏网关错误持续几秒钟，直到健康检查检测到实例已关闭。 被动健康检查（NGINX 和 NGINX Plus 均支持）可防止最终用户看到这些类型的错误。

ALB 的运行状况检查只能通过检查 HTTP 状态代码来确定实例的运行状况（例如200确定或404未找到）。 这种健康检查不可靠；例如，一些 Web应用用用户友好的页面替换服务器生成的错误，并且一些错误仅在网页正文中报告。

NGINX Plus 支持被动和主动健康检查，后者比 ALB 更强大，能够匹配响应主体和状态代码。

价格

最后，部署 ALB 时面临的最大问题就是成本。 负载平衡可能是您的亚马逊账单的重要组成部分。

AWS 使用复杂的算法来确定定价。 除非您确切知道每个月要管理多少个新连接、多少个并发连接和多少数据（这很难预测），并且您可以按照与亚马逊相同的方式运行 LCU 计算，否则您每个月都会害怕收到亚马逊账单。

AWS 上的 NGINX Plus 为您提供完全的可预测性。 只需支付固定的小时费用加上 AWS 托管费用，您就可以获得功能更强大的负载平衡解决方案以及全面支持。

结论

NGINX Plus 是经过验证的第 7 层负载均衡解决方案，同时还具有第 4 层负载均衡功能。 它与亚马逊自己的 Classic Load Balancer 或 NLB 配合良好。

我们鼓励在 AWS 环境中持续并更多地使用 NGINX 和 NGINX Plus，因为它们已经是一种非常流行的解决方案。 如果您还不是 NGINX Plus 用户，请立即开始30 天免费试用或联系我们讨论您的用例。