4. 网络自动化编排技术栈

网络自动化编排不是单一软件，而是一套分层协作的技术栈。理解这套栈的关键，是分清“谁做决策、谁做翻译、谁做执行、谁做反馈”。本节围绕控制器、编排器、南北向接口以及 NETCONF、RESTCONF、gNMI、OpenConfig、Telemetry 等核心组件与协议，梳理它们各自的职责边界与协作关系。

一、编排器与控制器：决策层与执行层

编排器（Orchestrator）面向业务意图，负责跨域、跨设备的流程编排。它接收“开通一条总部到分支的专线”这类业务请求，将其拆解为多个可执行任务，并决定执行顺序、依赖关系和失败回滚策略。编排器通常不直接与设备交互，而是调用控制器提供的北向接口。

控制器（Controller）面向网络设备，负责将编排器下发的抽象指令翻译为具体设备可执行的配置或操作。控制器维护网络拓扑、设备清单和状态模型，是“意图”与“设备”之间的翻译层。在 SDN 架构中，控制器还承担路径计算、策略下发和状态采集等职责。

两者的分工可以概括为：编排器管“做什么、按什么顺序做”，控制器管“对哪台设备、用什么协议做”。

二、北向接口与南向接口

北向接口（NBI）是编排器与控制器之间的契约，通常以 RESTful API、gRPC 或消息队列形式暴露。它传递的是业务级或网络级意图，例如“创建租户 VPC”“调整带宽至 200Mbps”。北向接口的设计强调抽象性和稳定性，避免上层业务随底层设备型号变化而频繁修改。

南向接口（SBI）是控制器与网络设备之间的通道，负责下发配置和采集状态。南向接口的协议选择直接决定了自动化的能力边界：NETCONF 适合配置管理，gNMI 适合高速遥测，RESTCONF 适合轻量级 HTTP 集成。南向接口强调设备兼容性和操作原子性。

三、核心协议与数据模型

NETCONF 基于 SSH，使用 XML 编码，通过 <get-config>、<edit-config>、<commit> 等操作实现配置的读取、修改和提交。它支持候选配置（candidate datastore）和事务回滚，适合对配置一致性要求高的场景。

RESTCONF 将 NETCONF 的数据模型映射到 HTTP 方法上，用 GET、POST、PUT、PATCH、DELETE 操作 JSON 或 XML 数据。它降低了集成门槛，适合 Web 应用和轻量级工具链快速接入。

gNMI（gRPC Network Management Interface）基于 gRPC 和 Protobuf，提供 Subscribe、Get、Set 三类操作。其最大优势是支持流式遥测订阅，设备可主动推送状态变化，而非等待控制器轮询。

OpenConfig 不是协议，而是一套厂商中立的 YANG 数据模型。它定义了接口、路由、QoS 等标准路径，使 NETCONF、RESTCONF、gNMI 可以用统一的路径表达配置和状态，例如 /interfaces/interface[name=Ethernet1]/state/counters/in-octets。

Telemetry 是状态采集机制，通常与 gNMI 配合使用。它支持周期上报和事件触发上报，将设备指标以流式方式推送到采集器，再汇入监控或分析平台，形成“配置下发—状态反馈”的闭环。

四、协作流程与闭环

一次完整的自动化编排通常经历以下链路：编排器接收业务意图，通过北向接口调用控制器；控制器将意图翻译为设备级操作，选择 NETCONF 或 gNMI 等南向协议下发；设备执行后，Telemetry 将接口流量、CPU 利用率、路由收敛状态等指标流式回传；采集器将数据送入监控平台，控制器或编排器根据反馈判断是否达成目标，必要时触发调整。

以“为分支节点开通 200Mbps 专线”为例：编排器拆解出“创建隧道接口”“配置 QoS 策略”“绑定至物理口”三个任务；控制器通过 NETCONF 的 <edit-config> 下发接口配置，通过 gNMI 的 Set 下发 QoS 参数；设备提交后，gNMI Subscribe 订阅接口速率计数器，若 30 秒内速率稳定在 190–210Mbps 区间，则判定开通成功，否则触发回滚。

五、关键判断依据

判断技术栈是否就绪，可以观察三个信号：北向接口是否稳定抽象（业务变更不引发设备级改动）、南向协议是否覆盖目标设备（设备是否支持所需 datastore 和 RPC）、Telemetry 是否形成有效反馈（指标延迟是否满足闭环要求）。三者缺一，自动化编排就容易退化为“脚本批量下发”，失去意图驱动的核心价值。