四层负载均衡 vs 七层负载均衡

想象一个场景：双十一零点，你正等着付款，系统却提示「系统繁忙」。

这背后，很可能是你的请求在某个环节被卡住了——可能是 Nginx 的连接数爆了，可能是后端 Tomcat 的线程池耗尽了，也可能是数据库连接池满了。

问题来了：负载均衡器在这个链路中，到底扮演了什么角色？它是在第 4 层工作，还是在第 7 层工作？

这个选择，直接决定了你能处理什么样的流量，能做多精细的路由。

OSI 七层模型回顾

在说 L4 和 L7 之前，先快速过一下 OSI 七层：

层级	名称	典型协议	关键设备
7	应用层	HTTP、DNS、FTP	网关
6	表示层	TLS/SSL	-
5	会话层	NetBIOS	-
4	传输层	TCP、UDP	负载均衡器
3	网络层	IP、路由	路由器
2	数据链路层	MAC、VLAN	交换机
1	物理层	光纤、双绞线	-

负载均衡器主要工作在第 4 层和第 7 层，所以叫「四层负载均衡」和「七层负载均衡」。

四层负载均衡：只看得见「门牌号」

四层负载均衡基于 TCP/UDP 报文的头部信息做转发，不关心应用层协议内容。

工作原理

当你访问 123.125.115.110:80 时，四层负载均衡会：

1. 解析 TCP 头部的源 IP、目标 IP、源端口、目标端口
2. 根据调度算法选择一个后端服务器
3. 透明转发报文（可能修改 MAC 地址或 IP 地址）

典型代表

• LVS（Linux Virtual Server）
• F5 BIG IP 硬件负载均衡
• 云厂商的 CLB（四层模式）

Nginx 四层配置示例

stream {
    upstream backend {
        server 192.168.1.10:3306;
        server 192.168.1.11:3306;
    }

    server {
        listen 3306;
        proxy_pass backend;
    }
}

优缺点

优点：

• 性能极高，因为只是报文转发，几乎没有额外开销
• 支持所有 TCP/UDP 协议，不限于 HTTP
• 能承受海量并发连接

缺点：

• 无法基于 URL、Header、Cookie 等做精细路由
• 无法做应用层的健康检查（比如检测后端 HTTP 状态码）

七层负载均衡：看得见「内容」

七层负载均衡基于应用层协议（如 HTTP）做更精细的转发决策。

工作原理

当你访问 api.example.com/users/123 时，七层负载均衡会：

1. 解析 HTTP 请求行：GET /users/123 HTTP/1.1
2. 解析 Host、User-Agent、Cookie 等 Header
3. 根据 URL 路径、Header 内容等选择后端服务器
4. 重新构造 HTTP 请求并转发

典型代表

• Nginx（HTTP 模块）
• HAProxy（七层模式）
• Apache Traffic Server
• 云厂商的 ALB（七层模式）

Nginx 七层配置示例

http {
    upstream api_backend {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
    }

    upstream static_backend {
        server 192.168.1.20:80;
    }

    server {
        listen 80;

        # 静态资源走 CDN 回源
        location /static/ {
            proxy_pass http://static_backend;
        }

        # API 请求走应用集群
        location /api/ {
            proxy_pass http://api_backend;
        }

        # 根据 Header 路由
        location / {
            if ($http_x_tenant = "vip") {
                proxy_pass http://vip_backend;
            }
            proxy_pass http://api_backend;
        }
    }
}

优缺点

优点：

• 可以基于 URL、Header、Cookie、请求方法等做精细路由
• 支持 URL 重写、动静分离
• 能做应用层健康检查
• 支持会话保持（基于 Cookie）

缺点：

• 需要解析 HTTP 协议，性能开销比四层大
• 只能处理 HTTP/HTTPS 等特定协议

对比总结

维度	四层负载均衡	七层负载均衡
工作层级	传输层（TCP/UDP）	应用层（HTTP）
转发依据	IP + 端口	URL、Header、Cookie
性能	极高	较高（但足够用）
功能丰富度	基础	丰富
适用场景	数据库、Redis、游戏后端	Web 服务、API 网关
配置复杂度	简单	复杂
协议支持	所有 TCP/UDP	仅 HTTP 系列

实际选型建议

选四层：

• 后端是 MySQL、Redis、MongoDB 等非 HTTP 协议
• 需要处理海量短连接
• 对延迟极度敏感

选七层：

• 后端是微服务，需要金丝雀发布、灰度路由
• 需要基于 Header 做多租户隔离
• 需要 URL 重写、缓存控制等高级功能

最佳实践：四层 + 七层组合

用户请求 → 四层负载均衡（LVS/F5） → 七层负载均衡（Nginx） → 微服务集群

先用四层扛住流量洪峰，再用七层做精细路由。这种架构在大型互联网公司非常常见。

面试追问

1. 为什么 LVS 能比 Nginx 支持更高的并发？
2. 七层负载均衡怎么做会话保持？Cookie 方式有什么坑？
3. 如果四层负载均衡后面的某台机器挂了，七层能感知到吗？

---

思考题：

假设你正在设计一个支持多租户的 SaaS 平台，不同租户的数据需要隔离。你会用四层还是七层负载均衡来实现租户隔离？为什么？如果租户数量从 100 增长到 10000，你的方案还能 work 吗？