买负载均衡还在拍脑袋？ALB、NLB、CLB 到底差别在哪，一次讲清楚

买负载均衡还在拍脑袋？ALB、NLB、CLB 到底差别在哪，一次讲清楚

导读：有朋友上周找我，说要给新项目挂个负载均衡，控制台里 SLB、ALB、NLB、CLB 四个选项摆一排，随手选了个"最眼熟的"，结果上线才发现按路径转发配不了，只能推倒重来。

今天就把这四个缩写一次性掰开讲清楚——看完你至少不会再买错。

全程不需要任何命令行。

先给结论，赶时间看这段就够

阿里云的"负载均衡"其实是一个产品家族，名字叫 SLB（Server Load Balancer）。

这个家族下面现在有三款在卖的产品：

产品

中文名

干活层级

一句话定位

ALB

应用型负载均衡

七层（HTTP/HTTPS/QUIC/gRPC/SSE）

要看内容、按规则转发的选它

NLB

网络型负载均衡

四层（TCP/UDP/TCPSSL）

只求快、连接多的选它

CLB

传统型负载均衡

四层 + 基础七层

老系统还在用，新项目别默认选

记不住的话，记这个土味比喻：

ALB 是懂业务的前台，NLB 是高速收费站，CLB 是老牌综合窗口，SLB 是这栋办事大厅的名字。

顺带一提，这个家族现在其实还有第四款GWLB（网关型负载均衡），不过它是专门给安全设备做流量引流的，跟上面三位不是一类活，下面单独讲。

大厅不是窗口。这就是大多数人第一次搞混的根源。

SLB 根本不是"一台机器"

这事得从历史说起。

早些年阿里云只有一种负载均衡，大家顺口就叫它 SLB。

叫久了，"SLB"这四个字母就跟"负载均衡实例"划上了等号，很多老运维写文档还是"给 XX 挂个 SLB"。

**负载均衡SLB（Server Load Balancer）**是一种对流量进行按需分发的服务，通过将流量分发到不同的后端服务来扩展应用系统的服务吞吐能力，并且可以消除系统中的单点故障，提升应用系统的可用性。

后来产品线拆了：应用型 ALB、网络型 NLB、传统型 CLB 三兄弟各管一摊。

官方文档又把 SLB 定义成整个产品家族的总称。

于是同一个词，在不同人嘴里意思完全不一样：

• • 老同事说"挂个 SLB"，可能指的是那台老的 CLB 实例；

• • 文档里的"SLB 产品家族"，指的是 ALB + NLB + CLB 的合集；

• • 新人听完之后，以为 SLB 是第四种产品。

所以从今天起，写架构图和工单时别再说"上个 SLB"了。

改成这句：

我们用阿里云负载均衡家族里的 ALB（或 NLB / CLB），原因是……

多打几个字，能省掉后面一堆返工。

用办事大厅打个比方

假设你开了一栋办公楼，每天一堆人来办事。你不可能让所有人冲进每个办公室，所以门口得有个收发室。

收发室干四件事：

1. 1. 把人先接住

2. 2. 看他手里拿的单子

3. 3. 判断哪个窗口空着、哪个窗口挂了

4. 4. 把人分到对的窗口

负载均衡干的就是这个活。用户请求先进来，它再转给后端服务器；某台服务器健康检查挂了，它就不往那儿发新请求，用户完全无感。

关键在于——这三个"收发室"看单子的能力完全不同。

ALB 看得最细。它不只看你从哪个门进来，还要看你预约了哪个科室：域名是什么、URL 路径是 /api 还是 /admin、Header 里带了什么、Cookie 里有什么、是不是走特殊通道。

NLB 看得最快。它压根不细读你的材料，只看协议、端口、连接，然后放行。目标只有一个：让海量车辆低延迟地通过。

CLB 是个老窗口。四层能干，基础七层也能干，但高级路由、云原生集成、弹性伸缩这些新本事，不是它的强项。

ALB：那个会看你预约单的前台

ALB 全称 Application Load Balancer，专门吃应用层流量。

所谓"七层"，说人话就是：它看得懂 HTTP 请求里写的是啥。

这带来几个实打实的能力：

• • 一个域名按路径拆开：/api走接口服务，/static走对象存储，/admin走后台

• • 灰度发布：按 Header、Cookie、请求参数把 1% 的用户切到新版本

• • 做 Kubernetes 的 Ingress 网关，对接 ACK、ASK

• • 支持 HTTPS、QUIC、gRPC，还有现在很常用的SSE 流式返回

最后这条值得单独说一句。现在但凡做个 AI 应用，大模型要一个字一个字往外吐，走的就是 SSE。阿里云官方文档已经明确写了 ALB 支持 SSE 流式传输，能实时返回推理结果。

你要是拿四层负载均衡去扛 SSE，等于让收费站读长篇小说——能读，但憋屈。

一句话：新建 Web 站点、API 服务、小程序后端、AI 应用入口，默认先看 ALB。

应用型负载均衡ALB（Application Load Balancer）是阿里云推出的专门面向HTTP、HTTPS和QUIC等应用层负载场景的负载均衡服务，具备弹性及大规模应用层流量处理能力。ALB具备处理复杂业务路由的能力，与云原生相关服务深度集成，是阿里云官方提供的云原生Ingress网关。

网络型负载均衡NLB（Network Load Balancer ）工作在四层，跟 TCP、UDP、TCPSSL 这些连接本身打交道。

官方给它的定位是"面向万物互联时代的新一代四层负载均衡"，支持超高性能和自动弹性，单实例能到 1 亿并发连接。

什么场景需要它？

• • IoT 设备接入、车联网、视频监控、智能家居——连接数多到吓人

• • 音视频、游戏、消息网关——延迟敏感

• • TCPSSL 卸载——证书在负载均衡上统一管，后端轻松点

• • 后端不在云上——可以挂 IP 类型后端，配合云企业网把流量分发到跨 VPC、跨地域甚至线下 IDC

那问题来了：ALB 也挺强，干嘛还要 NLB？

因为"看懂内容"和"放行得快"是两种完全不同的能力，而且互相冲突。

让 ALB 去扛几百万条不需要理解内容的 TCP 长连接，是在浪费它的解析开销；让 NLB 去按 URL 路径转发，它压根看不懂。

别让前台去当收费站，也别让收费站去审合同。

GWLB：专门把流量拉去"过安检"的那一个

GWLB 网关型负载均衡，阿里云 SLB 家族成员，可正常新购。它是三层透明负载均衡，不做业务网站入口，专门用于防火墙、IDS/IPS 等安全设备集群。流量经过 GWLB 时源目 IP 不变，透明引流给安全设备检测，适合构建集中式边界安全网关、流量审计，多用于政企、金融等高合规场景。

传统型负载均衡CLB（Classic Load Balancer）是将访问流量根据转发策略分发到后端多台云服务器的流量分发控制服务。

支持 TCP、UDP、HTTP、HTTPS，四层功底扎实，基础七层也有。

很多人看到"传统型"三个字就觉得它该进博物馆了，这个判断不准确。

CLB 真正的优势是稳、熟、到处都是。大量跑了五六年的系统挂在上面，规则简单，从来没出过事。这种场景硬要迁，纯属给自己找活干。

但有个信号必须知道：

官方文档显示，CLB 包年包月实例已在 2024 年 12 月 1 日 00:00:00 停止新购。

这不代表 CLB 明天就不能用了——存量实例照常跑。但它很明确地告诉你：新项目的方向是 ALB 和 NLB。

所以判断标准很简单：

• • 老系统、规则简单、迁移成本高 →继续用 CLB，别折腾

• • 新搭入口、需要云原生 Ingress / 高级七层路由 / 大规模四层连接 →别买 CLB

别一上来就翻对比表。现场决策更实用的是这五问，能快速把错误选项排掉。

① 入口协议是什么？

HTTP / HTTPS / QUIC / gRPC / SSE → ALB；TCP / UDP / TCPSSL → NLB。

② 要不要看请求内容？

要按域名、路径、Header、Cookie 转发 → ALB。只按端口和连接分发 → NLB。

③ 连接规模有多大？

海量长连接、设备接入、音视频流 → NLB。请求量大但路由规则复杂 → ALB。

④ 是不是云原生架构？

K8s Ingress、ACK/ASK、SAE、函数计算 → ALB 更直接。NLB 能做容器场景的四层入口，但别拿它当七层 Ingress 用。

⑤ 手上有没有 CLB 存量？

有存量不等于要迁。先盘一遍：规则复杂度、访问峰值、证书、健康检查方式、后端类型、回滚方案、双跑成本。盘完发现需求已经超出 CLB 舒适区了，再动。

三个误区 ALB 更新，那就全用 ALB？

新不代表通吃。我见过有人把几十万 IoT 长连接怼到 ALB 上，账单和延迟一起起飞。

NLB 性能强，网站也上 NLB？

只做 80/443 端口转发，NLB 确实能干。但只要你哪天想加个按路径转发、按 Header 灰度、重定向、WAF 深度集成，就得推倒重来。

有健康检查就高枕无忧了？

健康检查只能避免把流量发给明显已经挂掉的后端。

它救不了慢查询、救不了数据库连接池打满、救不了那种"端口通着但页面要 30 秒才出来"的半死不活状态。负载均衡是入口，不是万能药。

GWLB 也是负载均衡，那业务入口用它也行？

不行。GWLB 是三层、IP 全端口、Geneve 封装、后端是安全设备的引流层。拿它当业务负载均衡，等于让安检机去当前台——流量是能过，但路由、灰度、证书、七层能力一个都没有，还白白多一道延迟。业务入口该 ALB 还 ALB，GWLB 只负责把流量引去"过安检"。

计算成本

技术选型翻车，一半翻在账单上。

ALB、NLB、CLB 三家的计费模型和 LCU（负载均衡容量单位）定义都不一样。选型时要一起算的账至少有这些：

• • 实例费

• • LCU 费用（按什么维度计费，三家不同）

• • 公网 EIP 或共享带宽

• • 迁移期间新老双跑的重复成本

很多"架构图上特别优雅"的方案，上线第一个月就被账单教育了。

先拿预估流量算一遍，再决定。

星哥的云上小店

平时要买云服务器、域名、对象存储、负载均衡这些，可以走星哥的推荐链接，走的是官方渠道，价格公开透明，星哥这边能拿一点返佣，算是给熬夜写稿续杯咖啡。

阿里云：y.xgss.net/a

腾讯云：y.xgss.net/tx

复制上面的地址粘贴到浏览器打开就行，跟你自己进官网下单流程完全一样，不额外收费。

有新购、续费、升配需求的朋友可以先存一下这俩地址，用得上。

负载均衡这东西，看起来只是"把流量分给后端"这么一件小事。

但它一旦选错，后面牵连的是证书、域名、WAF、Ingress、灰度策略、带宽、灾备方案，还有一整条迁移路径。

改一次，比当初多花两小时选型痛十倍。

带走这张小抄就够了：

• • 看得懂 HTTP 内容、按业务规则转发 →ALB

• • 不看内容、重点是 TCP/UDP 连接规模 →NLB

• • 老实例、简单四层、迁不动 →CLB（下线）

• • 所有流量要先过一遍防火墙 / IPS / NIDS →GWLB

负载均衡中，
ALB、NLB、GWLB 支持全新购买；
CLB 仅保留按量按使用量计费的新购入口，包年包月和按规格计费 CLB 已停售，新项目尽量选用 ALB/NLB 替代 CLB。

你现在的业务入口挂的是哪一种？有没有踩过选型的坑？评论区聊聊。