slb负载均衡配置

SLB（Server Load Balancer）不是载均置配完就完事的东西。我见过太多人把监听端口一填、衡配后端服务器一挂，载均置就以为高可用稳了，衡配结果一次机房割接直接打回原形。载均置负载均衡的衡配核心不在“均衡”，在于故障隔离和流量调度策略能不能扛住真实压力。载均置

先说最基础的衡配监听配置。四层（TCP/UDP）和七层（HTTP/HTTPS）的载均置差别不只是协议号。四层转发靠的衡配是LVS内核模块，性能极高，载均置一台8核机器扛几十万并发连接不算难事。衡配但它看不到HTTP头，载均置没法做基于URL或Cookie的衡配会话保持。七层走Tengine/Nginx，载均置能解析应用层内容，代价是CPU消耗明显上升。我实测过，同样8核32G的SLB实例，七层HTTPS卸载场景下，QPS到8万左右CPU就接近瓶颈，而四层同配置轻松过30万。

健康检查是SLB的命门。默认的TCP端口探测太粗糙，后端进程假死但端口还听着的情况它根本发现不了。必须换成HTTP探测，指定一个能反映真实业务状态的URI。比如 /api/health 返回200且body里带 status:ok，这才算数。探测间隔别设太短，2秒一次足够，连续失败3次摘除节点。超时时间要小于间隔，否则探测任务会堆积。有个坑：如果后端是Java应用，Full GC时健康检查可能超时，节点被误摘，GC结束后流量已经切走，节点又空转。解决办法是把超时放宽到5秒，或者用JVM内部指标做健康判断。

会话保持分两种。四层用源IP哈希，简单但NAT环境下大量用户会落到同一台后端。七层用Cookie插入，SLB在响应里写一个 SERVERID，后续请求带着它走。缺点是首次请求仍可能被调度到任意节点，如果应用没做session共享，用户会看到登录态丢失。我的建议：能改应用就上Redis集中存session，别依赖SLB的会话保持。实在改不动，用七层Cookie保持加后端同步方案兜底。

权重配置不是拍脑袋定的。新上线一台配置相同的机器，权重先给10，观察5分钟CPU和RT，再逐步加到100。直接给满权重，瞬时流量打进来，JIT还没预热，请求全堵在队列里。下线节点更讲究：先把权重降到1，等连接数自然回落到个位数，再从后端池摘除。直接摘除会导致长连接被RST，用户端报502。

证书管理容易被忽略。七层HTTPS监听要上传证书链，不是只传域名证书。中间证书缺失，安卓部分机型直接握手失败。证书到期前30天就要准备替换，SLB支持多证书绑定，但同一端口只能生效一个。替换时新建监听端口，切DNS权重，旧端口保留24小时再删。

最后说个真实案例。某电商大促前压测，SLB后端20台机器，权重均等。压测到70%流量时，监控显示后端CPU只有40%，但SLB自身新建连接数飙升到上限。查下来是短连接太多，SLB的conntrack表被打满。后来开启连接复用，后端加 keepalive_timeout 75s，问题消失。负载均衡的瓶颈往往不在后端，而在SLB自己的连接跟踪表。

配置完记得做一次故障演练：手动摘掉一台后端，看流量是否在3秒内切走；再模拟健康检查失败，确认节点被正确隔离。别等真出故障才验证。