ALB、NLB、CLB 负载均衡深度剖析

前言

笔者在上周的实际工作中遇到了一个典型的负载均衡选择问题：在使用代理调用相关模型时，最初配置 Nginx 的代理地址为 ALB 的 7 层虚拟 IP（VIP），但由于集团网络默认的超时时间为 3 分钟，导致服务调用频繁出现超时中断。尝试将代理地址切换为 NLB 的 4 层虚拟 IP 后，该问题得到了完美解决。这一亲身经历让我深刻体会到，不同类型的负载均衡在实际场景中的表现差异显著，选择合适的负载均衡类型对系统稳定性至关重要。基于此，本文将对 ALB、NLB、CLB 三种主流负载均衡进行深度剖析，帮助读者理解其技术原理与适用场景。

负载均衡（Load Balancer）是分布式系统中实现高可用、高并发的核心组件，其核心作用是将流量「合理分配」到多个后端服务节点，避免单点过载。根据工作层级和功能定位，常见的负载均衡可分为 CLB（传统负载均衡）、NLB（网络负载均衡）、ALB（应用负载均衡） 三类。以下从技术原理、核心特性、适用场景等维度深度解读。

一、CLB（Classic Load Balancer，传统负载均衡）

1. 定义

CLB 是最早出现的负载均衡类型，定位为「通用型基础负载均衡」，同时支持 四层（传输层）和七层（应用层）协议，但功能相对基础，主要满足简单的流量分配需求。

2. 工作层级

四层（传输层）：基于 TCP/UDP 协议，通过「源 IP + 端口、目标 IP + 端口、协议类型」对流量进行转发（类似 NAT 机制）。
七层（应用层）：基于 HTTP/HTTPS 协议，可解析 URL、主机头（Host）等简单应用层信息，但路由能力有限。

3. 核心特性

基础负载均衡算法：支持轮询（Round Robin）、加权轮询、最小连接数等简单策略。
健康检查：通过 TCP 端口探测或 HTTP 状态码（如 200 OK）判断后端节点是否可用。
会话保持：基于 Cookie 或源 IP 绑定会话，确保同一用户请求转发到同一后端节点。
兼容性：支持几乎所有传统服务器和应用，无需改造后端服务。

4. 优势

部署简单：配置门槛低，适合新手或快速搭建场景。
兼容性强：支持老旧系统和多种协议，无需后端服务适配。
成本较低：功能简单，资源消耗少，运维成本低。

5. 局限性

性能上限低：并发能力有限（通常十万级以下），难以应对超大规模流量。
功能简陋：不支持复杂路由（如基于 URL 路径的精细化转发）、HTTP/2、WebSocket 等现代协议。
扩展性弱：无法适配微服务、容器化等复杂架构的动态流量调度需求。

6. 适用场景

中小型 Web 应用（如企业官网、简单电商网站）。
传统 TCP/UDP 服务（如邮件服务器、简单数据库代理）。
对成本敏感、无需复杂功能的场景。

二、NLB（Network Load Balancer，网络负载均衡）

1. 定义

NLB 是专为「高性能、低延迟」设计的四层负载均衡，仅工作在传输层（TCP/UDP），聚焦于解决大规模流量的高效分发问题。

2. 工作层级

四层（传输层）：基于「源 IP、源端口、目标 IP、目标端口、协议类型」的五元组进行流量转发，不解析应用层数据（如 HTTP 内容）。

3. 核心特性

超高并发能力：支持百万级并发连接，单机吞吐量可达数十 Gbps。
微秒级延迟：转发逻辑基于内核态实现（如 Linux 内核的 XDP 技术），比用户态转发快 1-2 个数量级。
弹性与高可用：自动适配后端节点扩缩容，支持跨可用区部署，单点故障不影响整体服务。
静态 IP 支持：可绑定固定 IP 或弹性 IP，方便客户端固定接入点。
基础健康检查：基于 TCP 端口探测（如三次握手是否成功）或 UDP 报文响应。

4. 优势

性能天花板高：是三种负载均衡中「纯转发能力」最强的，适合超大规模流量场景。
稳定性强：设计目标是「无状态转发」，自身故障概率极低。
适配动态场景：可快速响应后端节点的增减（如 Kubernetes 容器的动态扩缩容）。

5. 局限性

不支持应用层功能：无法基于 URL、HTTP 头信息等应用层数据进行路由，也不支持 SSL 终止（需后端服务自行处理 HTTPS）。
健康检查简单：仅能判断节点「是否存活」，无法检测应用层异常（如节点存活但返回 500 错误）。

6. 适用场景

高并发 TCP 服务（如大型游戏服务器、金融交易系统）。
实时音视频流传输（如直播、视频会议）。
IoT 设备通信（海量设备的 UDP 数据上报）。
需要低延迟的科学计算集群、分布式存储访问入口。

三、ALB（Application Load Balancer，应用负载均衡）

1. 定义

ALB 是针对「应用层精细化流量调度」设计的七层负载均衡，工作在 HTTP/HTTPS 协议层，能深度解析应用层数据并实现灵活路由。

2. 工作层级

七层（应用层）：基于 HTTP/HTTPS 协议，可解析 URL 路径、主机头（Host）、HTTP 方法（GET/POST）、请求头（Header）等应用层信息。

3. 核心特性

精细化内容路由：支持基于 URL 路径（如 /api/v1/* 转发到服务 A，/web/* 转发到服务 B）、主机头（如 a.example.com 到服务 X，b.example.com 到服务 Y）的转发策略。
SSL 终止与卸载：在 ALB 层处理 SSL 握手和加密解密，后端服务仅需处理 HTTP 流量，降低服务器负载。
高级健康检查：基于 HTTP 响应码（如 200 正常，503 异常）、响应内容（如检查返回的 JSON 字段）判断应用状态。
协议兼容性：支持 HTTP/2、WebSocket、gRPC 等现代应用协议。
会话管理：通过 Cookie 或路径实现会话粘性（Sticky Sessions），适配需要保持用户状态的场景（如购物车）。

4. 优势

灵活适配复杂架构：是微服务、Serverless 等现代架构的「流量入口首选」，可作为 API 网关使用。
应用层可见性：能收集请求日志（如响应时间、错误码），便于问题排查和性能分析。
安全性增强：可集成 WAF（Web 应用防火墙）、限流、黑白名单等功能，过滤恶意请求。

5. 局限性

性能略低于 NLB：因需解析应用层协议，转发延迟比 NLB 高（毫秒级），并发能力通常在数十万级。
仅支持七层协议：无法直接处理 TCP/UDP 裸流量（需配合 NLB 或 CLB 实现四层转发）。

6. 适用场景

微服务架构（如 Spring Cloud、Kubernetes 集群的流量入口）。
API 网关（统一管理接口路由、认证、限流）。
复杂 Web 应用（如需要按路径拆分的前后端分离项目）。
HTTPS 服务（利用 SSL 终止降低后端服务器负载）。

四、ALB、NLB、CLB 核心差异对比

维度	CLB（传统负载均衡）	NLB（网络负载均衡）	ALB（应用负载均衡）
工作层级	四层 + 七层（基础支持）	仅四层（TCP/UDP）	仅七层（HTTP/HTTPS）
并发能力	十万级以下	百万级以上	数十万级
延迟	毫秒级	微秒级	毫秒级（略高于 NLB）
核心功能	基础负载均衡、简单健康检查	高性能转发、低延迟、弹性伸缩	精细化路由、SSL 终止、应用层监控
协议支持	TCP、UDP、HTTP、HTTPS（基础）	TCP、UDP	HTTP、HTTPS、HTTP/2、WebSocket、gRPC
适用架构	传统单体应用	高并发网络服务	微服务、Serverless、复杂 Web 应用
典型场景	中小型 Web 应用、简单 TCP 服务	游戏服务器、视频流、IoT 通信	API 网关、微服务入口、HTTPS 服务