ALB、NLB、GWLB、CLB怎么选？

[🧠 ALB：七层应用层的"大脑"](#🧠 ALB：七层应用层的“大脑”)

[🚀 NLB：四层网络层的"性能引擎"](#🚀 NLB：四层网络层的“性能引擎”)

[🛡️ GWLB：安全设备集群的"透明插头"](#🛡️ GWLB：安全设备集群的“透明插头”)

[📦 CLB：一个时代的"经典款"](#📦 CLB：一个时代的“经典款”)

[✅ 怎么选？一张表看懂](#✅ 怎么选？一张表看懂)

重点一：其实如果你看懂下面这张图，后面的内容你都不需要看了：

如果你需要用HTTPS协议，那NLB可以不用看了，不支持；

如果你要用UDP协议，ALB也不用看了，不支持；

如果你即想用HTTPS协议，又想用UDP协议，那唯一选择就是CLB。

重点二：创建CLB虚拟服务器组比较重要，可以挂多个业务负载群

重点三：GWLB是三层的负载均衡，这个主要是流量分发至后端健康的网络虚拟设备，以实现安全防御、网络分析等目的，一般用在部署网络边界防火墙、第三方安全与检测服务等等，通常被部署在 ALB/NLB 的前端或后端，作为整个架构的安全护城河

阿里云的负载均衡产品线，现在一共有四款：ALB、NLB、GWLB，还有一款老同志CLB。很多刚接触的朋友容易搞混，它们名字听着像，但各自管的活儿、擅长的领域，其实差别很大。

如果非要一句话概括，大概是这样的：

下面拆开说说它们各自的脾气秉性。

如果你需要的是一个能"看懂"用户请求内容的负载均衡，那ALB是首选。它工作在七层（应用层），专门处理HTTP、HTTPS、QUIC这类协议。

它最核心的能力是基于内容的路由 。比如，你可以设置规则：所有访问 api.example.com 的请求，转发到"订单服务"集群；所有访问 www.example.com/static/* 的请求，转发到"静态资源"服务器。

因此，它特别适合：

它的"聪明"是用一点延迟换来的，因为需要解析HTTP头部，但单实例百万级QPS的性能，对绝大多数业务来说绰绰有余。

当你的核心诉求是"快、稳、省"，不关心请求内容是什么，只关心能不能高效地转发出去，那就要看NLB了。它工作在四层（传输层），主要处理TCP、UDP和TCPSSL流量。

它的特点就一个字：猛。单实例可以支撑1亿并发连接，延迟能低到微秒级。它不解析HTTP，只做端口转发，把SSL加密解密的苦活累活也在自己这儿卸掉（SSL卸载），给后端服务器减负。

它最适合的场景是：

简单说，NLB面向的是"机器与机器"的通信，ALB面向的是"人与应用"的通信。

GWLB的定位很特殊，它不是给普通业务应用用的，而是给网络和安全团队用的。你可以把它理解成一个透明的流量"分发器"和"转发器"。

它的工作方式是，把通过它的流量，原封不动地 （透明地）转发给你部署在后端的第三方虚拟安全设备集群，比如**防火墙（NGFW）、入侵检测/防御系统（IDS/IPS）、深度报文检测（DPI）**等。

它解决的问题是：以前你要在流量路径上串一个防火墙，得改网络拓扑，很麻烦。现在有了GWLB，可以把安全设备做成一个集群，GWLB负责把流量引过去检查，检查完再送回来，对业务流量完全透明，实现了"安全服务链"。

最后说CLB。它是阿里云负载均衡最早的产品形态，可以同时支持四层和七层，功能比较基础。

它的主要问题是，ALB和NLB基于新一代架构，支持自动弹性伸缩，业务高峰来了自己能扩容，而CLB用的是物理机架构，规格需要手动预估和申请，在流量突增时可能不够灵活。

阿里云官方的态度也很明确：存量业务可以继续用，但新建项目，强烈建议优先考虑ALB和NLB。

说了这么多，你大概也清楚了。这里总结一个更聚焦实战场景的选型建议：

你的业务长这样	闭眼选这个	原因
Web网站、API服务、微服务，需要根据URL、域名分发给不同后端	ALB	它是七层路由的行家，这些是它的基本功。
游戏服务器、物联网平台、高性能数据库代理，对延迟和并发要求极高	NLB	性能天花板，亿级连接、微秒延迟是它的招牌。
需要把流量先过一遍防火墙、入侵检测等安全设备，再回到业务	GWLB	它就是为这种"插播"安全节点的场景设计的。
传统业务上云，业务简单稳定，图省事不想折腾	CLB	够用，但确实有点过时了。