负载均衡是分布式系统的流量调度基石，需统筹流量入口设计、节点调度逻辑、健康检查与可观测性；L4适用于高吞吐低延迟场景，L7适用于内容感知与精细路由场景，选择取决于业务特征而非功能堆砌。
负载均衡接入不是简单加一台代理或配几个IP，而是涉及流量入口设计、节点调度逻辑、健康保障机制和可观测性建设的系统工程。关键在于匹配业务特征选对层级、算法和部署形态，而不是堆功能。
按业务需求选对负载均衡层级
四层（L4）和七层（L7）不是“高低之分”，而是“适用之别”：
- 选L4（如LVS、HAProxy TCP模式、云厂商CLB）：当需要极致性能（10万+ QPS）、低延迟（
-
选L7（如Nginx、HAProxy HTTP模式、Envoy、AWS ALB）：当需基于URL路径、Header、Cookie、Host或JWT claims做路由时。例如：
/api/v1/users转给用户服务，/static/走CDN，或灰度流量打标后定向分发。 - 慎用DNS轮询：仅适合静态、低敏感场景（如内部管理后台）。因TTL缓存不可控、无健康检查、无法按地域/运营商调度，实际中已逐步被Anycast+HTTP健康探测替代。
算法选择要看连接模型和状态要求
算法不是越“智能”越好，而是越贴合请求生命周期越稳：
- 短连接API（如RESTful接口）：优先用加权轮询（Weighted RR）。它简单、无状态、易压测。权重可按CPU核数或历史TP99反推，比如8核机器设weight=8，4核设weight=4。
- 长连接服务（如WebSocket、SSE、IoT设备保活）：必须用最少连接（Least Connections）。否则轮询会把新连接持续打到已满载的节点，引发雪崩。HAProxy和Nginx都原生支持该模式。
-
需要会话保持（Session Stickiness）：用IP哈希（IP Hash）最轻量，但要注意NAT环境失效；更可靠的是Cookie插入（如Nginx的
sticky cookie），由LB写入session_id并绑定后端，故障时可自动漂移。 - 缓存/数据库读节点路由：推荐一致性哈希（Consistent Hashing），增减节点时仅影响邻近槽位，避免全量缓存失效。
高可用不能只靠主备，得有闭环机制
单点LB本身是风险源，必须构建“检测—决策—切换—验证”闭环：
-
主动健康检查要带业务语义：不只是ping通或TCP建连成功，应GET
/healthz?full=1，校验DB连接、下游依赖、磁盘水位等。Nginx Plus、HAProxy Enterprise支持脚本化探针。 - 被动健康检查要防误杀：配置合理的失败阈值（如连续3次5xx才摘除）和恢复窗口（如连续2次200再加回），避免瞬时抖动引发震荡。
- 多活LB部署建议双活（Active-Active）：用Keepalived+VRRP实现VIP漂移是过时方案；现代推荐用BGP Anycast（如MetalLB for K8s）或云上多可用区SLB，天然支持跨机房容灾。
-
备用节点别闲置：Nginx配置中的
backup参数只在全部主节点宕机时启用，利用率低；更优做法是设为低权重（如weight=1），平时分担部分流量，同时承担故障缓冲角色。
监控与调优要聚焦真实瓶颈
不要只看“请求成功率”，要盯住三类指标：
-
LB自身指标：连接数（
active conn）、新建连接速率（CPS）、吞吐（bps）、CPU/内存使用率。突增CPS但QPS不涨？可能是慢连接堆积或SYN Flood攻击。 - 后端节点指标：各节点的响应时间分布（TP50/TP90/TP99）、错误码比例（5xx/4xx）、连接队列长度。若某节点TP99陡升但连接数不高，大概率是应用层GC或锁竞争。
- 调度公平性指标：各节点请求占比标准差、权重偏差率。例如配置了3:2:1权重，但实测流量比为45%:35%:20%，说明存在未识别的长尾延迟干扰调度器判断。
调优常见动作：开启HTTP/2复用减少连接数、SSL卸载到LB节省后端CPU、启用gzip压缩降低带宽、限制单IP连接数防爬虫——这些都不是“高级功能”，而是上线前必做的基线配置。
