负载均衡 CLB、ALB、NLB 怎么选：一张性能对比表加三笔账单

结论先放这里：七层选 ALB，四层海量连接选 NLB，CLB 只在存量或极简场景继续用。选错类型不会立刻出错，但账单和排障成本会在事后找上来。

一、SLB 是产品族，不是单个产品

很多人以为 SLB（Server Load Balancer）就是控制台里那个"传统型负载均衡"，其实现在它是一个产品族，下面三个成员：

三者共用一个控制台入口，但底层架构、性能模型、计费模型都不一样。把 CLB 当成"默认选项"直接下单，是后面所有麻烦的起点。

二、性能天花板：三个数量级差异

官方文档给出的单实例性能上限如下（均为单实例、非集群聚合值）：

这张表里最值得注意的不是绝对数字，而是"是否需要自己预估峰值"。

CLB 的性能保障型实例是按规格卖的，你买的是 s1.small 还是 s3.large，决定了它能扛多少连接、多少 CPS、多少 QPS。到了大促临时加两台后端，规格不会跟着涨，超了就直接丢连接。ALB 和 NLB 是按用量计费的自动弹性模型，不存在"规格不够"这个操作失误。

三、能力边界：七层特性只在 ALB 完整

几个实际后果：

• 想做"同一域名下 /api 转 A 组、/static 转 B 组"，CLB 做不到基于路径以外的内容路由；ALB 一行转发规则解决。
• 想按 Cookie 做灰度（先放 5% 用户到新版本），CLB 没有这个能力，只能靠 DNS 权重或应用层自己写。
• 想要"发布时不再丢请求"，需要优雅中断。CLB 没有，滚动发布期间必然有少量 502/504。

四、健康检查：默认参数一样，可调范围不一样

默认值在 CLB 与 ALB 上基本一致（以官方文档为准）：

由此可以算出一个容易被忽略的数字：故障发现时间 ≈ 检查间隔 × 不健康阈值。默认 2 秒 × 3 次 = 6 秒。也就是说后端进程挂掉之后，仍然有大约 6 秒流量会打到它上面。如果业务对这段时间敏感，把间隔调到 1 秒、不健康阈值调到 2 次，能压到 2 秒左右，代价是探测频率翻倍。

反过来，探测量大的时候把间隔拉长到 10~30 秒可以减少对后端的干扰，但故障切换就会变慢。这是纯粹的取舍，没有最优解。

两个坑：

1. 不要把 4xx/5xx 加进健康状态码。看着好像"只要服务器有响应就算活着"，实际上 500 的实例会被判定为健康继续接流量。
2. 健康检查路径不要探业务接口。业务接口依赖数据库，数据库抖一下，所有后端集体被判不健康，健康检查自己变成故障放大器。建议单独给一个静态页，如 /healthz.txt。

五、三笔账单：CLB 的规格费是隐性成本

第一笔：CLB 按使用量计费

CLB 自 2024-12-01 起调整了计费项，原来的"实例费"改名为"公网IP保有费"，另外新增了实例费。目前按使用量计费的公网 CLB 包含四项：

LCU 的换算规则（TCP）：新建连接 800 个 / 并发连接 10 万个 / 处理数据量 1 GB 各算 1 个 LCU，一个小节内取最大值而不是累加。

第二笔：CLB 按规格计费（已停售，仅存量）

按规格计费实例已于 2026-01-01 起停止新购，包年包月 CLB 也早已停售。存量实例仍在按规格计费，这部分成本是固定的——业务量降下来，规格费也不会降。

第三笔：ALB 按量计费

ALB 的 LCU 系数比 CLB 的 HTTP 场景更宽松一点（新建连接 25 个 / 并发连接 3000 个 / 1 GB 流量 / 规则评估 1000 个各算 1 LCU），同样取最大值。但规则评估数是 ALB 特有的成本项：转发规则、AScript 脚本行数、扩展证书数量，三项各有 25 个免费额度，超出部分按 QPS × 超出数量 累加。规则攒到五六十条、QPS 又高的实例，这一项会成为主要成本，而不是带宽。

以上均为产品目录价，随地域与活动变动，实际价格以官方页面实时展示为准。

六、选型决策：四个问句定下来

按顺序问，命中就停：

第一问：需要七层（HTTP/HTTPS）能力吗？
需要 → 进第二问。不需要（纯 TCP/UDP，如数据库代理、游戏长连接、MQTT）→ 直接 NLB。

第二问：需要基于内容的路由、灰度、重写吗？
需要 → ALB。只是简单按域名分发 → 进第三问。

第三问：QPS 会不会超过 5 万，或者并发连接会不会超过 100 万？
会 → ALB（自动弹性）或 NLB（四层场景）。不会 → 可以继续用 CLB，但注意规格已停售，新购只能选按使用量计费。

第四问：是不是已经在用 CLB，且没有明显痛点？
是 → 可以不动。迁移本身有成本，为了"用新产品"而迁移不划算。等下一次架构调整时一起换。

一句话版本：

• 互联网 Web 应用、API 网关、需要灰度 → ALB
• IoT、车联网、音视频、纯四层大流量、需要 TCPSSL 卸载 → NLB
• 老系统、内网简单四层、对成本极敏感且量很小 → CLB

顺便说一个容易混淆的点：公网 ALB 的公网能力是通过绑定 EIP 提供的，意味着你会同时看到 ALB 账单和 EIP 账单。做成本核算时别只盯着负载均衡这一栏。

七、上手指路（以 ALB 为例）

1. 建实例：选地域、VPC、交换机（建议至少两个可用区），功能版本按是否需要 WAF 增强决定。
2. 建服务器组：选后端类型（ECS / IP / ECI / FC），配置健康检查。静态页路径、2 秒间隔、3 次阈值是稳妥起点。
3. 建监听：HTTP 80 与 HTTPS 443 分开建，HTTPS 监听上挂证书。
4. 配转发规则：默认规则兜底，再按域名或路径加规则。规则数量注意 25 条免费额度。
5. 验证：先挂一台后端，用 curl 直接打 ALB 的 IP 与端口确认连通，再逐步加后端。
6. 切流量：DNS 改 CNAME 到 ALB 的 DNS 名称，TTL 提前调小。

命令行自查的几个常用动作：

# 确认后端端口在安全组层面是否放通（从同 VPC 的另一台机器执行）
nc -zv 192.168.1.10 8080

# 确认健康检查路径返回 200
curl -s -o /dev/null -w "%{http_code}\n" http://192.168.1.10:8080/healthz.txt

# 确认 DNS 已切到负载均衡
dig +short www.example.com

# 多次请求看是否轮转到不同后端（后端需回显自身 IP）
for i in $(seq 1 10); do curl -s http://www.example.com/whoami; echo; done

如果第 2 步返回的不是 2xx，先别急着查负载均衡，九成是安全组没放通负载均衡的健康检查源段，或者后端服务只监听了 127.0.0.1。

八、八个容易踩的点

1. 把 CLB 当默认选项：新项目直接用 CLB，等要灰度、要路径路由时才发现不支持。
2. 健康检查探业务接口：数据库一抖，全线摘除。
3. 健康检查路径需要登录：返回 302 到登录页，判定不健康，所有后端同时下线。
4. 健康状态码加了 5xx：500 的实例继续接流量。
5. 只在一个可用区建后端：负载均衡本身高可用，后端全在同一可用区，可用区故障照样全挂。
6. ALB 规则数超 25 条不设预算：规则评估数会让 LCU 账单跳一个量级。
7. 公网 ALB 忘了算 EIP 账单：负载均衡这栏很便宜，EIP 那栏不便宜。
8. CLB 实例只停机不释放：停止实例只暂停转发，实例费、公网IP保有费照收；要停计费只能释放。

九、给准备上云的同学

负载均衡是"用一次就一直用"的基础设施，选型的边际成本很低，但换型的成本很高——涉及 DNS 切换、会话中断、灰度窗口。所以第一次选的时候花半小时把上面四个问句走一遍，比后面返工划算得多。

官方产品页对各型号的能力、规格、计费有完整说明，动手前建议对着页面把自己场景的 QPS、并发连接、出流量三个数估出来，再去 LCU 估算器里跑一遍，账单就基本不会失控：

阿里云负载均衡 SLB 产品页（CLB / ALB / NLB 全系）