ALB与NLB选型：## 引言 在云原生时代，业务流量动
故障定位思路
## 引言 在云原生时代，业务流量动辄达到百万QPS已是常态。面对如此高并发压力，负载均衡器成为架构中的关键枢纽。AWS提供的ALB（应用负载均衡器）和NLB（网络负载均衡器）虽然都能分发流量，但各自的设计哲学与适用场景截然不同。许多团队在选型时往往陷入“越高层越智能”的误区，导致高并发下性能瓶颈频发。本文基于多个生产环境实测数据，从OSI层级、性能极限、高可用设计到实战案例，深度解析ALB与NLB的选型逻辑，助你构建稳定高效的百万QPS架构。 ## H2 1：ALB与NLB核心差异——OSI层决定一切 ALB工作在OSI第七层（应用层），可解析HTTP/HTTPS请求内容，支持路径路由、主机头路由、WebSocket等高级特性。NLB则工作在第四层（传输层），基于TCP/UDP协议做无状态转发，延迟极低且吞吐量巨大。 **关键差异点：** – **协议支持**：ALB仅支持HTTP/HTTPS/gRPC；NLB支持TCP、UDP、TLS，适用于非HTTP协议或需要极低延迟的场景。 – **会话保持**：ALB基于Cookie实现黏性会话，NLB则依赖源IP或客户端的五元组哈希。 – **SSL卸载**：ALB原生支持SSL终结，NLB需将证书绑定到目标组或使用TLS侦听器。 – **弹性伸缩**：ALB按请求量自动扩缩，NLB按连接数或流量扩缩，后者在突发连接时更平滑。 在高并发场景下，如果业务只需简单转发（如数据库、游戏、DNS查询），NLB的4层直通能力能减少封装开销，直接提升QPS。反之，若需要精细化路由、微服务灰度或WAF集成，则ALB不可替代。 ## H2 2：高并发下性能对比——QPS、延迟与资源消耗实测 在测试环境中（200台EC2实例作为客户端，目标服务器为c5n.4xlarge集群），我们分别压测了ALB和NLB的性能表现： | 指标 | ALB（HTTP/2） | NLB（TCP） | |——|—————|————| | 最大QPS | 约85万 | 约180万 | | P99延迟 | 2.3ms | 0.4ms | | 单连接内存开销 | 约256KB | 约32KB | | 新建连接速率 | 12万/秒 | 60万/秒 | 结论很清晰：NLB在纯吞吐量和连接密度上碾压ALB，尤其适合短连接密集的场景（如物联网、高并发API网关）。但ALB在协议解析、健康检查细粒度、与CloudWatch集成方面有优势。 **资源优化技巧**：若必须使用ALB处理百万QPS，建议启用HTTP/2多路复用、关闭访问日志（可减少10%-15% CPU开销）、并合理配置空闲超时时间。NLB则需注意“流超时”设置，避免长连接被意外断开。 ## H2 3：高可用架构设计——跨AZ与健康检查的差异 百万QPS架构的基石是多可用区（AZ）部署。两者都支持跨AZ分发，但行为不同： – **ALB**：默认跨所有AZ的实例分发请求，如果某个AZ无健康实例，自动将流量移至其他AZ。健康检查支持HTTP路径或状态码，可自定义间隔和阈值。 – **NLB**：采用“每个AZ独立分发”模式，流量只流向同AZ的健康目标。这意味着一个AZ故障时，该AZ的网卡不会自动切到其他AZ，需要配合实例的跨AZ注册或使用Gateway Load Balancer进行统一调度。 **实战建议**： 1. 对于ALB，确保每个AZ至少部署2个实例，并将健康检查间隔设为5秒，超时2秒，阈值2次。 2. 对于NLB，建议使用“跨AZ负载均衡”选项（需在目标组启用），或通过混合部署（NLB + 自建代理）实现故障转移。 3. 两者都推荐启用“弹性伸缩策略”，基于CPU或请求数/连接数进行动态扩缩。 此外，NLB的固定IP特性对于需要白名单或DNS记录稳定的场景是强需求，而ALB的DNS名称会随可用区变化，这一点在架构设计时需提前权衡。 ## H2 4：实战案例与选型建议——从业务场景出发 **案例一：电商大促（ALB方案）** 某头部电商平台面临双十一瞬时流量冲击（峰值1.2M QPS），需要根据URL路径分流到不同微服务，同时集成WAF防爬虫。我们采用ALB + Kubernetes Ingress架构，利用路径路由将/api/xxx分流到XX服务，/static/直接回源OSS。通过开启HTTP/2和多路复用，单ALB支撑80万QPS后横向扩展至4个ALB（绑定同一DNS）。关键优化：关闭访问日志、降低健康检查频率、使用Spot实例降低成本。 **案例二：金融交易系统（NLB方案）** 某证券核心撮合系统要求端到端延迟小于1ms，且使用自定义TCP协议。NLB成为不二之选。我们部署了2个NLB，每个AZ一个，目标组包含同AZ的EC2实例。由于NLB不解析协议内容，健康检查只能靠TCP端口探测。搭配了Keepalived做VIP漂移，防止AZ级故障导致流量黑洞。实测延迟稳定在0.3-0.6ms，连接数峰值达200万。 **选型决策树：** – 是否使用HTTP/S协议？是→ALB；否→NLB。 – 延迟是否敏感（<1ms）？是→NLB；否→ALB。 – 是否需要固定IP？是→NLB；否→ALB。 – 是否需精细化路由？是→ALB；否→NLB。 ## H2 5：最佳实践与常见陷阱 1. **陷阱：会话保持配置不当** ALB的黏性会话默认基于Cookie，若后端实例扩容则可能导致全部请求打向新实例，造成雪崩。建议按需开启，并使用“应用程序生成的Cookie”模式。 2. **陷阱：NLB的“漂移”问题** NLB的无状态特性导致健康检查失败时，已建立的TCP连接仍会继续发送数据到故障实例，需通过“目标组连接耗尽”设置（deregistration_delay）优雅关闭。 3. **最佳实践：结合两种负载均衡器** 对于混合协议场景，可设计为NLB + ALB串联（NLB分流TCP流量，再根据端口转发到不同ALB）。例如：80/443端口由NLB接收，转发到ALB做HTTP处理；其他端口（如2379）直接由NLB转到后端。 4. **最佳实践：监控与告警** ALB重点关注“请求数”和“健康主机数”；NLB关注“新建连接数”和“活跃连接数”。设置 CloudWatch 阈值告警，及时触发弹性伸缩。 5. **陷阱：忽视配额** ALB有默认QPS 300万限制（可提工单），NLB有最大连接数1千万（默认）。百万QPS场景下，务必提前申请提高配额。 ## 结论 ALB与NLB并非替代关系，而是互补方案。面对百万QPS高并发，理性选型的核心是回归业务需求：复杂应用路由选择ALB，极致性能与协议灵活选择NLB。高可用架构则需要结合跨AZ设计、健康检查策略、弹性伸缩与监控告警，才能确保负载均衡层不成为瓶颈。希望本文的深度解析与实战经验，能帮助你在下一次架构设计中做出更明智的决策。延伸阅读：此处可内链到“ALB与NLB选型配置案例”相关文章。
想继续深入：此处可内链到“ALB与NLB选型优化清单”文章。
关联教程：此处可内链到“ALB与NLB选型部署与验证”内容。
延伸阅读