一、先搞懂：四层和七层，到底差在哪？
很多团队选负载均衡全凭感觉——"听说七层更智能，就用七层吧。"结果性能拉胯、配置复杂、故障排查头大。
四层和七层的本质区别，就一句话：看多深。
| 维度 | 四层负载均衡（L4） | 七层负载均衡（L7） |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS） |
| 看什么 | 源IP、目标IP、源端口、目标端口 | URL路径、Header、Cookie、请求体 |
| 比喻 | 高速公路收费站——看车牌号放行 | 智能交通指挥中心——看目的地、货物类型精准调度 |
| 处理方式 | NAT修改目标IP，直接转发，不碰数据内容 | 完整解析HTTP报文，代理模式重建连接，可修改请求/响应 |
| 典型场景 | 游戏联机、金融交易、Redis/MySQL代理 | Web应用、微服务API网关、多租户SaaS |
用一个最直观的例子：四层负载均衡看到10.0.0.1:8080就转发，它不知道你访问的是/api/users还是/static/logo.png；七层负载均衡能读懂URL，把图片请求甩给CDN节点，把API请求路由到用户服务集群——这就是"智能"的代价。
二、性能对比：四层是猛兽，七层是精密仪器
性能，是选型的第一道门槛。
2.1 四层：百万级QPS的"暴力美学"
四层负载均衡只做一件事：查表、改IP、转发。不解析内容，不建立应用层连接，延迟通常在微秒级。
天翼云四层负载均衡的性能指标：
| 指标 | 能力 |
|---|---|
| 最大连接数（TCP/UDP） | 单实例可承载百万级并发连接 |
| 每秒新建连接数CPS（TCP/UDP） | 十万级以上，远超七层 |
| 吞吐量 | 可达百万级数据包每秒 |
| 延迟 | 微秒级，几乎可以忽略 |
这意味着什么？意味着当你的游戏服务器需要处理200万+并发UDP连接，当你的金融撮合系统要求P99延迟<10ms——四层是唯一选择，没有之一。
2.2 七层：毫秒级延迟的"智力竞赛"
七层负载均衡要做的事情多得多：解析HTTP请求、建立后端连接、可能还要做SSL卸载、内容重写。这些操作让延迟飙升到毫秒级，通常比四层高20%~50%。
天翼云七层负载均衡的性能指标：
| 指标 | 能力 |
|---|---|
| 最大连接数（HTTP/HTTPS） | 单实例可承载数十万连接 |
| 每秒新建连接数CPS（HTTP） | 万级，低于四层一个数量级 |
| 每秒查询数QPS | 十万级HTTP请求每秒 |
| 延迟 | 毫秒级，但支持HTTP/2多路复用、QUIC协议优化 |
七层的性能瓶颈在哪？在SSL卸载。如果你的业务全是HTTPS，七层设备需要承担加解密运算，CPU负载可能高达80%。但天翼云七层负载均衡支持Session Ticket机制，通过TLS连接复用缩短握手时间，实测SSL握手性能提升3倍，广告商业务收入因此显著提升。
2.3 性能对比总结
| 维度 | 四层 | 七层 |
|---|---|---|
| QPS上限 | 10万+ | 1万~10万 |
| 延迟 | 微秒级 | 毫秒级 |
| 单连接开销 | 几十字节 | 数KB（需维护会话状态） |
| SSL卸载 | 不支持 | 支持，但消耗CPU |
| 适用QPS阈值 | >10万选四层 | <10万可选七层 |
我的建议：QPS超过10万、P99延迟要求<10ms的场景，闭眼选四层。其他场景，七层的智能值得那点性能牺牲。
三、功能对比：四层是"搬运工"，七层是"调度官"
性能决定了"能不能扛住"，功能决定了"能不能玩出花"。
3.1 四层能做什么？
| 功能 | 支持情况 |
|---|---|
| 轮询/加权轮询/最小连接/源IP Hash | ✅ 全部支持 |
| 健康检查（TCP端口连通性） | ✅ 支持 |
| 会话保持（基于源IP） | ✅ 支持 |
| 按URL路由 | ❌ 不支持 |
| SSL卸载 | ❌ 不支持 |
| 内容缓存/压缩 | ❌ 不支持 |
| 请求头重写 | ❌ 不支持 |
| WAF集成 | ❌ 不支持 |
四层的功能就像一把瑞士军刀——够用，但不花哨。它的核心价值就是：把流量快速、均匀地分发到后端，然后在某个后端挂了的时候自动踢掉。
3.2 七层能做什么？
| 功能 | 支持情况 |
|---|---|
| 轮询/加权轮询/最小连接/源IP Hash | ✅ 全部支持 |
| 健康检查（HTTP请求/自定义脚本） | ✅ 支持，更精细 |
| 会话保持（基于Cookie） | ✅ 支持 |
| 按URL/域名/Header路由 | ✅ 核心能力 |
| SSL/TLS卸载 | ✅ 核心能力 |
| 内容缓存/压缩/重写 | ✅ 支持 |
| 请求头重写/响应过滤 | ✅ 支持 |
| WAF集成（防SQL注入/XSS/CC攻击） | ✅ 支持 |
| 灰度发布（按Header切流） | ✅ 支持 |
| 转发策略（精确匹配/正则匹配/前缀匹配） | ✅ 支持 |
七层的功能是"调度官"级别的。举个实战案例：
某电商平台通过七层负载均衡实现了"新用户100%引导至新首页"——只需配置一条转发策略：当请求Header中
X-App-Version: beta时，路由到新首页服务集群。转化率因此提升15%。
这是四层永远做不到的事。
3.3 功能对比总结
| 维度 | 四层 | 七层 |
|---|---|---|
| 流量分发 | ✅ 基础 | ✅ 精细 |
| URL路由 | ❌ | ✅ |
| SSL卸载 | ❌ | ✅ |
| 安全防护 | 仅抗DDoS | WAF+防CC+防注入 |
| 灰度发布 | ❌ | ✅ |
| 灰度能力 | 无 | 按Header/Cookie/权重 |
| 配置复杂度 | 低 | 高 |
七层的功能不是"锦上添花"，而是微服务架构的刚需。 没有七层，你的API网关、灰度发布、多租户路由全都得自己在后端Nginx上实现——等于把负载均衡该干的活又搬回了应用层。
四、高可用对比：殊途同归，但七层更"聪明"
高可用是负载均衡的命脉。在这一点上，四层和七层都能做到99.99%的可用性，但路径不同。
4.1 四层的高可用：简单粗暴，但有效
四层的高可用靠三板斧：
| 机制 | 说明 |
|---|---|
| 健康检查 | TCP端口连通性检测，发现异常自动剔除 |
| 跨AZ部署 | 后端主机支持跨可用区，单AZ故障流量自动切走 |
| 集群模式 | 网元跨AZ多活，任意节点故障业务自动切换 |
天翼云性能增强型四层负载均衡采用集群模式部署，任意节点故障时业务流量自动切换到其他可用节点，实现无单点故障。
4.2 七层的高可用：更精细，但更复杂
七层在四层的基础上，多了一层应用层健康检查：
| 机制 | 说明 |
|---|---|
| HTTP健康检查 | 不只检查端口通不通，还检查/health接口返回200 |
| 自定义脚本检查 | 可执行Shell脚本，检测数据库连接、磁盘空间等 |
| 慢启动 | 新节点上线时逐步加权，避免冷启动被流量打死 |
| 动态权重调整 | 根据后端响应时间、错误率自动调权，高负载节点少分流量 |
| 会话保持 | 基于Cookie的会话保持，用户不会被"踢"到其他节点 |
某金融系统的实战数据：配置每10秒一次的七层健康检查，当节点连续3次响应超时时自动剔除，故障切换时间控制在30秒内。而四层的TCP健康检查通常需要30秒~1分钟才能判定节点异常——七层快了一个数量级。
4.3 高可用架构对比
| 维度 | 四层 | 七层 |
|---|---|---|
| 健康检查粒度 | 端口级 | URL/脚本级 |
| 故障发现速度 | 30秒~1分钟 | 10秒~30秒 |
| 跨AZ容灾 | ✅ 支持 | ✅ 支持 |
| 集群模式 | ✅ 支持 | ✅ 支持 |
| 会话保持 | 源IP Hash | Cookie Hash（更可靠） |
| 弹性伸缩联动 | ✅ 支持 | ✅ 支持 |
| 故障切换时间 | 秒级 | 亚秒级~秒级 |
七层的高可用不是"更强"，而是"更快发现、更精准切换"。 在金融、医疗等对RTO要求极高的场景，这几十秒的差距就是生死线。
五、天翼云的两种实例：经典型 vs 性能增强型
除了四层七层，天翼云还把负载均衡实例分成了两档：
| 维度 | 经典型 | 性能增强型 |
|---|---|---|
| 费用 | 免费 | 收费 |
| 部署模式 | 主备模式 | 集群模式 |
| 性能共享 | 同VPC内多实例共享 | 独享，性能更强 |
| 适用场景 | 访问量小、模型简单的Web业务 | 高并发、大流量、强性能要求 |
| 四层/七层 | 均支持 | 均支持 |
我的建议：日均QPS低于1万、业务模型简单的，经典型够用，还免费。日均QPS超过1万、或需要七层高级功能的，直接上性能增强型，别省这个钱。
某视频流媒体平台的数据：从经典型迁移到性能增强型七层负载均衡后，服务可用性从99.95%提升至99.99%，用户请求平均响应时间降低35%，高峰期卡顿率下降60%。
六、终极选型决策树：三步锁定最优方案
别再纠结了，按这个流程走：
| 步骤 | 问题 | 答案 | 选型 |
|---|---|---|---|
| 第一步 | 是否需要按URL/Header/Cookie路由？ | 是 | → 七层 |
| 否 | → 进入第二步 | ||
| 第二步 | QPS是否>10万？P99延迟是否要求<10ms？ | 是 | → 四层 |
| 否 | → 进入第三步 | ||
| 第三步 | 业务是否全HTTPS？是否需要WAF/灰度发布？ | 是 | → 七层（性能增强型） |
| 否 | → 四层（经典型即可） |
七、写在最后：没有"更好"，只有"更合适"
四层和七层不是替代关系，而是互补关系。
天翼云负载均衡的最佳实践是"四层入口+七层处理"的分层架构：四层在边缘扛住DDoS和海量连接，七层在核心做智能路由和安全防护。某头部直播平台就是这么干的——边缘节点部署四层负载均衡承接200万+并发UDP流，延迟稳定在3ms内；核心业务层接入七层网关实现按直播间地域动态调度，首屏加载速度提升40%。
作为开发工程师，你写的每一行代码最终都要经过负载均衡这道关。它的品质，就是你系统的天花板。
别等出了事故才来研究负载均衡——现在就打开控制台，对照你的业务场景，按决策树走一遍。选对了，你的系统扛得住百万并发；选错了，再好的代码也白搭。
四层是力量，七层是智慧。真正的高手，两个都要。
