负载均衡选型别再懵CLB、ALB、NLB、GWLB 到底怎么分怎么选负载均衡这词做后端、运维、架构的同学基本天天听但真被问到“CLB、ALB、NLB、GWLB 到底有什么区别我该选哪个”的时候很多人的脑子是懵的。我自己带团队做架构评审时几乎每轮都会遇到把应用型负载均衡当四层用、把网关型负载均衡当普通入口代理用的案例。今天这篇就把这几个概念彻底理顺不绕弯子直接从定义、协议、适用场景、选型逻辑、部署细节和成本权衡讲清楚。1. 先把四个缩写背后的定位搞清楚1.1 CLB 是“老大哥”但不是“过时”的代名词传统型负载均衡Classic Load Balancer简称 CLB是云厂商最早提供的一类负载均衡产品它的设计思路非常直接对外暴露一个统一入口VIP然后把流量按一定策略转发给后端的多台服务器。CLB 同时支持四层TCP/UDP和七层HTTP/HTTPS转发端口映射灵活配置相对简单所以在很多老系统里服役多年稳定性经受住了大量考验。但 CLB 也有一些明显的短板。最典型的是“全能但不够精”四层性能上限有限高并发场景容易成为瓶颈七层功能虽然都有但像高级路由规则、跨域、灰度发布这类能力和后来的应用型负载均衡比起来就显得粗糙。所以云厂商几乎都建议新业务优先考虑 ALB 或 NLBCLB 更多是作为存量系统的兼容方案存在。1.2 ALB 是“七层专家”路由能力拉满应用型负载均衡Application Load Balancer简称 ALB主打 HTTP/HTTPS 协议层面的处理。它和 CLB 最大的差异是ALB 懂应用协议它能看 URL 路径、Host 头、查询参数、请求头甚至 Cookie然后按照这些内容把请求路由到不同的服务。打个比方CLB 像一个物业前台所有快递都收但只按“几号楼”粗分ALB 则是一个懂业务的秘书它知道“财务文件送财务部、技术合同送技术部”还能根据文件重要性走不同的签收流程。所以微服务架构、容器集群、HTTP 网关这类场景ALB 基本是标配。1.3 NLB 是“纯粹的四层机器”性能决定一切网络型负载均衡Network Load Balancer简称 NLB只关心传输层也就是 TCP/UDP。它的核心卖点是性能单实例百万并发连接是基操转发延迟做到微秒级而且支持弹性 IP 绑定、保留客户端源 IP、静态 IP 等硬核特性。NLB 非常适合长连接场景。比如游戏服务器、金融行情推送、消息中间件Kafka/RocketMQ入口、数据库读写分离代理等这类流量不需要七层那么花哨的路由逻辑但绝对不能丢包、不能被四层性能卡死。NLB 在架构里往往扮演“扛流量入口”的角色后面再挂 ALB 或业务集群做精细分发。1.4 GWLB 是“流量中间人”帮所有流量做安全过滤网关型负载均衡Gateway Load Balancer简称 GWLB可能是四个里最容易被忽略的但它的定位非常有趣它不直接终结流量而是把流量先引给一串第三方设备防火墙、入侵检测、审计系统、WAF 等等这些设备处理完再把流量交还给后端业务。所以 GWLB 的典型口号是“在不改动业务架构的前提下给流量插入一道安全或者增值服务流程”。比如你想给所有南北向流量加一层透明防火墙传统做法是改链路拓扑有了 GWLB 只需把流量导向 GWLB 实例由它分发到防火墙集群处理完再回注业务侧完全无感。这个设计思路和 Service Mesh 里的“Sidecar 透明拦截”有异曲同工之处只不过它作用在网络基础设施层。2. 一张表看懂四者差异选型前先看这里2.1 核心维度对比维度CLBALBNLBGWLB协议支持TCP/UDP/HTTP/HTTPSHTTP/HTTPS/gRPC/WebSocketTCP/UDP/TLSIP承载任意协议转发依据IP端口URL/Host/Header/参数IP端口/连接数IP端口性能定位中等中等偏上极高百万并发起步依赖后端设备保留客户端源IP部分支持需代理协议支持X-Forwarded-For原生支持原生支持典型场景存量系统兼容、简单负载微服务网关、K8s Ingress高并发长连接、数据库入口安全设备接入、流量过滤编排配置复杂度低中低中高价格趋势低但性能有限中高中高性能溢价中按实例流量这个表值得打印出来贴在工位上。但我要强调不要只看“协议支持”那一行做决定真正影响体验的是“场景匹配度”下面第三节逐步展开。2.2 为什么不能只看协议范围做选型举个例子你的对外服务只是一个小商城HTTP/HTTPS 流量不大但你对延迟很敏感。如果只看协议范围CLB 和 ALB 都能选但两者在路由精细度、监控指标、与容器体系的集成度上差别非常大。CLB 虽然便宜但如果你后续要按版本灰度、按地域切流会发现 CLB 的路由规则根本无法支撑最后还得更换成 ALB迁移成本反而更高。反过来如果你的业务是极致的性能导向如高速交易撮合而你在入口处硬套一个 ALB看着路由很好用但七层处理本身就要消耗 CPU 解析报文延迟比 LVS 类方案高一截。正确的做法可能是 NLB 做入口业务内再用 ALB 或者应用层框架做细分路由。所以我的建议是选型不是选“最强”的而是选“适应你流量模型和发展节奏”的。先明确你的流量是短连接 HTTP 还是长连接 TCP再看是否需要精细路由、是否依赖客户端真实 IP、是否需要在流量路径上插入安全设备这四个问题回答完答案基本自己浮出来。3. 核心应用场景拆解直接判断你的业务该用哪个3.1 Web 应用与微服务ALB 当主力CLB 可兜底现在绝大多数 Web 业务都是前后端分离 微服务化的形态。入口流量是 HTTP/HTTPS需要按路径把请求分发到网关、用户服务、订单服务等不同集群还需要支持灰度发布的权重调整。这种场景直接上 ALB路由规则五元组齐全Host、Path、Header、Query、Method一个监听器就能覆盖复杂的转发需求原生支持与容器服务/K8s 联动Ingress Controller 底层就是调 ALB 实现动态路由灰度发布可以直接在负载均衡层切权重不需要业务代码配合。如果你团队小、预算紧、业务流量也就几百 QPSCLB 也能撑住但你要接受后续可能迁移 ALB 的成本。我个人体会是新项目只要预算不是极端敏感直接上 ALB省得以后和研发吵路由需求。3.2 游戏、消息、数据库等长连接场景NLB 是不二之选游戏登录服、消息推送、Kafka 客户端接入、MySQL/Redis 代理入口这些流量的共同点是连接建立时间长、并发连接数高、单个请求的协议非常简单大部分是自研或二进制协议而且客户端 IP 经常要透传给后端做限流或日志分析。NLB 在这种场景下的优势是无可替代的单实例支持百万级并发连接且 CPU 开销极低保留客户端源 IP后端不用修改架构就能拿到真实 IP支持固定 IP 和弹性 IP客户端白名单不用频繁变更转发链路短、延迟低对游戏、行情类业务至关重要。我踩过的坑是早期为了贪便宜用了 CLB 做 TCP 转发结果高峰期连接数一上来CLB 的连接建立吞吐直接打满业务侧报“Connection timed out”排查半天才发现瓶颈在负载均衡器。后来切到 NLB压力瞬间消失。所以对这种场景我只有一句话别省那点钱NLB 就是为这种流量设计的。3.3 防火墙、IDS 等安全设备接入GWLB 承担“透明代理”角色很多企业有合规要求所有南北向流量必须经过防火墙或审计系统。传统做法是在核心交换机上旁路部署但流量大了之后防火墙集群要扩容链路配置非常痛苦。GWLB 的出现就是解决这个问题的把防火墙/IDS/审计设备挂在 GWLB 后端以“透明网关”方式接入流量的进出完全不用改业务代码也不用改 DNS 或 VIP安全设备可以横向扩展GWLB 负责把流量分配给它后面的设备集群支持健康检查和故障剔除某台防火墙挂了流量自动切到其他节点。这里的“透明”是我特别想强调的GWLB 不修改报文只是做转发编排所以业务看到的目标地址、源地址基本不变链路就像插了个不会卡脖子的“流量适配器”。如果你的安全体系已经比较重但网络拓扑又不允许大改GWLB 几乎是唯一不影响业务的高可用方案。3.4 CLB 的坚守阵地存量系统和轻量场景说实话我在新项目里已经很少用 CLB 了但存量系统里它依然是主力。很多老业务上线早运维同学已经吃透了 CLB 的配置和监控口径贸然换负载均衡器容易引发不可控故障。这种情况下最容易踩的雷就是“没想清楚就迁移”如果只是把 CLB 换成 ALB监听器、证书、健康检查全部要重新配一遍后端实例组绑定方式不同云厂商的 CLB 和 ALB 在 API 和 Tag 规范上也有差异老业务里可能到处写死了 CLB 的 VIP 或 CNAME迁移时要全量排查。所以我对存量系统的建议是CLB 先留着稳定运行比什么都重要。等你要做下一轮功能升级或架构改造时再一并考虑迁移到 ALB/NLB。另外CLB 用于一些轻量场景比如内部管理后台的单一入口依然是性价比不错的选择毕竟它便宜、部署快、监控老牌成熟。4. 选型前的四个灵魂拷问配合成本和运维视角4.1 流量是短连接还是长连接短连接为主如普通网站 API选 ALB 或 CLB靠七层路由做精细管理长连接、大并发如游戏、消息选 NLB。这个判断会在开头就确定大方向比盯着参数表纠结半天高效得多。4.2 是否需要透传客户端真实 IP做限流、风控、日志分析的基本都需要真实 IP。NLB 原生支持源 IP 透传ALB 通过 X-Forwarded-For 头也能把客户端 IP 传给后端但要求后端应用明确信任并提取该头CLB 则要看配置方式。这个细节在合规审计类项目中是硬要求千万别等上线后才发现日志里全是负载均衡器的 IP。我见过不止一个团队在这上面返工——后端拿到的 IP 全是负载均衡内网 IP风控系统直接失效排查了两天才定位到是负载均衡层没有开启透传。4.3 是否需要七层精细化路由如果你有按 URL 做 A/B 测试、按 Header 切流量、按 Cookie 做会话保持等需求答案只能是 ALB。NLB 和 GWLB 不看这些字段CLB 的七层路由能力偏弱。顺便说一句云原生时代K8s 的 Ingress 规则很多都是映射到 ALB 的如果你已经上了容器平台ALB 和 K8s 的集成度会让你的工作量骤减。4.4 流量路径上是否需要插入安全/增值设备如果有GWLB 基本是唯一合适的产品。它和 WAF 防火墙的配合模式是把安全设备挂到 GWLB 后端而不是传统意义上“串接在链路上”。这样设备扩容、版本升级都不会影响主链路。5. 真实踩坑记录从“能用”到“好用”差在哪5.1 只盯着功能列表忽略了健康检查的设计我见过不止一个项目ALB 配好后一切正常但后端某台实例挂了之后流量并没有被摘除大量请求打到故障实例上导致局部错误率飙升。排查发现健康检查路径配成了一个不存在的 URL负载均衡器以为后端都还健康自然不摘除。健康检查不是“有就行”需要认真设计检查路径最好落到一个真实且轻量的接口不要返回大量 JSON 数据超时时间、间隔时间和不健康阈值要按业务抖动容忍度调整对依赖数据库的接口健康检查里最好不要带 DB 查询否则 DB 抖动会让整个实例被判不健康。5.2 会话保持配置错误导致登录态反复失效七层负载均衡默认不保留客户端会话如果你后端没有做分布式会话必须开启“会话保持”一般基于 Cookie。我遇到过因为 ALB 的会话保持配置写错目标应该绑定后端服务器组结果绑到监听器导致用户每次请求都落到不同实例session 一直丢客户投诉不断。这类问题最恶心的点是“偶发”不压测很难复现。我的经验是上线前专门写一个脚本来验证“连续多次请求是否命中同一后端”把它列入发布检查清单而不是等出事了再查。5.3 只看实例规格忽略了带宽与配额上限选 NLB 的时候很多人只纠结“单实例支持多少连接数”却忘了看带宽上限和并发新建连接数上限。连接数和新建连接速率是两个不同的指标连接数再高如果新建连接速率被限制秒杀场景照样被卡死。另外一个坑是负载均衡实例的后端服务器数量上限。你的业务如果规划要挂几百台后端必须提前确认所选产品和服务配额是否支持别上线前才发现配额不够临时提工单等审批。6. 坦白说的个人选型心法给你一个可落地的清单6.1 新项目默认首选 ALB NLB 的组合需要安全链时再叠加 GWLB经过大量项目实践后我的默认推荐其实是对外 HTTP 服务统一用 ALB因为它在路由和可观测性上最完善数据库、消息中间件、游戏等长连接入口统一用 NLB因为性能最稳只有当网络路径上必须插安全设备时才引入 GWLB。6.2 存量业务“先稳定再平滑升级”绝不做大版本跨越对于已经跑了几年的 CLB 老业务我的态度一直是不急着换。但一旦决定换就要走“验证—灰度—切换—观察—下线”的完整流程。先在测试环境验证配置和证书再用 5% 流量灰度接着逐步切流切换后连续稳定运行一周再下线旧实例。这样虽然慢但最安全。6.3 监控与告警做在前面比产品选型更关键负载均衡器是流量入口它的健康状态直接决定业务可用性。务必把以下指标加入监控面板活跃连接数、新建连接速率、丢弃数据包数后端健康检查失败次数流量吞吐与带宽使用率证书过期时间这个太容易漏了证书过期无声无息直到用户浏览器报警才发现。7. 一些容易忽略但很实用的细节7.1 关于会话保持的“粘性”设计在使用 ALB 时如果后端业务是单机 session你要配置“基于 Cookie 的粘性会话”让同一客户端的请求始终落到同一台后端。这里还有两个注意点选择 Cookie 作为粘性依据时后端应用不能调用 Set-Cookie 覆盖负载均衡器注入的 Cookie如果业务中有 WebSocket 长连接注意 ALB 对 WebSocket 的支持默认是开启的但粘性会话对 WebSocket 的处理可能和普通 HTTP 不同。7.2 关于证书的管理ALB 和 CLB 都可以挂 HTTPS 证书但最佳实践不是把证书直接扔给负载均衡器而是用云厂商的证书管理服务统一管理到期前自动提醒甚至可以配置自动续签。证书过期导致的服务中断是我见过最“低级”但也最频繁的线上事故之一。7.3 关于跨可用区部署负载均衡器本身是跨可用区冗余的但后端服务器也要尽量多可用区部署。如果只在单可用区挂后端那么负载均衡器即使跨区冗余流量也会全部集中到那个区可用性反而降级。8. 总有一款适合你的业务但别滥用“唯一解”说句实话负载均衡器的选型没有一劳永逸的标准答案CLB、ALB、NLB、GWLB 四者也不是互相替代的关系更多是各司其职。CLB 是老朋友稳定、简单ALB 是七层大脑精细、智能NLB 是四层猛将高速、硬核GWLB 是安全纽带透明、灵活。我在实际项目里最深的体会是先理解流量再选产品。不要因为某个产品“听起来高大上”就硬套也不要因为“便宜”就忽视性能风险。把流量模型和应用需求搞清楚再结合成本、运维能力和后续演进方向做决定就不会出现“用错负载均衡器导致重构”这种痛苦局面。最后分享一个小技巧选型时多看看云厂商发布的性能白皮书和配额文档上面写的新建连接速率、每秒并发能力、后端可挂载实例数往往比销售话术可靠得多。把关键指标提前列成表格对比你的选型决策会轻松很多也不会被各种概念绕晕。