在云负载均衡（Cloud Load Balancer）场景中，Web 界面上显示的配置信息，绝大多数情况下是从控制面（Control Plane）获取的，而不是直接从数据面（Data Plane）获取。
下面我们详细分析原因、架构逻辑以及例外情况。
✅ 一、核心结论
| 信息类型 | 来源 | 原因 |
|---|---|---|
| 用户配置信息 （如 VIP、端口、后端服务器、健康检查、SSL 证书等） | ✅ 控制面 | 控制面是配置的“权威源”（Source of Truth） |
| 运行时状态信息 （如连接数、QPS、延迟、后端健康状态） | ⚠️ 部分来自数据面 | 数据面采集性能指标，通过监控系统上报 |
| 规则生效状态 （如 ACL 是否已加载） | ✅ 控制面 + 数据面状态汇总 | 控制面下发，数据面反馈确认 |
📌 总结：Web 界面 = 控制面提供“配置” + 监控系统提供“状态”
✅ 二、典型云负载均衡架构
text
深色版本
+---------------------+
| Web Console |
| (展示配置与状态) |
+----------+----------+
| HTTPS / API
v
+---------------------+
| API Server | ← 控制面入口
| - 接收用户配置 |
| - 验证 & 持久化 |
+----------+----------+
|
v
+---------------------+
| Control Plane | ← 配置的“大脑”
| - 配置管理 |
| - 健康检查 |
| - 策略编译（如 ACL） |
| - 下发到数据面 |
+----------+----------+
| IPC / RPC / 消息总线
v
+---------------------+
| Data Plane (多个实例) |
| - 高性能报文处理 |
| - 连接跟踪、NAT、调度 |
| - 上报统计与状态 |
+----------+----------+
|
v
+---------------------+
| Monitoring System | ← 采集数据面指标
| (Prometheus, Telegraf)|
| - QPS, 连接数, 延迟 |
| - 后端响应时间 |
+---------------------+
✅ 三、Web 界面数据来源详解
1. 配置信息 → 来自控制面
Web 界面显示的以下内容，均从控制面数据库或配置中心读取：
| 配置项 | 来源说明 |
|---|---|
| 负载均衡实例 IP（VIP） | 控制面分配并持久化 |
| 监听器（Listener）配置 | 控制面存储：协议、端口、调度算法 |
| 后端服务器组（Server Pool） | 控制面维护服务器列表 |
| 健康检查配置 | 控制面配置探测频率、超时、阈值 |
| SSL 证书绑定 | 控制面管理证书生命周期 |
| ACL / WAF 规则 | 控制面存储规则集 |
✅ 为什么是控制面？
- 控制面是唯一能修改配置的入口；
- 配置需要持久化、审计、版本管理；
- 数据面是“无状态”的，重启后从控制面重新加载。
2. 运行时状态 → 来自数据面 + 监控系统
虽然配置来自控制面，但实时性能指标来自数据面：
| 状态信息 | 获取方式 |
|---|---|
| 当前连接数（Connections） | 数据面每秒上报，监控系统聚合 |
| 每秒请求数（QPS/RPS） | 数据面统计，通过 StatsD/Prometheus 暴露 |
| 后端服务器健康状态 | 控制面健康检查 + 数据面连接失败反馈 |
| 延迟（P95/P99） | 数据面记录请求耗时，上报 |
| 流量（Mbps） | 数据面统计收发包，汇总上报 |
🔹 数据面通常通过以下方式上报：
- gRPC/Thrift 主动上报；
- Prometheus Exporter 被动暴露指标；
- 日志系统（如 ELK）解析访问日志。
3. “生效状态” → 控制面与数据面协同
Web 界面可能显示“规则已下发到所有节点”，这需要：
- 控制面记录下发状态（是否已推送到所有数据面实例）；
- 数据面返回确认 ACK（如“ACL 规则 v2 已加载”）；
- 控制面汇总后，向 Web 返回“已生效”。
✅ 四、为什么不直接从数据面读取配置？
❌ 问题：
如果 Web 界面直接从数据面读取配置，会带来严重问题：
| 问题 | 说明 |
|---|---|
| 配置不一致 | 多个数据面实例可能处于不同版本（正在更新中） |
| 数据面不可用时无法查看 | 数据面崩溃，但用户仍需查看配置 |
| 缺乏审计能力 | 无法知道谁在什么时候修改了配置 |
| 无法支持“待生效”配置 | 用户修改后，需预览，但尚未下发 |
✅ 控制面是配置的“权威源” ，确保一致性、可审计、可回滚。
✅ 五、实际案例：阿里云 SLB / AWS ELB
| 云厂商 | Web 控制台配置来源 |
|---|---|
| 阿里云 SLB | 控制面（管控系统） + 监控系统（ARMS） |
| AWS ELB / ALB | AWS 控制面 API + CloudWatch 指标 |
| 腾讯云 CLB | 控制集群 + Prometheus 监控 |
| 华为云 ELB | 控制面配置库 + Telemetry 上报 |
它们都遵循：配置看控制面，状态看监控。
✅ 六、总结
Web 界面显示的配置信息，主要来自控制面；实时状态信息来自数据面的监控上报。
| 信息类型 | 来源 | 是否可直接从数据面读？ |
|---|---|---|
| 配置（What you set） | ✅ 控制面 | ❌ 不推荐（不一致、不可靠） |
| 状态（What is happening） | ✅ 数据面 + 监控 | ✅ 是唯一来源 |
| 生效状态（Is it applied?） | ✅ 控制面汇总数据面反馈 | ⚠️ 协同结果 |
💡 类比理解
| 类比 | 控制面 | 数据面 | Web 界面 |
|---|---|---|---|
| 公司管理 | HR 系统（员工信息） | 考勤机（打卡记录） | 管理后台（查看花名册 + 出勤率） |
| 数据库 | 主库（写入） | 从库（读取） | 应用前端 |
| 编译器 | 源代码 | 可执行文件 | 运行日志 |
控制面是“源代码”，数据面是“运行程序”，Web 界面是“开发者工具” 。
这种架构确保了云负载均衡的高可用、可管理、可观测。
