2.1 逻辑平面架构：控制与转发分离

2.1 逻辑平面架构：控制与转发分离

本章先回答"控制权放在哪"。承上：第 1 章确立了集中决策对设备自治的对照；本节把这个说法落成可工程检验的平面划分。启下：2.2 节的组件对照、第 3 章的选路执行，都建立在本节的消息通道与职责边界之上。

分层的动机

传统路由器把三件事揉在一个盒子里：管理员敲配置（管理）、路由协议算路并生成转发表（控制）、芯片按转发表发包（转发）。三者耦合的好处是天然自治——拔掉网线它照样按旧表转发；坏处是三件事互相拖累：改配置要进设备、看状态要登设备、策略一致性靠人肉保证。SD-WAN 的解法不是发明新平面，而是把三个平面物理拆开、通道加密、权责写死。

管理平面：声明意图的地方

管理平面是管理员与网络的接口：配置模板、策略编辑、拓扑展示、审计日志都在这里。它面向"慢变量"——站点增减、策略调整、版本升级，时间尺度是分钟到天。工程上它通常是一个多租户的 Web 平台或 API 服务，所有配置变更从这里经控制器中转下发，并留下完整的变更记录。评估一套方案时，管理平面要看三件事：变更能否灰度（先推一个站点再全网）、能否回滚、策略冲突能否在保存前被检查出来。

控制平面：实时算路的大脑

控制平面维护全网拓扑与链路状态，把管理平面下发的策略翻译成每个边缘设备的转发表项与隧道策略。它的输入有两路：一路是静态策略（哪些应用走哪类链路、优先级多少），一路是动态遥测（每条链路的时延、抖动、丢包，由边缘设备周期探测上报）。它的输出是转发指令。时间尺度是秒级——链路劣化到阈值，控制器或边缘本地逻辑在秒内完成切换。控制平面通常以集群形态部署（云端或数据中心），多节点冗余，节点间同步状态。

转发平面：只认表的执行者

转发平面在边缘设备上，职责被压缩到极限：按转发表封装、加密、转发，按本地策略表在控制器不可达时继续执行最后已知策略。它面向"快变量"——每个包的处置，时间尺度是微秒级。关键设计原则是转发不依赖控制平面在线：控制通道断了，业务流量照跑，只是暂时没有新的选路调整。

图：三平面拆分：消息走哪条通道，谁对谁负责

消息通道与协议承载

三平面之间靠三类通道连接，通道的协议承载因厂商而异，但角色分工一致。管理到控制：配置与策略的推送，常用 REST API 或厂商私有协议，TLS 加密。控制到转发：路由与隧道策略下发，典型做法是控制器与边缘之间维持加密的控制会话（如基于 DTLS/TLS 的私有协议，或标准 BGP 扩展），只传控制信息不传业务流量。转发到控制：遥测上行，包括链路探测结果、隧道状态、应用识别统计，采集粒度从秒到分钟。设计要点是控制通道与业务流量在物理链路上共路、在逻辑上隔离——业务走业务隧道，控制走控制会话，互不挤占也不互为故障域。

失联兜底：集权架构的安全阀

集中控制最大的质疑是"控制器挂了怎么办"。成熟架构的回答是三层兜底：其一，控制平面集群化，多节点跨机房部署，任一节点故障不影响策略下发；其二，边缘设备持久化最后已知策略，控制通道中断时按既有转发表与本地探测继续选路——本地探测指边缘设备自己也在对链路做时延抖动丢包测量，劣化越限时直接本地切换，不必等控制器指令；其三，管理平面与控制平面解耦部署，管理端故障只影响配置变更，不影响实时选路。审方案时务必让厂商演示"拔掉控制器"的场景：业务应无感知，仅策略变更与全局视图暂不可用。

控制通道的工程细节

通道本身有几个值得较真的细节。认证：边缘与控制器的第一次握手必须双向认证——边缘验控制器证书（防假冒平台下发恶意策略），控制器验边缘证书（防伪接入点窃取策略与拓扑）。证书体系由控制器侧统一签发，站点入网时分配（6.2 节 ZTP 的一部分）。保活与重连：控制会话有心跳保活，中断后指数退避重连，重连成功后增量同步错过的策略更新——同步机制要能处理"离线一天后回来"的场景，这是验收时值得现场测的项。带宽占用：控制消息的带宽占用极小（每站点每天通常在兆字节量级），但探测遥测的上行频率要设上限（3.2 节的开销纪律），避免 Thousand 站点规模的遥测洪峰压垮控制器入口。

版本一致性是另一个隐蔽考点：控制器升级后，新旧版本的策略语义是否兼容？边缘设备批量升级期间，新旧版本混跑是否正常？成熟厂商会维护版本兼容矩阵并在编排器里强制校验，不成熟的方案靠人记住"先升边缘还是先升控制器"——升级顺序错了全网瘫痪的案例并不罕见。

问题：管理平面能不能直接指挥转发平面，跳过控制器？

架构上可以（部分产品允许管理直连设备做应急配置），工程上应当禁止常态使用。跳过控制器的变更不进版本序列、不同步集群、不留审计，等于在集中管控体系里开了一条旁路——用三次就会退化回"人肉运维加漂移"。正确的用法是仅保留给"控制器全灭后的紧急救援"，且使用后必须做配置对账。审方案时可以问一句：你们的旁路配置如何被平台发现并收敛？答不上来的产品，旁路迟早变成常态。

策略冲突检查：集中管控最容易被低估的价值

策略从分散走向集中，除了下发效率，还有一项容易被忽略的能力：冲突检查。两台传统路由器上互斥的配置（一边允许、一边拒绝的同一条路径策略）要等故障发生才被发现；集中管理平面在策略保存时就能做一致性校验——同一应用组被两个策略域引用、链路偏好与安全规则互相矛盾、分段矩阵里出现互相覆盖的条目，都能在保存前被拦下。工程上的建议是把冲突检查设为强制（保存即检查、冲突即拒绝），并保留检查日志——每一条被拦截的冲突配置都是一次被避免的故障。评估平台时，故意录入两条互斥策略看它的反应，比看任何演示都更能区分成熟度。

问题：三个平面对应三种岗位吗？

不严格对应，但可以作为团队技能地图的参考。管理平面的工作是策略设计与变更流程——偏架构与流程能力；控制平面是平台运维——偏系统与排障能力；转发平面在站点侧，日常只剩硬件维护与现场配合——偏基础网络功底。小型团队常见的一人多面（设计、运维、现场都管）完全可行，三平面划分的价值此时在于划分关注时段：改策略集中在变更窗口、盯平台是日常、跑现场是例外。团队扩编时，按这三个方向分化岗位，比按"厂商产品"分化更稳定——产品会换，平面职责不会。

本节要点

• 三平面的划分标准是时间尺度与权责：管理管慢变量，控制管秒级算路，转发管每包执行。
• 控制通道与业务隧道逻辑隔离，控制信息加密传输，不与业务互为故障域。
• 边缘自治兜底是集中控制的安全阀：失联时按最后已知策略加本地探测继续服务。
• 管理平面看变更能力（灰度、回滚、冲突检查），控制平面看高可用，转发平面看自治完整性。

下一节把三平面映射到具体组件：传统分支路由器的功能清单，如何被边缘、控制器、编排器三件套接走。