一、背景：为什么我们需要一套新的七层负载均衡能力
随着公司业务形态的持续演进，越来越多的服务开始从传统 IDC / 经典网络，逐步迁移到 VPC 与容器化环境。
在这一过程中，原有七层负载均衡能力逐渐暴露出一些共性问题：
七层能力主要面向经典网络，对 VPC 场景支持不足
后端实例类型差异较大（虚机 / 裸金属 / Pod），接入方式不统一
四层与七层能力割裂，业务在扩展时需要维护多套流量入口
配置变更、规则调整需要频繁reload生效，变更效率和稳定性受限
这些问题在单一业务阶段并不明显，但在 多业务并行、网络形态混合、云原生逐步推进 的背景下，已经开始对业务迭代和运维效率形成约束。
基于此，智汇云-平台侧推进了 统一七层负载均衡服务 的建设，希望通过一套公共能力，支撑多种网络形态下的七层流量接入需求。
二、如果你还在使用旧方案，可能正在经历这些问题
从业务线视角看，以下场景并不陌生：
同一业务同时存在 经典网络流量 + VPC 流量
后端既有 虚拟机服务，也有 容器化服务
需要基于 域名 / URL / Header 做精细化转发或灰度
在这些情况下，常见的处理方式往往是：
多套七层负载均衡并行使用
不同环境使用不同接入方式
配置分散、维护成本高
流量切换和策略调整风险较高
这些复杂度并不直接创造业务价值，但会持续消耗业务和运维团队的精力。
三、统一七层负载均衡做了哪些关键改进
本次统一七层负载均衡在设计上，重点解决的是“能力统一”和“复杂度下沉”的问题，核心改进点包括：
1. 统一的七层控制面
七层相关资源（Service / Router / Upstream）统一由平台 API 管理
七层规则集中存储与分发，避免多系统配置
2. 配置实时生效，降低变更风险
七层规则变更通过配置中心实时下发
无需重启转发组件即可生效，减少变更窗口依赖
3. 统一支持经典网络与 VPC 场景
对业务侧屏蔽网络差异
业务只需关注服务与规则本身，无需关心后端实际网络形态
4. 四层与七层能力协同复用
在现有四层能力基础上扩展七层能力
降低额外接入与学习成本
这些设计并不是为了“做一个更复杂的负载均衡”，而是希望 把复杂度留在平台侧，把稳定和简单交给业务侧。
四、这些变化对业务线意味着什么
从业务使用角度看，统一七层负载均衡带来的直接收益主要体现在：
接入方式稳定
无论后端服务形态如何变化，流量入口方式保持一致策略调整更安全
七层规则支持在线调整，减少人工操作风险更适合业务演进
支持灰度、路径路由、多版本并存等常见业务场景降低长期维护成本
避免因架构调整频繁更换负载均衡方案
可以理解为：
七层负载均衡从“每个业务各自维护的能力”，变成了一项 可被业务稳定复用的公共基础能力。
五、哪些业务场景适合优先接入
结合当前能力与稳定性，推荐以下场景优先接入统一七层负载均衡：
新上线的 Web / API 服务
正在进行 VPC 化或容器化迁移的业务
有以下需求的服务：
基于域名 / URL 的路由
会话保持（登录态、状态服务）
健康检查与自动摘除
HTTPS 证书统一管理与卸载
暂不建议直接接入的场景：
对链路时延极度敏感的强状态核心系统
使用非常规协议、依赖复杂定制转发逻辑的服务
上述场景建议先与智汇云平台团队进行评估沟通。
六、统一七层负载均衡流量路径
流量分为云上云下两种场景：
经典网络七层流量：公网EIP -> 四层负载均衡集群(idc vip) -> 七层负载均衡网关 -> IDC可达IP(包括虚机/POD等)
VPC云上七层流量：公网EIP -> 四层负载均衡集群(vpc vip) -> 七层负载均衡网关(vxlan封装) -> VPC内IP(包括虚机/POD等)
七、接入成本与当前能力边界说明
在当前版本中：
业务代码通常无需改动
支持通过域名切换方式进行平滑接入
七层规则可通过控制台或 API 进行统一管理
需要说明的是：
当前功能已覆盖常见七层使用场景
更复杂的转发能力（如更丰富的协议支持）仍在持续演进中
平台侧建议：
核心业务在正式切量前，提前与智汇云平台团队进行一次接入评估。
八、如何开始使用 & 支持方式
七层负载均衡资源可通过平台 hulk.qihoo.net 统一入口进行创建与管理
使用前可参考产品帮助手册了解资源模型与配置方式
接入或评估过程中如有问题，可联系智汇云平台团队进行支持
九、常见问题（FAQ）
1. 接入统一七层负载均衡，需要改业务代码吗？
一般不需要。
统一七层负载均衡主要工作在流量入口层，通过域名、路由规则和转发策略完成流量调度。
在大多数 Web / API 场景下，业务代码无需感知七层负载均衡的存在。
如果业务当前存在强绑定 IP、端口或特殊 Header 逻辑，建议在接入前与平台团队确认。
2. 现有服务可以平滑切换吗？会不会影响线上流量？
支持平滑接入与逐步切换。
常见做法是：
先创建七层规则并完成联调
通过域名解析或权重方式逐步引流
观察稳定性后再完成切换
在接入过程中，无需一次性切全量流量，可以按业务节奏逐步推进。
3. 现在支持哪些后端类型？虚机和容器可以混用吗？
支持混用。
当前统一七层负载均衡支持的后端实例类型包括：
虚拟机
裸金属
容器 / Pod
业务可以在同一个七层服务中，同时配置不同类型的后端实例，
无需因为部署形态变化而调整流量入口。
4. 和原有四层负载均衡是什么关系？需要替换吗？
不是强制替换关系，而是能力协同。
统一七层负载均衡在现有四层能力基础上扩展：
四层仍负责基础转发与高可用
七层负责协议解析、路由和策略控制
业务可以根据需求：
仅使用四层
四层 + 七层组合使用
无需一次性重构原有架构。
5. 配置改错了怎么办？会不会影响正在跑的流量？
七层配置支持在线变更与实时生效，但也建议遵循以下原则：
重要规则变更前先在测试或低风险业务验证
使用最小变更原则，避免一次性修改过多规则
核心业务变更建议提前与平台团队沟通评估
平台侧提供健康检查与异常摘除机制，用于降低错误配置带来的影响范围。
6. 如果我现在不确定适不适合接入，应该怎么做？
建议先评估，再决策。
可以从以下方式入手：
选择一个新服务或非核心服务作为试点
与平台团队沟通当前业务架构与流量模型
对照七层能力确认是否能覆盖现有需求
统一七层负载均衡的目标不是“替代一切方案”，而是为合适的业务提供一个长期稳定的七层流量入口选择。
