云上负载均衡的演化,本质上就是网络功能从硬件固化走向软件定义的缩影。

一、演化过程:从“接通”到“智能调度”,再到“透明服务链”
在 AWS 的体系中(其他主流云厂商的逻辑类似),这些负载均衡器的出现有着明显的代际特征:
1. CLB(Classic Load Balancer)—— 第一代,基础转发
- 定位: 四层(TCP/SSL)和简单七层(HTTP/HTTPS)负载均衡。
- 特点: 功能单一,主要解决“将流量均匀分到后端”这一基本问题。它缺乏对应用层内容的精细理解,多个服务只能挤在同一个 CLB 后,通过笨拙的端口映射区分。
- 局限: 没有现代微服务的路由概念,功能固化,几乎就是一个硬件设备在云上的最简软件复刻。
2. ALB(Application Load Balancer)—— 第二代,内容感知路由
- 演化驱动力: 微服务和容器化兴起,需要根据请求内容(域名、路径、Header)将流量导向不同的后端服务。
- 能力质变: 这是完全的第七层软件定义负载均衡。它支持基于内容的规则路由、身份认证、WebSocket/gRPC,并与 ECS/Lambda 等云原生服务紧密集成。
- 意义: 负载均衡从“连接分发器”变成了应用网关,几十个微服务可以共享一个 ALB,通过路由规则灵活编排,告别了硬件时代的端口冲突和僵硬的拓扑。
3. NLB(Network Load Balancer)—— 第三代,极致性能与固定 IP
- 演化驱动力: 四层应用(如数据库、游戏、物联网)需要极高的吞吐、极低的延迟,并且需要稳定、对外暴露的静态 IP。
- 能力质变: 基于 AWS 的 Hyperplane 等 SDN 数据平面,它能轻松处理千万级并发,并保持源 IP 透传。它把四层负载均衡的软件性能做到了超越传统硬件盒子的水平,同时还具备云的弹性和按量付费。
4. GWLB(Gateway Load Balancer)—— 第四代,透明网络服务链
- 演化驱动力: 安全合规要求。流量在到达应用前,需要“强制”经过防火墙、入侵检测等第三方虚拟化安全设备,但又不改变网络拓扑。
- 能力质变: 它使用 GENEVE 协议封装流量,将报文原封不动地“镜像”给后端的虚拟安全设备集群,检查后再原路送回。这实现了透明的安全服务链,解决了硬件时代串接安全设备导致单点故障、弹性差、引流复杂的巨大痛点。
演化总结:从简单的端口转发(CLB) → 应用内容智能路由(ALB) → 高性能四层交付(NLB) → 透明插入网络服务(GWLB)。功能越来越专用、智能,与控制面和生态的融合越来越深,这背后完全由软件定义网络架构支撑。
二、软件定义网络相比纯硬件的优势
以上演化的每一步,都凸显了软件定义网络对纯硬件方案的碾压性优势:
| 敏捷与自动化 | API 优先,一切即代码 | |
| 弹性与扩展 | 水平弹性伸缩 | |
| 功能迭代速度 | 软件快速迭代 | |
| 高可用与去中心化 | 分布式高可用集群 | |
| 成本模型 | 按使用付费 | |
| 可观测性 | 原生深度可观测 | |
| 生态与集成 | 与云原生生态深度绑定 | |
| 业务连续性创新 | GWLB 的创新 |
传统硬件是一个封闭的、功能确定的黑盒,而软件定义负载均衡是一个可编程的、面向服务的分布式平台。控制面(API/自动化)与数据面(高性能分发)分离,让网络功能摆脱了专用硬件铁壳的束缚,真正成为云上智能、弹性的水管系统。
夜雨聆风