ELB 为何有 3 种类型 - ALB、NLB、CLB 分离的设计决策内幕
从 OSI 参考模型层级、性能特性和历史经过解析 ALB、NLB、CLB（Classic）三种负载均衡器为何未统合而并存。
Classic Load Balancer - ELB 的起点
2009 年推出的 Elastic Load Balancing（现 Classic Load Balancer）是 AWS 首个负载均衡服务。CLB 被设计为可处理 L4（TCP）和 L7（HTTP/HTTPS）流量的通用负载均衡器。然而这种「什么都能做」的设计后来产生了问题。L4 和 L7 的负载均衡在处理流水线上有根本差异，统一处理导致两方面都无法达到最优性能。
ALB 的诞生 - 专注 L7 的设计
2016 年推出的 Application Load Balancer（ALB）是完全专注于 L7（HTTP/HTTPS）的负载均衡器。实现了 CLB 无法做到的基于路径的路由（/api/* 到 API 服务器、/static/* 到静态文件服务器）、基于主机的路由（api.example.com 和 www.example.com 路由到不同目标组）以及 WebSocket 和 HTTP/2 的原生支持。
NLB 的诞生 - 追求 L4 极限性能
2017 年推出的 Network Load Balancer（NLB）专注于 L4（TCP/UDP/TLS），追求极限性能。NLB 每秒可处理数百万请求，延迟为数十微秒，与 ALB 的数毫秒相比低了一个数量级。这种性能差异源于 NLB 完全不解析数据包内容。NLB 基于流（源 IP、目标 IP、端口、协议的组合）进行路由判断，无需将数据包重组为 HTTP 请求。
为何不统合为一个
「将 ALB 和 NLB 统合为一个服务不就好了」这个疑问很自然，但不统合的原因在技术上很明确。L4 和 L7 的负载均衡处理流水线根本不同。L7 需要接收所有数据包、重组为 HTTP 请求、解析头部、评估路由规则、必要时改写头部后转发到目标。这需要大量内存和 CPU。L4 只需查看数据包头部的 IP 和端口即可做出路由判断，可在硬件级别处理。统合意味着所有流量都要经过 L7 的重处理流水线，L4 工作负载会产生不必要的延迟。
选择判断标准
三种 ELB 的选择由工作负载特性决定。处理 HTTP/HTTPS 流量且需要基于路径或主机路由时选 ALB。Web 应用、REST API、微服务大多数情况下 ALB 最优。处理 TCP/UDP 流量且需要极限性能或静态 IP 时选 NLB。游戏服务器、IoT 设备连接、金融交易系统等延迟敏感的工作负载适合 NLB。CLB 仅用于遗留系统维护，新项目不应选择。