四层代理专注ip+端口转发，扛连接保性能；七层代理深度解析http内容，做语义路由与决策；二者解耦实现分工协作、独立升级与故障隔离，lvs+nginx组合在高并发https场景下显著降低cpu瓶颈。
应用层与传输层解耦不是为了“分层而分层”，而是让每层专注做自己最擅长的事：传输层扛连接、保性能，应用层管内容、做决策。这种分工能避免单点瓶颈，也便于独立升级和故障隔离。
四层负载均衡：只管“连不连得上”
这一层工作在TCP/UDP层面，不看HTTP头、不解析URL，只根据IP+端口做转发。典型实现是LVS（Linux Virtual Server），配合DR或FullNAT模式，吞吐能力可达百万级QPS。
- DR模式下，负载均衡器只改MAC地址，响应由后端服务器直发客户端，节省带宽；
- FullNAT适合跨VPC或云环境，通过两次地址转换解决网络隔离问题；
- 健康检查用轻量ICMP或TCP SYN探测，毫秒级发现节点异常，剔除延迟控制在1秒内。
七层负载均衡：专注“该发给谁”
它接在四层之后，拿到已建立的连接，再深度解析HTTP请求——比如读取Host头选租户集群、匹配/path/api/v2走灰度通道、提取Cookie识别用户会话。
- Nginx或HAProxy是主流选择，OpenResty支持Lua扩展，可嵌入业务逻辑；
- SSL/TLS卸载必须在此层完成，搭配Intel QAT卡，加解密耗时降低70%以上；
- 静态资源（/static、/img）直接回源CDN或对象存储，动态API才转发至应用集群。
解耦的关键支撑机制
光分两层还不够，中间需要稳定协同的“粘合剂”：
- 统一健康检查口径：四层用TCP探活，七层叠加HTTP /health接口验证业务就绪状态，双通道校验防误剔；
- 会话状态外置：购物车、登录态等不留在任一节点，统一存Redis集群，保证任意后端都能处理同一用户后续请求；
- 配置中心驱动：路由规则、权重、超时策略从配置中心（如Nacos、Consul）动态下发，无需重启服务即可生效。
为什么不能跳过四层直接上七层？
全量HTTPS流量+高并发场景下，七层代理CPU极易成为瓶颈。某政务系统实测：10万并发连接时，纯Nginx七层方案CPU打满95%，而LVS+NGINX组合下，四层承担连接建立与维持，七层仅处理已解密的HTTP请求，整体CPU占用压到40%以下，P99延迟稳定在80ms内。
