负载均衡-CLB / ALB / NLB / GWLB 的区别

你图里这几种 负载均衡（ALB / NLB / GWLB / CLB） ，本质区别在 工作层级、协议能力、功能复杂度、适用架构 。我按「一眼区分 → 技术差异 → 典型场景 → 选型建议 」给你一版架构级解释，偏你现在做平台/中台/微服务的视角。

一、先给一个「一句话认知」

类型	一句话理解
ALB（应用型）	懂 HTTP/HTTPS 语义，能做七层路由、域名、路径、Header
NLB（网络型）	只管 TCP/UDP 转发，性能极高、延迟极低
GWLB（网关型）	给"流量链路"插安全/审计/网络功能的透明网关
CLB（传统型）	早期统一 LB，功能折中，逐步被 ALB/NLB 替代

二、核心技术差异（重点）

1️⃣ 工作层级（最关键）

类型	OSI 层
ALB	L7 应用层
NLB	L4 传输层
GWLB	L3/L4（流量转发 + 封装）
CLB	L4 + 部分 L7（早期混合）

👉 是否"看得懂 HTTP"，决定了能力上限

2️⃣ 协议 & 能力对比

能力	ALB	NLB	GWLB	CLB
HTTP / HTTPS	✅ 强	❌	❌	⚠️ 基础
TCP / UDP	⚠️	✅ 强	✅	✅
WebSocket	✅	⚠️	❌	⚠️
七层路由（域名/路径/Header）	✅	❌	❌	⚠️
TLS 终止	✅	❌（透传）	❌	⚠️
超高并发	中高	极高	高	中
透明转发	❌	❌	✅	❌
安全/审计链路插入	❌	❌	✅	❌

3️⃣ 性能与成本感知

项目	ALB	NLB
延迟	较高（解析 HTTP）	极低
吞吐	中高	百万级 QPS
功能成本	高	低
使用复杂度	高	低

三、分别适用于什么场景（重点）

✅ ALB ------ 应用层 / 微服务 / API 网关入口

典型特征

需要 域名 / 路径 / Header 路由
HTTP/HTTPS
业务感知流量

适用场景

API Gateway
微服务入口
B 端 / C 端 Web、H5、小程序
SaaS 平台统一入口
蓝绿 / 灰度发布

你熟悉的典型架构

text 复制代码

用户
 ↓
ALB（/api → 服务A，/ai → 服务B）
 ↓
Spring Cloud Gateway / K8s Ingress
 ↓
微服务

结论

👉 只要是"业务入口"，优先 ALB

✅ NLB ------ 高性能 TCP / RPC / 内网服务

典型特征

不关心 HTTP
只做端口转发
性能极致

适用场景

RPC（Dubbo / gRPC）
数据库代理（MySQL / Redis）
RocketMQ / Kafka
内网服务互调
游戏 / 实时通信

典型架构

text 复制代码

服务A
 ↓ TCP
NLB
 ↓
服务B

结论

👉 只要你追求性能、延迟、稳定，选 NLB

✅ GWLB ------ 安全 / 网络功能插槽（高级）

这是很多人不理解但非常"架构级"的 LB。

它不是给业务用的，是给"网络能力"用的

适用场景

WAF
防火墙
IDS / IPS
流量审计
数据脱敏
第三方安全设备

核心特点

透明（业务无感知）
流量"旁路"或"链路注入"

典型架构

text 复制代码

用户流量
 ↓
GWLB
 ↓
安全设备集群（防火墙 / 审计）
 ↓
业务服务

结论

👉 只有在安全 / 合规 / 网络治理场景才会用

⚠️ CLB ------ 传统负载均衡（不推荐新项目）

特点

早期云产品
能力不上不下
运维复杂

适用场景

老系统
不方便改造
历史包袱

结论

👉 新架构尽量别选 CLB

四、选型速查表（给 CTO / 架构评审用）

需求	推荐
Web / API / 微服务入口	ALB
RPC / MQ / DB / 内网服务	NLB
安全、审计、合规	GWLB
老系统迁移	CLB（过渡）

五、结合你现在的平台

你实际会用到的组合大概率是：

text 复制代码

公网
 ↓
ALB（域名、HTTPS、路由）
 ↓
K8s Ingress / Spring Cloud Gateway
 ↓
微服务
 ↓
NLB（MQ / ES / Redis / RPC）

GWLB 只在你：

要做企业级安全
要过等保 / 合规
要接第三方安全设备
才有必要上

如果你愿意，我可以下一步帮你做三件事之一（你选）：

1️⃣ 画一张「云上负载均衡 + K8s + 微服务」标准架构图

2️⃣ 帮你写一段"架构选型说明"，直接能放在方案/PPT 里

3️⃣ 结合等保 2.0/3.0，讲清楚什么时候必须上 GWLB

你直接说选哪一个。