云上负载均衡选型与配置实战：从ALB到NLB，选对不选贵

去年双11，一个电商客户凌晨给我打电话，声音发颤：“我们扩容了，加了三十台机器，流量还是扛不住，用户疯狂重试，系统快崩了。”

我登录控制台一看，CPU、内存都还有余量，但负载均衡的健康检查把一半后端标记成了“不健康”，流量全怼到了剩下那十几台上。再一看，健康检查间隔设了5秒，超时2秒，阈值2次失败就摘掉。后端服务偶尔有300ms的抖动，刚好超过2秒，就被踢出去了。

一个健康检查参数，差点让大促翻车。

这是负载均衡最容易被忽视的地方：选对了类型只是第一步，配置错了照样出事。

今天聊聊云上负载均衡。不是那种“LB很重要”的废话，而是帮你理清楚：ALB、NLB、CLB到底怎么选？健康检查、会话保持、慢启动怎么配？哪些坑踩了会要命？

01 选型：七层还是四层？

云厂商通常提供三种负载均衡：七层（HTTP/HTTPS）、四层（TCP/UDP）、以及二者的混合体。选哪个，看你的协议和需求。

七层负载均衡（ALB/CLB七层）

能看懂HTTP协议，可以基于URL路径、请求头、Cookie做转发。支持SSL卸载、WebSocket、重定向、重写。

适合场景：Web应用、API网关、微服务入口。需要路径分发、域名分发的地方。

不适合场景：纯TCP流量（如数据库连接、游戏长连接）、极高性能要求（七层处理有额外开销）。

四层负载均衡（NLB/CLB四层）

工作在传输层，只看IP和端口，不关心应用协议。性能极高，延迟低，支持海量连接。

适合场景：TCP/UDP流量、数据库代理、游戏服务、IoT接入。

不适合场景：需要URL路由、Cookie粘性、SSL卸载的场景。

反常识观点：不是所有流量都适合七层。很多人一上来就选七层，觉得“功能多肯定好”。但七层的处理开销是四层的几倍，纯TCP流量用七层纯粹浪费性能。

一个真实对比：某游戏公司用七层LB扛TCP长连接，单实例只能支撑5万连接；换四层NLB后，单实例轻松到100万连接。

类型选对了，配置没跟上，一样翻车。

健康检查

这是最容易出问题的配置，也是最影响稳定性的。

关键原则：宁可多留一个可疑的，别急着踢出去。留一个可疑实例，最多慢一点；踢错了，流量全挤到其他实例上，可能雪崩。

会话保持

开启后，同一个客户端的请求会一直发到同一台后端。对需要保持登录状态的应用有用。

但代价很大：会话保持会让流量分配不均，某些热点用户会把一台机器打爆，其他机器闲着。能不用就不用。实在需要，用Redis存会话状态，让后端无状态，比会话保持靠谱得多。

慢启动

新加入的实例，一开始只给少量流量，逐步增加到正常水平。防止刚启动的实例被瞬间流量冲垮。

这是大促必备配置。不加慢启动，扩容的机器一上来就接全量流量，JVM还没预热、缓存还没命中，直接超时。

坑一：跨可用区开启后，跨区流量收费

很多人不知道，LB跨可用区转发是要收流量费的。如果后端实例分布不均，大量请求从A区的LB转到B区的后端，账单上会多一笔不小的跨区流量费。解决方案：每个可用区至少放一台后端，让LB尽量在本区内转发。

坑二：连接超时设置不当

LB和后端之间的连接超时设太短，业务还没处理完就被LB断开了，客户端收到504。设太长，LB可能积累大量僵死连接。一般Web应用60-120秒，长连接场景（如文件上传）要调大。

坑三：后端长连接配置不一致

LB默认会复用和后端的连接。如果后端的连接超时时间比LB短，后端主动断开了，LB还在用那条连接，就会报错。两边的超时配置要一致。

回到开头那个电商客户。我们连夜排查，发现问题出在健康检查配置上：超时2秒，间隔5秒，阈值2次。后端服务大促期间响应偶尔超过2秒，就被判定不健康。十几个实例被反复踢出又加回，流量震荡，雪上加霜。

修复方案：超时改到5秒，间隔保持5秒，不健康阈值从2次改到3次。改完后，健康检查稳定了，流量恢复均衡。

第二天大促，峰值流量比前一天还高，但系统稳稳扛住。

运维负责人后来说：“以前觉得健康检查就是个开关，现在才知道，参数调不对，等于没开。”

负载均衡这东西，看起来就是“流量分发”，用起来才发现细节无数。选型错了，性能上不去；配置错了，稳定性一塌糊涂。

但也不用怕。记住几个原则：能用四层就别用七层；健康检查宁可宽松别严格；会话保持能不用就不用；大促前把慢启动和连接超时调好。

那位运维负责人后来又补了一句：“负载均衡就像大楼的入口，门不够宽，里面再大也没用。”