📚 课程目录第3章负载均衡核心原理

3. 负载均衡核心原理：分类、四层与七层、常见瓶颈

说实话，负载均衡这东西，我刚开始接触的时候也觉得挺玄乎的。不就是把流量分到多台机器上吗？后来在实际项目里摔过几次跟头，才发现里面的门道比想象中多得多。今天咱们就聊聊负载均衡的分类、四层和七层的区别，以及那些容易踩的坑。

3.1 负载均衡的分类：软件 vs 硬件

先问个问题：你选负载均衡方案时，第一反应是买设备还是装软件？其实这两种思路各有各的适用场景。我个人的习惯是：先看流量规模和预算，再看运维团队的能力。

一、硬件负载均衡

典型代表：F5 BIG-IP、Citrix ADC、A10 Networks。

优点：性能极高，专用芯片处理流量；自带SSL卸载、DDoS防护；稳定可靠，少维护。
缺点：贵，一台几十万起；升级换代成本高；配置复杂，依赖厂商支持。

二、软件负载均衡

典型代表：Nginx、HAProxy、LVS、Envoy、Traefik。

优点：成本低，开源免费；灵活，可定制；社区活跃，文档丰富。
缺点：性能受限于服务器CPU和网卡；需要自己处理高可用和监控。

我在一个金融客户的项目里遇到过这样一个场景：他们的核心交易系统要求99.999%的可用性，流量峰值每秒10万连接。当时选了F5硬件方案，确实稳如老狗，但运维团队每次调整策略都要提单等厂商。后来他们内部的一个监控服务改用了Nginx + Keepalived，开发和运维自己就能搞定。你看，这不是非此即彼的问题，而是分场景选择。

我的建议：如果业务对延迟极其敏感（比如高频交易）、或者需要内置SSL硬件加速，硬件方案依然有优势。但90%的互联网场景下，软件方案完全够用，而且运维更可控。我自己更倾向软件方案，因为出问题能自己翻代码定位。

3.2 四层与七层负载均衡的区别

这个区别是面试必考题，也是实际部署时最容易搞混的地方。说白了，四层和七层的核心差异在于它们工作在OSI模型的哪一层，以及能看懂什么协议。

维度	四层（L4）负载均衡	七层（L7）负载均衡
OSI层	传输层（TCP/UDP）	应用层（HTTP/HTTPS/gRPC等）
处理依据	源IP、目标IP、端口、协议	URL、Header、Cookie、请求体内容
性能	高，纯内核态转发，毫秒级	相对低，需要解析应用协议，存在代理开销
功能	简单转发，不支持会话保持、重写等	支持路由、重写、限流、WAF、SSL卸载等
典型场景	数据库读写分离、DNS、游戏UDP	Web应用、API网关、微服务架构
典型工具	LVS、IPVS、F5 LTM L4 profile	Nginx、HAProxy、Envoy、Traefik

举个具体的例子你就明白了。四层负载均衡就像快递分拣中心，只看包裹上的城市标签就往对应卡车扔，不管里面装的是衣服还是书。而七层负载均衡就像仓库管理员，不但要看包裹，还要打开检查里面东西的种类，然后决定送到哪个货架。

我记得有一次线上事故，运营同事反馈某个活动页面总是报错，但其他页面正常。我们的入口是Nginx七层负载均衡，排查后发现是某个URL路径规则写错了，导致所有包含“/activity/”的请求都被转发到了一个已下线的Web服务器。如果是四层负载均衡，它根本不会看URL，只会把流量平均分发，反而不会出这种问题。所以你看，七层灵活，但配置门槛更高。

我曾经踩过的坑：在一个TLS卸载架构里，我一开始用了四层负载均衡直接透传TCP流量到后端，然后后端自己做SSL卸载。结果发现后端服务器的CPU全部飙升到90%，因为每个请求都要做一次非对称解密。后来我把SSL卸载挪到了七层负载均衡器上（Nginx），CPU一下就降到20%。这个教训告诉我：TLS卸载一定要在负载均衡的早期阶段完成，别甩给后端。

3.3 常见瓶颈与避坑指南

你想想看，负载均衡器本身也是台机器（或者虚拟机），它也会有瓶颈。我总结了三个最常见的坎：

连接数上限 —— 操作系统默认的文件描述符限制（默认1024）很快就会耗尽。尤其在高并发长连接场景下，每个连接占一个fd，很容易触发这个瓶颈。解决方法：调大系统参数 ulimit -n 100000，并确认负载均衡软件自己的连接池设置。
CPU瓶颈（尤其是七层场景） —— 解析HTTP协议、正则匹配URL、SSL加解密都是CPU密集型操作。我曾经在Nginx里配置了20条rewrite规则，压测时CPU直接打满。后来把规则拆到Lua脚本里异步处理，才压住。
内存占用 —— 连接跟踪表、Session表、缓冲区都会消耗内存。硬件设备内存固定，软件方案可以调整，但要防止OOM。HAProxy的 nbthread 和 maxconn 参数需要踩点测试。
网络带宽/网卡软中断 —— 软件负载均衡依赖网卡IRQ亲和性，如果不绑定CPU核，单个网卡中断会被分配到不同CPU，导致cache颠簸。我习惯用 irqbalance 或手动绑定中断到特定CPU。

一个小技巧：部署前先用 sysbench 或 wrk 压测一下你选的软件负载均衡器的极限并发数和吞吐量，记录下来作为容量基线。这样后期扩缩容时心里有底。

最后附上一张我整理的负载均衡分类与分层对比图，帮你把思路理清楚：

图中你可以看到，软件/硬件只是载体，真正决定行为方式是四层还是七层。在实际架构中，我经常把四层和七层组合使用：入口用LVS做四层分发，后面接Nginx做七层路由。这样既能扛高并发，又能享受七层的灵活性。记住一点：没有银弹，只有最适合你场景的方案。

3.4 一个小实验：用Nginx体会四层 vs 七层

光说不练假把式。我下面贴两段配置，你可以在本地试试差别：

四层（TCP代理）

# nginx.conf - L4 stream模块
stream {
    upstream backend {
        server 192.168.1.10:3306;
        server 192.168.1.11:3306;
    }
    server {
        listen 3306;
        proxy_pass backend;
    }
}

七层（HTTP反向代理）

# nginx.conf - L7 http模块
http {
    upstream backend {
        server 192.168.1.10:80 weight=3;
        server 192.168.1.11:80 weight=1;
    }
    server {
        listen 80;
        location /api/ {
            proxy_pass http://backend;
        }
        location /static/ {
            proxy_pass http://static_servers;
        }
    }
}

看到了吧？四层配置简单粗暴，不关心内容；七层配置可以按路径分流。你在压测时可以用 wrk -c 1000 -t 4 http://your-lb/ 和 wrk -c 1000 -t 4 tcp://your-lb:3306 对比吞吐量，感受下差距。