阿里云负载均衡怎么选？实例规格和监听配置有哪些坑

业务从单台服务器扩到多节点后，最先碰到的往往是流量怎么分。某个节点被打满，或者一台机器宕机，用户那边就开始报错，这时通常需要在客户端和后端之间加一层负载均衡。阿里云负载均衡是托管产品，下面从产品选型、调度与健康检查，到一个电商大促的改造例子，把配置时要留意的地方讲清楚。

负载均衡在架构里处在哪一层

它站在客户端和后端服务器之间，把请求分发到多台实例上。实际用下来，有三个好处比较直接：加实例就能接更多流量；某台实例出问题，流量会切到健康节点；证书、访问控制和日志可以在入口统一处理，不用每台机器各配一遍。

在阿里云上，一套配置一般由三部分组成：监听（Listener）定义协议和端口，后端服务器组决定流量去哪里，健康检查持续判断每台实例能不能接流量。三者里有一个没配对，就可能出现“负载均衡已经创建，但访问不通”的情况。

三类产品怎么选

阿里云负载均衡目前有三类产品，选型时先看业务要在哪一层做转发。

应用型负载均衡（ALB）：工作在七层，可以按域名、路径、请求头写转发规则。Web 站点、微服务网关、需要灰度发布的服务，一般选它。
网络型负载均衡（NLB）：工作在四层，处理 TCP、UDP。连接数多、对延迟敏感的场景，比如游戏、音视频推流，适合放在这里。
传统型负载均衡（CLB，原 SLB）：兼容老系统，四层和七层的基础转发都能做。存量系统迁移时可以先保留，新项目建议优先看前两者。

判断方法不复杂。先画一张简单的流量图，标出请求会经过几层、有没有会话保持的需求，再对照产品。很多人跳过这一步，直接按价格或名字选，后面要么规则写不下去，要么得返工迁移。

调度算法和健康检查

调度算法决定请求落到哪台机器。常见的有加权轮询、加权最少连接和源地址哈希。后端机器配置接近、请求耗时也差不多时，加权轮询够用。请求耗时差异大时，加权最少连接更均匀，因为它会优先分给当前连接数少的机器。源地址哈希能让同一客户端尽量落到同一节点，适合依赖本地缓存或会话状态的服务，但节点增减时，一部分客户端会被重新分配，这一点要提前考虑。

健康检查比算法更容易出事故。有四个参数要逐个确认：检查协议和路径，比如 HTTP 检查 /health；检查间隔和超时时间；连续成功、连续失败各要几次才判定状态变化；返回码的匹配规则。健康检查接口建议单独写，只返回进程存活还不够，最好顺带验证数据库这类关键依赖。否则数据库连接断了，检查接口照常返回 200，故障节点还会一直收到请求。

一个大促前的改造例子

某中型电商的商品详情服务平时跑在四台 ECS 上，大促时流量峰值约为日常的十倍。原来的入口是一台老式网关，它自己先成了瓶颈，而且没有健康检查，故障节点仍会持续收到请求。

改造分三步走。第一步，入口换成应用型负载均衡，按域名和路径拆分：商品详情一组后端，搜索接口另一组，两边可以各自扩容。第二步，每个后端组配置 HTTP 健康检查，间隔不要太长，连续三次失败才摘除节点，避免网络抖动被误判成故障。第三步，HTTPS 证书托管在负载均衡侧，后端只走内网 HTTP，实例少做一部分加解密工作。

大促前的压测里，单节点故障时流量在数十秒内切走，用户侧基本没有明显感知。之后团队扩容新机器时，先给较低权重，观察一段时间没问题再逐步加权，新节点冷启动时的压力因此小了很多。