七层全代理正让位于四七层混合架构，核心是性能、语义与运维成本再平衡：DNS调度、四层入口分发、七层语义路由分层解耦，按协议切分流量，连接模型决定部署粒度，运维需分层可观测。
七层全代理架构正逐步让位于四七层混合架构，核心动因是性能、语义与运维成本的再平衡。纯七层虽灵活，但连接开销大、协议绑定深、延迟高；纯四层虽快，却无法支撑精细化业务路由。混合不是简单叠加，而是按需分层、各司其职。
分层解耦：明确每层的核心职责
混合架构的关键在于厘清边界：
- DNS层负责地理级调度，把用户导向最近的数据中心（如用Cloudflare或DNSPod做智能解析）
- 四层层承接所有入向连接，基于IP+端口做快速分发，不解析内容——LVS或Nginx stream模块在此承担“流量入口网关”角色
- 七层层只处理真正需要语义判断的子路径，比如/api/、/admin/、带特定Header的请求，由Nginx http模块或Envoy按规则精细分流
流量分段：哪些走四层，哪些必须上七层
不是所有流量都值得进七层。实践中可按协议和用途切分：
- 四层承载：MySQL主从流量、Redis集群访问、gRPC长连接、WebSocket握手后通信、静态资源CDN回源
- 七层介入：HTTP(S)动态接口路由（如/api/v2→新版本服务）、设备类型识别（User-Agent跳转移动端后端）、Cookie会话保持、WAF防护、AB测试流量打标
连接模型差异决定部署粒度
四层是透传模式，客户端与后端直接建连；七层是代理模式，LB与前后端各建一次TCP连接。这意味着：
- 四层节点可部署在更靠近网络边界的物理位置（如IDC出口），吞吐达百万QPS，延迟压到微秒级
- 七层节点应贴近应用集群部署，避免跨机房长链路，且需预留足够CPU处理SSL卸载、Header解析等计算任务
- 混合架构中，四层常作为前置LB，七层作为内网Service Mesh入口或Ingress Controller，形成两级转发链路
运维与可观测性需同步升级
混合后监控不能只看“整体成功率”，要分层归因：
- 四层层关注连接建立耗时、SYN重传率、五元组分布均衡度
- 七层层关注HTTP状态码分布、上游响应时间P95、URI路径级错误率、Cookie哈希漂移情况
- 建议用OpenTelemetry统一打点，在Span中注入layer=4或layer=7标签，便于故障快速定界
这种转型不是推倒重来，而是将七层能力下沉为可插拔策略，在四层底座上按需启用。架构越往后演进，越不是追求“全能”，而是追求“够用且可控”。
