负载均衡核心概念与分类归纳总结
聊负载均衡之前，我常问团队里刚入行的同学一个问题：
你有个电商网站，一台服务器扛不住高并发，你加了两台服务器。然后呢？流量怎么分？谁来决定用户请求该去服务器A还是服务器B？
答案就是负载均衡——说白了，它是一套流量分发的机制。在我的项目实战中，没有负载均衡的分布式架构几乎等于没做高可用。今天我把这块的核心概念和分类清一清。
负载均衡到底解决了什么？
核心就三件事：
- 横向扩展——加机器就能扛更多请求，业务量翻倍不需要重新架构
- 高可用——某台后端挂了，负载均衡自动把流量切到其他节点，用户几乎无感
- 资源合理利用——不让某台服务器闲死、另一台累死，让每台机器发挥价值
我做过一次压测对比：不加负载均衡，单节点每秒处理2000请求，CPU冲到95%。加了四节点+轮询策略，总吞吐量轻松破7000，各节点CPU稳定在60%左右。差距很明显。
负载均衡的分类——一张图看懂全局
先看这张结构图，后面逐条拆解。
一、按OSI层次分：四层 vs 七层
这是我做架构评审时一定会问的问题：你用四层还是七层？差别太大了。
| 对比维度 | 四层负载均衡（L4） | 七层负载均衡（L7） |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS/gRPC） |
| 转发依据 | IP + 端口 | URL、Header、Cookie、请求体 |
| 典型工具 | LVS、F5、AWS NLB | Nginx、HAProxy、Envoy |
| 性能 | 非常高（纯内核转发，毫秒级延迟） | 较高（需解析应用协议，有额外开销） |
| 灵活性 | 低（只能按IP和端口拆分） | 高（可按URL路径、域名、请求头做精细路由） |
| 适用场景 | TCP长连接、数据库、视频流 | Web应用、API网关、微服务 |
我个人习惯：后端服务是TCP私有协议或者对延迟极其敏感（如游戏服务器），用L4。如果是RESTful API、WebSocket、HTTPS终端，用L7准没错。曾经有个项目把L7硬怼在MySQL连接池前面，结果性能掉了30%，换成LVS DR模式后直接回血。
二、按部署形态分：硬件 vs 软件 vs DNS
硬件负载均衡
典型代表：F5 BIG-IP、A10 Networks。专有设备，自带专用芯片处理网络包。性能极高，单机能扛百万级并发。但贵——一台F5少说十几万起步，而且配置变更慢，运维人员需要懂专用命令行。
我在上一家金融公司见过F5集群，银行核心系统要求99.999%可用性，硬件方案确实稳。但问题是业务迭代快，每天接口版本变，每次都找网络组排期改VIP转发规则，苦不堪言。后来我们改造为Nginx+LVS混合方案，即满足合规又活了运维。
软件负载均衡
主流是Nginx、HAProxy、Envoy。跑在通用服务器上，成本低，配置灵活，社区生态丰富。
- Nginx：七层之王，反向代理、SSL卸载、Rewrite都强，也支持L4 stream模块
- HAProxy：四层七层都擅长，健康检查机制成熟，资源占用极其低
- Envoy：云原生新贵，gRPC、服务网格、可观测性原生支持，但学习曲线陡一些
注意：软件方案自带单点故障风险！我建议至少部署一对主备节点，使用Keepalived或K8s Service做高可用。不要单机裸奔——我见过生产环境因为Nginx进程挂掉导致全站502的惨案。
DNS负载均衡
最贴近用户的负载均衡。通过DNS解析返回不同IP，让用户直接访问离自己最近的机房。最简单的轮询DNS就能实现地域分流。缺点很明显：DNS缓存时效性差（TTL通常几分钟到几十分钟），节点故障后无法自动摘除。
我曾经用AWS Route 53 + 健康检查实现了智能DNS：当某个区域的服务器集体宕机，DNS自动把该区域的解析流量瞬移到其他区域。但要注意DNS变更生效时间，前端配短TTL（比如60秒）配合监控。
三、按调度策略分：静态 vs 动态
调度算法直接决定了后端“活匀不匀”。我遇到过一些团队随便选了个轮询，结果日志发现一台服务器CPU 90%另一台才10%。
| 策略 | 特点 | 适用场景 |
|---|---|---|
| 轮询（Round Robin） | 请求轮流发给每台后端，最简单 | 后端配置相同、请求处理时长接近 |
| 加权轮询（Weighted RR） | 按权重分配，权重高的多分 | 服务器性能不均（如4C8G vs 8C16G） |
| 最小连接数 | 动态选当前连接数最少的 | 长连接场景（如WebSocket、数据库中间件） |
| IP Hash | 对客户端IP取模，同一IP固定到同一后端 | 需要会话保持（Session Sticky） |
| URL Hash | 对请求路径取模，相同URL固定到同一后端 | 缓存命中率敏感（如图片、静态资源） |
| 最少响应时间 | 结合延迟和历史响应时间动态决策 | 延迟敏感、后端负载波动大 |
慎用IP Hash！我曾经有个项目，用户都从公司动态公网IP出口访问，结果几十个员工打进了同一台后端，而其他后端闲置——IP Hash在这种NAT环境下完全失效。后来换成Cookie-based Session Sticky才解决。
四、健康检查——负载均衡的生命线
负载均衡器必须能感知后端“活着没”。否则挂了你还往里发流量，用户全报错。健康检查分两种：
- 被动检查：统计连接失败次数，超过阈值自动摘除。Nginx的max_fails就属于这种。
- 主动检查：定时发心跳请求（TCP Ping / HTTP GET），返回异常就剔除。HAProxy的option httpchk就是。
我推荐主动+被动混合策略。主动检查间隔不能太短（建议3~5秒），否则成为另一种DDoS；被动检查作为兜底，防止主动检查漏网。再配合优雅下线机制：后端收到SIGTERM先停止接收新请求，等现有请求处理完再退出。
五、选型避坑总结
嗯，最后列几个我踩过的坑：
- 别迷信“硬件就是稳”：硬件有固件bug，升级周期慢，不适合快速迭代的业务。
- 四层负载均衡不要终止TLS：它不解密，没法做证书验证、重定向等七层操作。除非你只是做TCP透传。
- 注意后端连接超时配置：反向代理的keepalive_timeout和proxy_read_timeout必须匹配后端最大响应时间，否则无故断开影响业务。
- 加权轮询权重别乱设：我曾经为了方便给两台机器设了9:1，结果1的那台被淹没，加权的数字必须有实际资源依据。
负载均衡没有银弹，核心是对比业务场景选择合适的层、形态和算法。多画图，多压测，多观察真实流量分布——这才是硬道理。