阿里云负载均衡（SLB，Server Load Balancer）是将外部请求按照设定的策略分发到多台后端服务器的流量分发服务。它解决两个核心问题：单台服务器在高并发下的性能瓶颈，以及某台服务器故障时业务中断的风险。通过负载均衡，多台 ECS 实例组成一个对外提供统一入口的服务集群，任何一台实例故障，流量自动切到其余正常实例，业务不受影响。
阿里云当前提供三种负载均衡产品：应用型负载均衡 ALB、网络型负载均衡 NLB 和传统型负载均衡 CLB。三者的定位、协议支持和适用场景各不相同，理解这三者的区别是正确选型的前提。
三种产品的定位与核心差别
ALB（应用型负载均衡）
ALB（Application Load Balancer）是阿里云当前主推的负载均衡产品，工作在网络七层，专门处理 HTTP、HTTPS、gRPC 和 QUIC 协议的流量。ALB 基于 NFV 虚拟化平台构建，支持弹性伸缩，单实例最大处理能力为 100 万 QPS，可以在不更换实例规格的情况下自动应对流量突增。
ALB 最核心的能力是内容路由：可以根据请求的域名、URL 路径、HTTP 请求头、查询字符串等条件，将不同请求精确分发到不同的后端服务器组。这一能力让 ALB 成为微服务架构中的流量分发枢纽——前端请求统一打到 ALB，由 ALB 根据路径将 /api/ 转发到 API 服务集群，将 /admin/ 转发到管理后台服务器，将其余请求转发到主站服务器。
ALB 同时支持 SSL 证书卸载：HTTPS 流量在 ALB 层完成 SSL 握手和解密，转发给后端服务器的是 HTTP 明文流量，后端服务器不需要单独处理 SSL，减少了服务器的计算开销。ALB 可以集中管理所有域名的 SSL 证书，证书续签只需在 ALB 层操作，后端无需任何变更。
ALB 默认使用 HTTP 长连接（keep-alive），单个 TCP 连接可以复用处理多个请求，在高并发场景下比短连接明显减少 TIME-WAIT 连接的积累，对应用服务器的压力更小。
NLB（网络型负载均衡）
NLB（Network Load Balancer）工作在网络四层，专注于 TCP、UDP 和 TCP-SSL 协议的流量处理。基于高性能网络转发架构设计，单实例支持 1 亿并发连接和 100 Gbps 带宽，转发延迟低至微秒级别，是三种产品中性能上限最高的。
NLB 不解析 HTTP 协议内容，不支持基于域名或路径的内容路由，所有路由决策基于网络层的 IP 地址和端口信息。由于处理逻辑比 ALB 更简单，NLB 的延迟更低，在对响应时间有极高要求的场景下优于 ALB。NLB 目前的实例费用限时免费，只按 LCU（性能容量单位）和公网流量计费，整体成本低于 ALB。
NLB 的典型使用场景：游戏服务器的 TCP 长连接管理、实时音视频流的 UDP 传输、IoT 设备的 MQTT 连接管理、高并发数据库代理。NLB 支持 TCP-SSL 证书卸载，适合在四层处理 SSL 加解密而不需要解析 HTTP 内容的场景。
CLB（传统型负载均衡）
CLB（Classic Load Balancer）是阿里云早期的负载均衡产品，同时支持 TCP、UDP 四层负载均衡和 HTTP、HTTPS 七层负载均衡，但七层能力相对基础，不支持基于 URL 路径的精细路由，也不支持 gRPC 和 QUIC 协议。CLB 从 2024 年 12 月起停止新购包年包月，存量业务仍然可以继续使用，但阿里云的新功能开发重心已转向 ALB 和 NLB。
对于新建业务，CLB 不是推荐的选择。需要七层路由能力选 ALB，需要高性能四层选 NLB，CLB 主要用于存量业务的延续，以及对配置方式已经熟悉、暂时不需要 ALB/NLB 新特性的简单场景。
三种产品的选型判断
| 维度 | ALB | NLB | CLB |
| 工作层级 | 七层（应用层） | 四层（网络层） | 四层 + 基础七层 |
| 支持协议 | HTTP、HTTPS、gRPC、QUIC | TCP、UDP、TCP-SSL | TCP、UDP、HTTP、HTTPS |
| 内容路由 | 支持（域名、路径、请求头） | 不支持 | 不支持 |
| 单实例上限 | 100 万 QPS | 1 亿并发连接 | 按规格划定 |
| 延迟 | 毫秒级 | 微秒级 | 毫秒级 |
| 当前状态 | 主推，持续迭代 | 主推，实例费免费 | 停止新购包月 |
| 适合场景 | Web、API、微服务 | 游戏、IoT、音视频 | 存量业务延续 |
选型判断可以用一个简单的判断流程来梳理：如果业务流量是 HTTP/HTTPS，或者需要基于域名和路径路由，选 ALB；如果业务是 TCP/UDP 长连接、要求极低延迟、或者并发连接数在千万以上，选 NLB；如果已有 CLB 实例且没有 ALB/NLB 功能需求，可以维持现状，但新建业务不应再选 CLB。
ALB 创建与配置要点
ALB 是大多数新建业务的默认选择，以下以 ALB 为重点说明关键配置步骤。
实例类型与网络选择
创建 ALB 实例时首先选择公网实例或私网实例。公网实例通过弹性公网 IP（EIP）对外提供服务，适合面向终端用户的 Web 应用和 API；私网实例只在 VPC 内部访问，适合微服务之间的内部流量调度，不产生公网费用。
ALB 实例必须在 VPC 内创建，且创建后所属 VPC 不能修改，这一点和 ECS、RDS 的规则一致。建议在同一次规划中确认 ALB、ECS、RDS 都在同一 VPC 内，避免后期因网络不通而需要重建。关于 VPC 和交换机的规划方式，可以参考 阿里云 VPC 网络配置教程。
创建 ALB 时建议选择多可用区部署，在至少两个可用区各选一个交换机。ALB 的多可用区部署是原生支持的，不需要额外配置，系统自动在多个可用区分配实例，任何单一可用区故障不影响整体服务，SLA 可以达到 99.995%。
监听规则配置
监听（Listener）定义了 ALB 接收哪个端口的请求，以及如何处理这些请求。创建监听时指定协议（HTTP/HTTPS）和端口（80 或 443），配置 SSL 证书（HTTPS 监听必须），以及默认的转发动作。
监听的核心是转发规则，通过条件和动作的组合控制流量走向：
- 条件：域名匹配（Host Header）、URL 路径前缀或精确匹配、HTTP 方法、请求头键值对
- 动作：转发到指定服务器组、重定向（如 HTTP 重定向到 HTTPS）、返回固定响应、重写 URL
一个典型的多服务路由配置：监听 443 端口，默认动作转发到主站服务器组；添加规则，当路径前缀为 /api/ 时转发到 API 服务器组；当路径为 /health 时直接返回 200 固定响应。这样整个应用只需要一个 ALB 实例和一个 IP 地址，不同服务共用同一入口，通过路由规则分流。
后端服务器组
服务器组（Server Group）是接收流量的后端实例集合，每个服务器组可以包含多台 ECS 实例。创建服务器组时指定协议和端口，添加成员时可以为每台 ECS 设置权重（0–100），权重越高接收的请求比例越大，权重为 0 时该实例暂停接收新请求（用于灰度发布或维护）。
后端 ECS 实例和 ALB 必须在同一地域，建议将后端 ECS 部署在不同可用区，与 ALB 的多可用区部署配合，实现全链路的跨可用区容灾。关于 ECS 实例的规格选型和跨可用区部署，可以参考 阿里云 ECS 完整教程。
健康检查配置
健康检查是负载均衡高可用能力的核心机制。ALB 和 NLB 都会定期向后端服务器发起检查请求，确认服务器是否正常响应。如果某台服务器连续多次检查失败，该服务器会被自动从流量分发列表中移除，直到恢复正常后重新加入。
ALB 的健康检查可以使用 HTTP 协议，指定检查路径（通常是 /health 或 /ping）和期望的响应状态码（通常是 200）。后端服务器应实现一个轻量级的健康检查接口，只返回状态码，不执行复杂业务逻辑，确保检查响应时间稳定在 100ms 以内。
一个容易被忽视的配置问题： 健康检查流量来自阿里云内部保留地址段 100.64.0.0/10，这个地址段不会出现在正常的业务流量中。如果后端 ECS 上配置了 iptables 或第三方安全软件，并且规则中拒绝了所有非白名单 IP 的访问，必须单独将 100.64.0.0/10 加入允许规则，否则健康检查会持续失败，服务器会被 ALB 误判为不可用，导致流量被完全摘除。
调度算法的选择
ALB 和 NLB 提供多种调度算法，决定了流量如何在后端服务器之间分配。
加权轮询（Weighted Round Robin）是最常见的选择，按照各服务器的权重比例依次分发请求。适合后端服务器规格相同、请求处理时间差异不大的场景，配置简单，行为可预期。
加权最小连接数（Weighted Least Connections）将新请求优先分发给当前连接数最少的服务器（按权重调整后）。适合请求处理时间差异较大的场景，例如部分请求涉及耗时的数据库查询，部分请求快速返回，最小连接数算法能更均匀地分散后端压力。
源 IP 哈希（Source IP Hash）将来自同一客户端 IP 的请求持续分发到同一台服务器，实现会话保持。适合无法使用 Cookie 做会话保持的场景，但当某台服务器故障或扩容缩容时，会话会被重新分配，可能导致部分用户登录态失效。
大多数 Web 业务选加权轮询即可，配合应用层的 Redis 集中存储 Session，不依赖负载均衡层实现会话保持，架构更健壮。结合阿里云 RDS 和 Redis 缓存处理会话和数据，是标准的三层业务架构，可以参考 阿里云 RDS 数据库教程中的连接配置说明。
计费方式
ALB 和 NLB 均只支持按量付费，按小时结算。CLB 的包年包月已于 2024 年 12 月停止新购，现有包年包月实例可以继续使用至到期。
ALB 的账单由三部分构成： 实例费（按小时固定费用）、LCU 费（性能容量单位，按实际消耗的新建连接数、并发连接数、处理数据量和规则评估数计算）和公网网络费（公网 ALB 通过 EIP 提供公网能力，EIP 单独计费）。私网 ALB 不产生公网网络费，只有实例费和 LCU 费。
NLB 的账单由两部分构成： LCU 费（针对 TCP/UDP 流量，涉及新建连接数、并发连接数和处理数据量）和公网网络费（公网 NLB 通过 EIP 计费）。NLB 的实例费当前限时免费，是成本上相对 ALB 的额外优势，但这个免费政策有变更可能，使用前应以控制台当期报价为准。
LCU 的计费方式对初次使用负载均衡的团队不够直观，实际账单会因业务流量的并发量和请求复杂度而波动。建议在业务正式上线前，用测试流量观察一周的 LCU 消耗量，以此估算月度费用，避免账单超预期。
常见配置问题排查
健康检查全部失败，所有后端服务器被摘除： 首先确认后端 ECS 上是否有防火墙规则拦截了来自 100.64.0.0/10 的流量，这是最常见的原因。其次确认健康检查的端口和路径是否与应用实际监听的端口和路由匹配。第三，确认 ECS 的安全组是否允许来自负载均衡的流量（安全组应允许 100.64.0.0/10 或负载均衡的 VPC 内网段访问对应端口）。
客户端看到的请求来源 IP 是负载均衡的 IP 而不是真实客户端 IP： ALB 会在 HTTP 请求头中添加 X-Forwarded-For 字段，值为真实客户端的 IP 地址。后端应用应从这个请求头中读取客户端 IP，而不是从 TCP 连接的来源地址读取。如果应用代码直接读取连接 IP，读到的会是 ALB 的内网 IP，导致访问日志中所有请求都来自同一个 IP。
HTTPS 配置后客户端仍然可以用 HTTP 访问： 需要在 ALB 的 HTTP 80 监听中配置一条重定向规则，将所有 HTTP 请求重定向到 HTTPS。ALB 支持直接在监听动作中选择”重定向”并指定协议 HTTPS、状态码 301，配置完成后 HTTP 请求会自动跳转到 HTTPS，不需要在应用代码层面单独处理。
账号开通与代理充值
使用阿里云 ALB 和 NLB 需要有效的阿里云国际版账号。负载均衡本身没有特殊的账号权重要求，创建实例不需要额外申请配额。对于没有海外信用卡、需要 USDT 或对公转账付款的用户，通过 阿里云代理 渠道开户更直接，免实名、免绑卡，充值享额度赠金（$100 到账 $110，$500 到账 $600，$1000 到账 $1250），账号权重更高，适合需要同时部署 ECS、RDS、VPC 和负载均衡的完整业务架构。
