阿里云负载均衡别再乱买了：SLB、ALB、NLB、CLB 到底差在哪？

先说结论

现在看到阿里云负载均衡时，不要再把 SLB 当成某一种具体实例。更准确的理解是：SLB 是阿里云负载均衡产品家族的总称，里面主要有 ALB、NLB、CLB 三类产品。

• ALB：七层应用型负载均衡，重点处理 HTTP、HTTPS、QUIC、gRPC、SSE 这类应用层流量。你要按域名、路径、Header、Cookie、请求方法做转发，优先看它。
• NLB：新一代四层网络型负载均衡，重点处理 TCP、UDP、TCPSSL 这类连接层流量。你要高并发、低时延、长连接、IoT、音视频、消息服务入口，优先看它。
• CLB：传统型负载均衡，支持 TCP、UDP、HTTP、HTTPS，四层能力不错，也有基础七层能力。存量系统还在用它可以继续稳住，但新系统通常应该先看 ALB 或 NLB。

如果用一句特别土但好记的话讲：ALB 像懂业务规则的前台，NLB 像高速收费站，CLB 像老牌综合服务窗口，SLB 则是整栋办事大厅的名字。

图 1：AI 生成封面。SLB 更像产品家族入口，不要把它和某一个具体实例混成一件事。

一、问题背景：为什么很多人会把 SLB、CLB、ALB、NLB 说乱

如果你用云服务时间够久，大概率听过这几种说法：

• “给这个服务挂一个 SLB。”
• “公网入口先走 CLB。”
• “K8s Ingress 用 ALB。”
• “大量 TCP 长连接要换 NLB。”

这些话单独听都没错，但放在一起就容易把人绕晕。尤其是早些年大家习惯把“负载均衡实例”直接叫 SLB，后来阿里云负载均衡产品线演进出了应用型 ALB、网络型 NLB、传统型 CLB，文档又把 SLB 作为 Server Load Balancer 产品家族来讲。于是一个词既像“总称”，又像“旧叫法”，还像“我脑子里那个老实例”，混乱就来了。

我自己看这类架构图时，最怕的不是概念多，而是概念边界不清。比如一个业务负责人说“我要上 SLB”，工程师第一反应应该追问：你要的是七层 HTTP 路由，还是四层 TCP 分发？是新建服务，还是迁移存量 CLB？是公网入口，还是 VPC 内部流量？这些问题不问清，后面就会变成“买了一个能用但不合适的东西”。

阿里云官方帮助中心现在给出的入口也很明确：负载均衡 SLB 产品家族包括应用型负载均衡 ALB、网络型负载均衡 NLB、传统型负载均衡 CLB。换句话说，SLB 是这组能力的产品家族名，不是今天选型时最后落地的唯一答案。

图 2：真实截图。阿里云官方文档把 ALB、NLB、CLB 放在 SLB 产品家族下面做对比。

二、先用小学生能懂的比方讲清楚

把一个网站或系统想象成一栋大楼。每天有很多人来办事，有人来查资料，有人来交材料，有人来取东西，有人只是走快速通道。大楼不能让所有人直接冲进每个办公室，否则门口会乱，办公室也会被挤爆。

这时候需要一个“收发室”：

• 它先接住所有来访的人。
• 看每个人手里的单子写的是什么。
• 判断哪个窗口现在空、哪个窗口坏了、哪个窗口排队太长。
• 再把人分到合适的窗口。

负载均衡做的事情就很像这个收发室。用户请求先进负载均衡，负载均衡再把请求分给后端服务器。如果某台服务器健康检查失败，负载均衡就不再把新请求发过去，避免用户撞上坏窗口。

区别在于，不同柜台“看标签”的能力不一样：

• ALB 看得很细：这个人是来办“网页业务”的，单子上写着哪个域名、哪条路径、哪个 Header、哪个 Cookie，所以可以按业务规则分流。
• NLB 看得很快：它主要看协议、端口、连接，适合大量人快速过闸，尤其是 TCP/UDP 长连接。
• CLB 是传统综合窗口：很多老业务都在它上面，四层和基础七层都能做，但高级七层路由、云原生集成、弹性模型不是它最擅长。

图 3：把请求想成快递。ALB 看业务标签，NLB 看通道和连接，CLB 是老牌综合窗口。

三、ALB 是什么：懂 HTTP 业务规则的七层入口

ALB，全称 Application Load Balancer，中文是应用型负载均衡。它专门面向 HTTP、HTTPS、QUIC 等应用层负载场景。官方文档里也强调，ALB 具备弹性和大规模应用层流量处理能力，能处理复杂业务路由，并且是阿里云官方提供的云原生 Ingress 网关。

这句话听起来有点官方，我们拆开看。

所谓“七层”，你可以理解成它不只是看到“有人从某个端口进来”，还看得懂“这个 HTTP 请求想访问哪个域名、哪条 URL、带了什么 Header、Cookie 里有什么”。这就像前台不是只看你从哪个门进来，而是会看你预约了哪个科室、拿着什么材料、是不是 VIP 通道。

ALB 适合这些场景：

• 一个域名下面有很多路径：/api 给 API 服务，/static 给静态资源服务，/admin 给后台服务。
• 想基于 Header、Cookie、查询字符串、请求方法做灰度发布。
• Kubernetes 里要做 Ingress，对接 ACK、ASK 或云原生应用。
• HTTPS、QUIC、gRPC、SSE 这类应用层协议是核心入口能力。
• 需要和 WAF、证书、安全策略、全链路 HTTPS 等能力组合。

特别是现在大模型应用越来越多，SSE 流式返回很常见。ALB 官方文档已经明确写到支持 SSE 流式传输，在大模型 AI 应用中可实时返回推理结果。这类需求就明显更偏 ALB，而不是简单四层分发。

图 4：真实截图。ALB 页面强调 HTTP、HTTPS、QUIC、复杂路由和云原生 Ingress。

四、NLB 是什么：扛连接、扛吞吐的四层入口

NLB，全称 Network Load Balancer，中文是网络型负载均衡。它面向四层，也就是更靠近 TCP、UDP、TCPSSL 这些网络连接本身。官方文档把它描述为面向万物互联时代的新一代四层负载均衡，支持超高性能和自动弹性能力，单实例可以达到 1 亿并发连接。

如果 ALB 是懂业务单子的前台，NLB 更像高速收费站。它不会细读你车里的每一份文件，但它能让海量车辆快速、稳定、低延迟地通过。对很多系统来说，这正是最重要的能力。

NLB 适合这些场景：

• TCP/UDP 长连接很多，比如 IoT 设备、车联网、视频监控、智能家居。
• 音视频、游戏、消息服务、网关服务，追求低延迟和高并发。
• 要做 TCPSSL 卸载，集中管理证书，减轻后端压力。
• 要挂载 IP 类型后端，结合云企业网把流量分发到跨 VPC、跨地域或线下 IDC。
• 业务入口不是典型 HTTP 网站，而是更底层的网络协议服务。

很多人会问：既然 ALB 也很强，为什么还需要 NLB？答案是“看标签”和“过闸速度”是两种能力。你要按 URL 路由，NLB 不合适；你要海量 TCP 长连接，ALB 也不是最优入口。不要拿前台去当高速收费站，也不要让收费站去读复杂合同。

图 5：真实截图。NLB 页面强调四层、超高并发、自动弹性、TCP/UDP/TCPSSL。

五、CLB 是什么：传统型，不等于不能用

CLB，全称 Classic Load Balancer，中文是传统型负载均衡。它是将访问流量根据转发策略分发到多台后端云服务器的流量分发控制服务。它支持 TCP、UDP、HTTP、HTTPS，具备良好的四层处理能力，以及基础七层处理能力。

“传统型”这三个字很容易让人误会，好像它已经没价值了。这个理解不准确。CLB 的优势是成熟、常见、老系统里大量存在，简单四层转发和基础七层场景依然能稳定工作。真正的问题是：新系统选型时，不要因为习惯就直接买 CLB。

如果你是存量业务，CLB 已经稳定运行，规则也不复杂，迁移成本高，那短期继续用 CLB 是合理的。反过来，如果你正在搭一个新入口，而且明确需要云原生 Ingress、高级七层路由、HTTP/QUIC/gRPC/SSE，那应该先看 ALB；如果明确是大规模四层连接，那应该先看 NLB。

还有一个现实提醒：官方文档显示，CLB 包年包月实例已在 2024 年 12 月 01 日 00:00:00 停止新购。这个信号不代表 CLB 立刻不能用，但足以说明阿里云的产品演进方向已经转向 ALB/NLB 这类更新的负载均衡形态。

图 6：真实截图。CLB 是传统型负载均衡，支持四层与基础七层，适合不少存量和简单场景。

六、真正的选型方法：别背名词，先问 6 个问题

很多选型文章喜欢做大表格，但工程现场更需要一串能快速排除错误选项的问题。我通常会按这个顺序问：

第一，入口协议是什么？

如果主要是 HTTP、HTTPS、QUIC、gRPC、SSE，先看 ALB。如果主要是 TCP、UDP、TCPSSL，先看 NLB。如果是存量 CLB 上已有的 TCP/HTTP 简单入口，先评估继续 CLB 还是迁移。

第二，要不要看应用层内容？

要按域名、路径、Header、Cookie、请求方法、查询字符串做转发，选 ALB。只按端口、连接、四层协议分发，选 NLB。

第三，连接规模和延迟敏感度有多高？

如果是海量长连接、设备接入、音视频、消息通道，NLB 的定位更合适。如果是网站/API 请求量大、路由规则复杂，ALB 更合适。

第四，是否云原生？

Kubernetes Ingress、ACK/ASK、SAE、函数计算这些云原生集成，ALB 的定位更直接。NLB 也能做容器场景里的四层入口，但不要把它当成七层 Ingress 替代品。

第五，是否已有 CLB 存量？

存量系统不是一看到新产品就要迁。先看规则复杂度、访问峰值、计费模型、证书、健康检查、后端类型、回滚方案。如果只是简单入口，CLB 可以继续跑；如果新需求已经明显超出 CLB 的舒适区，再规划迁移到 ALB 或 NLB。

第六，谁来付公网带宽和容量的钱？

ALB、NLB、CLB 的计费和 LCU 定义不完全一样。选型不能只看技术名词，还要结合公网 EIP、共享带宽、LCU、实例费、迁移期间双跑成本一起算。很多“架构上更优雅”的方案，最后会被账单教育。

图 7：第一轮选型矩阵。它不能替代压测和账单测算，但能快速避免方向性错误。

七、常见误区：这些话听起来对，其实很危险

误区 1：SLB 就是 CLB。

这是历史习惯带来的误会。今天写新文档、新架构图时，建议把 SLB 写成产品家族，把具体实例明确写成 ALB、NLB 或 CLB。否则后续沟通会越来越乱。

误区 2：ALB 比 NLB 新，所以都用 ALB。

新不等于覆盖所有场景。ALB 强在七层应用路由，NLB 强在四层高并发连接。你让 ALB 去承担不需要应用层理解的大规模 TCP/UDP 长连接，不一定是好设计。

误区 3：NLB 性能高，所以网站也用 NLB。

如果只是把网站的 80/443 端口转到后端，NLB 能做一些四层转发。但一旦你需要按路径转发、按 Header 灰度、重写、重定向、WAF 深度集成，还是应该回到 ALB。

误区 4：CLB 是老产品，所以必须马上迁走。

迁移不是为了追新名词，而是为了降低风险或获得新能力。存量 CLB 如果稳定、规则简单、成本可控，可以先继续维护；如果遇到七层路由能力不足、弹性或云原生集成受限，再做迁移计划。

误区 5：只要有健康检查就万事大吉。

健康检查只是避免把流量转给明显不健康的后端。它不能替你解决应用慢查询、数据库拥塞、线程池打满、后端半死不活但端口还通的问题。负载均衡是入口，不是万能药。

八、Q&A

Q1：新建 Web/API 服务，默认选哪个？

优先看 ALB。尤其是要做 HTTPS、域名路径转发、灰度发布、重定向、Header/Cookie 规则、Kubernetes Ingress、SSE 流式响应时，ALB 更贴近需求。

Q2：新建 TCP/UDP 长连接服务，默认选哪个？

优先看 NLB。比如 IoT 设备接入、音视频、消息网关、游戏入口、TCPSSL 卸载、大规模连接保持，这些都是 NLB 更擅长的方向。

Q3：CLB 还能不能用？

能用。它是传统型负载均衡，不是“立刻废弃”。但新业务不建议无脑继续用 CLB，要先看 ALB/NLB 是否更匹配。存量 CLB 迁移前要做规则、证书、健康检查、后端类型、回滚路径和计费对比。

Q4：ALB 和 NLB 都能对外提供公网入口吗？

可以按产品能力和实例类型配置公网或私网入口，但具体要看地域、可用区、EIP、共享带宽、配额和当时控制台可选项。线上架构不要只看概念图，必须对照当前地域实际可购买能力。

Q5：为什么官方说 ALB 单实例可到 100 万 QPS，NLB 单实例可到 1 亿并发，我是不是就不用压测了？

不能。官方指标说明产品上限和弹性能力，不等于你的应用端到端链路能达到这个数。后端服务、数据库、缓存、跨区链路、证书、WAF、限流策略都可能成为瓶颈。负载均衡很强，但它不会让后端代码自动变强。

Q6：这篇为什么不提供 Windows、Ubuntu、macOS 一键脚本？

因为本文不是在某台机器上“安装或修复一个配置”的操作型文章，而是负载均衡产品概念和选型文章。真正创建 ALB/NLB/CLB 涉及账号、地域、VPC、交换机、证书、后端服务器组、计费方式和安全策略，不应该给一个脱离上下文的一键脚本让读者直接执行。

九、最后给一张决策小抄

如果你只想带走一个判断：

• 看得懂 HTTP 内容，按业务规则转发：ALB。
• 不关心 HTTP 内容，重点是 TCP/UDP 连接规模：NLB。
• 已有老实例、简单四层或基础七层、迁移成本高：CLB。
• 讨论产品家族、总称和文档入口：SLB。

负载均衡这东西，看起来只是“把流量分给后端”，但选错以后会影响证书、域名、WAF、Ingress、灰度、带宽、账单、灾备和迁移路径。别把它当成最后随手补上的网络零件，它其实是整个应用入口的门面。

参考资料

• 阿里云帮助中心：负载均衡 SLB 产品家族介绍
• 阿里云帮助中心：什么是应用型负载均衡 ALB
• 阿里云帮助中心：什么是网络型负载均衡 NLB
• 阿里云帮助中心：什么是传统型负载均衡 CLB