架构图
- 控制平面
控制平面是一个进程，一般监听socket，接收web、cli、netconf、restful等用户接口的配置下发，配置查询。 控制平面负责配置的持久存储，支持进程重启，集群配置同步，存数据库等。
- control-dp
control-dp与dp是多线程，共享地址空间，都属于数据面。
称之为control-dp,是因为它是dp用来通信的线程。
- dp
dp中的对象，可以以id为key，用于查找、更改配置，此时使用RCU方式，是典型的线程同步场景。
前一篇文章 网络设备控制平面的通用架构模式 - 掘金
介绍了控制平面的通用架构， “配置与状态分离”、“对象引用 + 运行时上下文实例化” 主要发生在控制面。
而数据面：
- 数据面通常不保存完整对象模型；
- 数据面使用高度优化的扁平化数据结构（如哈希表、数组、位图）；
- 数据面关注的是快速查找、匹配、转发，而不是对象建模；
- 所谓“对象”，在数据面往往被编译/展开为规则条目或状态条目，不是面向对象意义上的“实例” 。
控制面 vs. 数据面：职责对比
| 维度 | 控制面（Control Plane） | 数据面（Data Plane） |
|---|---|---|
| 职责 | 配置管理、策略决策、健康检查、会话管理、状态维护 | 高速报文处理：解析、匹配、调度、转发、NAT、限速等 |
| 性能要求 | 秒级/毫秒级响应即可 | 微秒级处理，百万PPS |
| 数据结构 | 复杂对象模型、树、链表、状态机 | 哈希表、数组、位图、无锁队列 |
| 语言/环境 | C/C++、Python（配置）、多线程 | C、汇编（关键路径）、DPDK/XDP、SIMD |
| 是否面向对象 | ✅ 是（逻辑上） | ❌ 否（性能优先） |
数据面：不是“对象”，而是“规则/状态条目”
数据面不会为每个 Real Server 创建一个 C++/C 结构体对象实例。它只关心：
“这个报文，应该转发给哪个后端 IP:Port？”
为此，数据面使用预计算的、扁平化的转发信息库（FIB-like）结构。
典型数据面结构（以 DPVS 或 LVS 为例）：
- 连接跟踪表（Connection Tracking Table）
- 调度表（Scheduler Table）
- 规则表（如 ACL、NAT 规则）
控制面如何“下发”到数据面？
这是一个关键机制：控制面向数据面“发布”状态快照。
流程如下：
- 控制面检测到
RS1在VS1上健康状态变为DOWN； - 控制面更新
VS1的运行时状态； - 控制面重新计算
VS1的可用后端列表； - 控制面通过IPC（进程间通信）或共享内存，将更新后的调度表“推”给数据面；
- 数据面原子更新其本地的
server_entry[]数组； - 后续新连接不再调度到该 RS。
数据面不主动感知健康状态，它信任控制面的决策。
