如何在Amazon上选择合适的负载均衡器：AWS Application Load Balancer与NGINX Plus对比

NGINX | 2020年7月21日

2016年8月，Amazon Web Services (AWS)推出了Application Load Balancer，用于对HTTP和HTTPS流量进行第7层负载均衡。与AWS现有的第4层和第7层负载均衡器Elastic Load Balancer相比，这款新产品增加了多项后者不具备的功能。Elastic Load Balancer随后正式更名为Classic Load Balancer。

一年后，AWS推出了Network Load Balancer，以改进第4层负载均衡。因此，在AWS上运行高可用、可扩展应用的用户可选择：

本文将介绍ALB的功能，并将其定价和功能与NGINX Open Source及NGINX Plus进行比较。

注意事项：

有关受支持功能的信息截至2020年7月准确无误，但可能会发生变化。有关NGINX Plus与Classic Load Balancer（原名Elastic Load Balancer或ELB）的直接比较，以及二者结合使用的信息，请参阅我们的上一篇博客文章。有关使用NLB实现NGINX Plus高可用部署的信息，请参阅我们的上一篇博客文章。

应用负载均衡器的功能

与Classic Load Balancer或NLB一样，ALB与AWS紧密集成。Amazon将其称为第7层负载均衡器，但它无法提供独立第7层反向代理和负载均衡器所具备的完整功能、调优能力和直接控制能力。

ALB提供以下Classic Load Balancer不具备的功能：

基于内容的路由。ALB支持根据请求URL、Host标头以及请求中的字段进行基于内容的路由，这些字段包括标准和自定义HTTP标头及方法、查询参数和源IP地址。（请参阅ALB文档中的“从Classic Load Balancer迁移的优势”。）
支持基于容器的应用程序。ALB改进了对托管在Amazon EC2 Container Service（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月准确无误，但可能会发生变化。

	Amazon ALB	NGINX Open Source	NGINX Plus
负载均衡方法和功能	`Round_robin`和`least_outstanding_requests`方法，支持基于Cookie的会话持久性、加权目标组和慢启动	多种负载均衡方法（包括轮询、最少连接、哈希、IP哈希和随机），支持加权上游服务器	功能与NGINX Open Source相同，此外还支持最短时间方法、更多会话持久性方法和慢启动
缓存	❌ 不支持在负载均衡器中缓存	✅ 静态文件缓存和动态（应用）缓存	✅ 静态和动态缓存，以及高级功能
健康检查	主动检查（通过检查异步检查返回的状态码来识别故障服务器）	被动检查（通过检查对客户端请求的响应来识别故障服务器）	同时支持主动和被动检查；主动检查比ALB功能更丰富、可配置性更强
高可用性	可在多个可用区中部署ALB实例以实现高可用性，但不能跨区域部署	使用NLB实现主动-主动高可用性，以及使用弹性IP地址实现主动-被动高可用性	功能与NGINX Open Source相同，此外还内置集群状态共享，可在所有NGINX Plus实例之间实现无缝高可用性
支持IP协议族中的所有协议	❌ 仅支持HTTP和HTTPS	✅ 还支持TCP和UDP，并提供被动健康检查	✅ 还支持TCP和UDP，并提供主动和被动健康检查
每个负载均衡器实例支持多个应用	✅	✅
基于内容的路由	✅ 基于请求URL、`Host`标头，以及标准和自定义HTTP标头、方法、查询参数和源IP地址等请求字段	✅ 基于与ALB相同的因素，此外还支持Cookie，以及使用NGINX JavaScript模块作为内联JavaScript引擎进行动态计算	✅ 基于与NGINX Open Source相同的因素，此外还支持JWT声明和键值存储中的值
容器化应用	可对Amazon ID、ECS容器实例、Auto Scaling组和AWS Lambda函数进行负载均衡	需要手动配置或使用配置模板	使用DNS自动配置，包括`SRV`记录；可与主流注册服务配合使用
可移植性	❌ 所有环境（开发、测试和生产）都必须位于AWS上	✅ 任何环境均可位于任意部署平台上
SSL/TLS	✅ 支持多个SSL/TLS证书和SNI ❌ 不支持验证SSL/TLS上游	✅ 支持多个SSL/TLS证书和SNI ✅ 可自由选择SSL/TLS密码套件 ✅ 全面验证SSL/TLS上游
HTTP/2和WebSocket	✅	✅
身份验证功能	– OIDC、SAML、LDAP和AD IdP身份验证选项 – 与AWS Cognito和CloudFront集成	多种身份验证选项
高级功能	❌ 基础API	✅ 源站内容服务、优先级设置、速率限制等	✅ 功能与NGINX Open Source相同，此外还提供RESTful API和键值存储
日志记录和调试	✅ Amazon二进制日志格式	✅ 可自定义的日志文件和多个调试接口	✅ 完全可自定义的日志文件和多个调试接口，并由NGINX提供全面支持
监控工具	✅ 与Amazon CloudWatch集成	✅ NGINX Controller*和其他第三方工具	✅ NGINX Controller和其他第三方工具；可报告更多统计信息
官方技术支持	✅ 需额外付费	❌ 仅提供社区支持	✅ 费用已包含在价格中，并由NGINX直接提供支持
免费套餐	✅ 前750小时	✅ 永久免费	✅ 30天试用订阅

* NGINX Controller现已更名为F5 NGINX Management Suite。

当然，评估负载均衡方案时，不应只看功能清单，而应考察其是否具备所需能力，以顺畅交付应用，并实现高安全性、高可用性和全面控制。

应对流量激增

Amazon Classic Load Balancer（原称ELB）应对流量激增的能力较弱。负载均衡器实例会根据当前流量水平自动调整规模，但在流量激增时，ELB可能需要数分钟才能响应并部署额外容量。用户不得不通过手动填写表单的流程，在流量激增前申请额外资源（称为“预热”）。由于ALB基于NGINX构建，其实例可以处理大得多的流量，但在流量激增时，仍可能出现扩缩容事件。此外，流量激增会自动增加负载均衡器容量单位（LCU）的消耗，进而导致成本上升。

如果自行部署和扩展负载均衡代理，即可全面掌控容量和成本。NGINX和NGINX Plus部署在标准Amazon实例中，我们的容量规划指南可帮助了解不同容量的实例类型可能达到的峰值性能。NGINX Plus对所有实例大小采用相同定价，因此，部署冗余容量来应对流量激增具有较高的成本效益；需要更多容量时，也能快速部署更多实例，无需填写表单。

通过健康检查检测故障服务器

我们对Amazon ALB的测试表明，它并未实施“被动”运行状况检查。只有在异步测试确认服务器未返回预期状态码后，系统才会检测到该服务器发生故障。

我们通过创建一个ALB实例，为一组实例进行负载均衡，从而发现了这一情况。我们将运行状况检查配置为最低5秒频率，并将失败检查次数的最低阈值设为2，然后持续向ALB发送请求。当我们停止其中一个实例时，ALB对部分请求返回了502 Bad Gateway错误，并持续数秒，直到运行状况检查检测到该实例已停止运行。NGINX和NGINX Plus均支持被动运行状况检查，可避免最终用户看到此类错误。

ALB的运行状况检查只能通过检查HTTP状态码（例如200 OK或404 Not Found）来判断实例的运行状况。此类运行状况检查并不可靠。例如，某些Web应用程序会用用户友好的页面替代服务器生成的错误，而有些错误仅在网页正文中报告。

NGINX Plus同时支持被动和主动健康检查，后者比ALB的健康检查功能更强，不仅能匹配状态代码，还能匹配响应正文。