2.2 关键组件对照：逐跳配置对集中编排

2.2 关键组件对照：逐跳配置对集中编排

上节把控制权分了层，本节把层落到组件：传统分支的一台路由器加上外围安全盒子，在 SD-WAN 里被拆成了哪几件、每件接走了哪些职责。读完本节，你应当拿到一份"功能放置映射表"，用于审任何厂商的架构图——看懂谁把什么放在哪，比记住产品名重要得多。

盒子里少了什么

把传统分支机房清单摊开：一台边界路由器（跑 OSPF/BGP、做 NAT）、一台防火墙（策略与攻击防护）、可能还有一台 VPN 网关（与总部打 IPSec 隧道）、加一个链路负载均衡器（如果有双线）。这些盒子各自有配置界面、各自的策略库、各自的小算盘。SD-WAN 做的第一件事是合并：路由、NAT、防火墙基础策略、IPSec 隧道、多链路负载均衡，全部收进同一台 x86 或 ARM 架构的边缘设备，软件化交付（可以是硬件盒子，也可以是虚机或容器形态）。第二件事是上收：跨站点的选路决策、策略分发、证书管理，交给控制器与编排器。

功能放置映射表

图：组件对照：从一柜子盒子到三件套

规模的分界点

三件套的形态选择随规模而变，给出经验分界点供参考。十个站点以内：边缘加一体化云平台（控制器编排器合一），一张模板管全网，不值得为分离架构付复杂度。几十到几百站点：完整三件套分离，管理平面开始承担审批流与多角色协作，控制平面集群化。上千站点：还要加两级设计——区域化控制平面（分大区部署，就近服务站点，控制流量不跨洋）与分层编排（全网编排放全局策略，区域编排做本地化适配）；此时策略一致性靠"全局模板加区域变量"的机制保证，任何手工的站点级配置都会成为审计噩梦。规模跨越分界点时的架构迁移要提前规划——从一体化迁到分离、从单平面迁到区域化，都是伤筋动骨的工程，立项时按三年后的规模选形，而不是按当下。

控制器与编排器：为什么是两个组件

不少方案图上控制器（Controller）与编排器（Orchestrator）画成两个框，初学者常以为是营销拆分。工程上的分界在于职责：控制器对实时性负责——维护拓扑、分发路由与隧道策略、协调密钥，失联会影响新策略下发但不影响既有转发；编排器对生命周期负责——站点从入网到退役的配置管理、模板版本、灰度与回滚，停机只影响变更不影响运行。小规模部署里两者常合并交付，但评估大型网络时值得追问：编排器的变更能否在控制器集群滚动升级期间照常排队？两者的数据库是否独立备份？

边缘设备的形态选择

边缘三形态各有利弊：硬件盒子性能稳、上线快，适合标准分支；虚机形态（跑在分支现有服务器或私有云上）省硬件、适合已虚拟化的站点；容器/云原生形态弹性最好，适合云上分支与临时点位（第 7 章的云分支会展开）。选型判断只有两条硬标准：加密吞吐是否达标（IPsec 全覆盖下，加密性能就是转发性能）、以及 QoS 队列数与应用识别库的更新频率是否满足第 4 章的策略需求。

一个站点的组件协同全过程

把三件套的协作串成一个完整故事：某连锁企业要在新城开一家门店。第零步（编排器）：网络管理员在管理平面新建站点档案，填入站点类型（标准店）、区域（华东）、链路计划（一条宽带加一张 5G），从模板库选择"标准店模板"并保存——此刻没有任何设备存在，配置只是一份数据。第一步（编排器到控制器）：编排器把站点档案推给控制器，控制器在授权清单里预留该站点的位置，等待设备认领。第二步（设备入网）：边缘设备快递到店，店员通电插线，ZTP 流程启动（6.2 节展开）——设备出示出厂证书，控制器核对清单、发放站点身份，编排器匹配到站点档案，把模板生成的配置下发。第三步（控制器到边缘）：控制器把该站点的隧道端点信息、路由策略、应用组策略、分段规则批量推给边缘；边缘与全网各站点建立 IPSec 隧道。第四步（运行态）：边缘本地执行选路与安全策略，探测数据回传控制器，遥测汇入管理平台的仪表盘；管理员在平台上看到新站点亮起"在线"。

全程网络工程师的动手环节：填一张站点表。其余环节全部自动化——这正是第 1 章对照图里"逐跳配置对集中编排"的具象化。老工程师看这个故事会有个直观感受：过去两周的差旅和两个通宵的割接，被压缩成了一次填表加半小时的等待。

问题：三件套会不会太多余？一个盒子全干了不行吗？

小网络里可以，很多厂商的小规格套餐就是控制器与编排器合一交付。但规模上去后分离的价值显现：管理平面的变更操作重（表单、审批、灰度），控制平面的实时性要求高（秒级响应遥测），两者的负载特征、故障模式、升级节奏完全不同。合在一起的结果是要么变更窗口冻结实时选路的升级，要么实时组件的频繁升级威胁配置数据安全。分离不是架构洁癖，是让"慢系统"与"快系统"各自按自己的节奏演化。

本节要点

• SD-WAN 的组件替换是"合并 + 上收"：站点侧功能合并进边缘，跨站决策上收到控制器与编排器。
• 控制器管实时（拓扑、策略、密钥），编排器管生命周期（模板、灰度、审计），职责分界在时间尺度。
• 审架构图的三问：功能放置、控制通道安全、失联兜底；红旗项是全家桶绑定与控制面单点。
• 边缘形态（硬件/虚机/容器）看两条硬标准：加密吞吐与策略执行能力。

最后一个选型视角：把本章的组件对照当"Shopping List"反着用。先按业务需求列功能清单（多少站点、哪些应用、什么合规），再对照本章映射表推算需要的组件规格——边缘的加密吞吐按站点流量峰值定、控制器按隧道与策略规模定、编排器按变更频率与角色数定。先需求后规格，采购单上每一行都有出处；反过来从厂商的产品层级倒推需求，多半会多买一级规格。

下一章进入这些组件协作的产物：Overlay 隧道怎么建、链路质量怎么量、选路决策怎么落地。