四层还是七层？聊聊负载均衡那些事儿

上周帮客户排查一个诡异的性能问题时，发现他们把所有流量都怼在四层负载均衡上，结果七层应用的各种优化策略完全没生效。今天就想和大家聊聊这两种负载均衡的区别，以及我在实际项目中总结的选型经验。

OSI模型中的四层与七层

先来个快速复习（敲黑板）：四层对应传输层（TCP/UDP），七层对应应用层（HTTP/HTTPS等）。就像快递运输，四层只管把包裹送到小区门口，七层则会精确投递到具体门牌号。

# 四层负载均衡典型配置（Nginx示例）
stream {
    upstream backend {
        server 192.168.1.1:3306;
        server 192.168.1.2:3306;
    }
    server {
        listen 3306;
        proxy_pass backend;
    }
}

四层负载均衡：简单粗暴的”快递小哥”

记得第一次用LVS做MySQL读写分离时，被它的性能震撼到了——单机轻松扛住10万+连接。四层负载的特点很鲜明：

• ⚡️ 性能怪兽：基本不解析数据包，转发延迟极低
• 🔌 协议无关：TCP/UDP通吃，数据库、游戏服务最爱
• 🤷 无状态：不会关心HTTP头、Cookie这些”细节”

但去年有个坑让我记忆犹新：某次Redis集群扩容后，四层负载导致部分客户端长连接始终粘滞在老节点上…

七层负载均衡：懂业务的”智能管家”

现在我的Go项目标配七层负载，特别是需要做这些骚操作时：

# 根据URL路径路由到不同服务
location /api/v1 {
    proxy_pass http://backend_v1;
}
location /api/v2 {
    proxy_pass http://backend_v2;
}

七层负载的三大绝活：

1. 🕵️ 能看懂HTTP协议，实现基于URL/Cookie的路由
2. 🛡️ 可集成WAF，防SQL注入等攻击
3. 📊 能收集详细监控指标（QPS、延迟分布等）

实战选型指南

根据我踩过的坑，总结出这个决策树：

• 需要处理非HTTP协议？ → 四层
• 追求极致性能？ → 四层
• 要灰度发布或AB测试？ → 七层
• 涉及SSL终端卸载？ → 七层

最近一个电商项目里，我们甚至玩出了骚操作：四层LVS做第一层流量分发，七层Nginx在后面做精细路由，既保性能又保灵活性。

性能对比实测数据

用wrk压测同一批ECS（配置：4C8G），结果很有意思：

所以千万别学我当初那个客户，用四层负载扛HTTP流量还抱怨rewrite规则不生效😂

写在最后

最近发现云厂商的LB服务越来越智能（比如阿里云的CLB支持四七层自动转换），但理解底层原理依然很重要。下次可以聊聊我在K8s Ingress上栽的跟头——那时候才真正明白什么叫”七层负载的优雅停机”。