2.1 三层架构与组件分工
2.1 三层架构与组件分工
本节摘要：ETSI NFV 架构的核心是分层解耦——NFVI 提供资源池，VNF 承载网络功能，MANO 统筹管理。本节讲清三层的内部结构，重点拆解 MANO 的 NFVO（全局编排）、VNFM（VNF 生命周期）、VIM（基础设施管理）三组件的职责边界，以及它们之间通过参考点（接口）交互的方式。
学习目标
阅读完本节，你应当能够：
- 画出 ETSI NFV 三层架构并标注主要参考点
- 说清 NFVO、VNFM、VIM 各自的职责和不重叠的边界
- 解释虚拟化层（VL）怎么屏蔽硬件异构性
- 说明 VNF 描述符（VNFD）和 NS 描述符（NSD）的作用
- 区分 Element Manager 模式和 VNFM 直接模式
一、问题与直觉
为什么 NFV 需要一套标准架构？想象一下，如果没有标准，每家厂商自己定义一套 NFV 实现——A 厂商的 VNF 跑在 A 厂商的 NFVI 上，用 A 厂商的管理软件；B 厂商完全是另一套。运营商想混用 A 和 B 的设备，接口对不上，集成成本爆炸。这正是传统网络设备"厂商锁定"的老问题在 NFV 时代的翻版。
ETSI 的标准架构就是为了解决这个问题。它定义了清晰的分层（NFVI、VNF、MANO）和组件间的标准接口（叫参考点，Reference Point）。只要各厂商的实现遵循这些接口，就能互操作——A 厂商的 VNF 可以跑在 B 厂商的 NFVI 上，用 C 厂商的 MANO 管理。这种"接口标准化、实现自由化"的思路，是打破厂商锁定的关键。
理解这套架构，你就能看懂任何 NFV 实现的内部结构——不管是开源的 OpenStack+ONAP，还是某厂商的私有方案，底层都是这三层和这几个组件。
二、核心原理
2.1 三层架构总览
ETSI NFV 架构把整个系统分成三层，加上外部的业务/运营支持系统（OSS/BSS）和网元管理系统（EM）：
三层各自的角色：
- NFVI（基础设施层）：物理硬件（服务器、存储、交换机）+ 虚拟化层（hypervisor 或容器运行时）。它把硬件资源抽象成虚拟资源池，供 VNF 使用。
- VNF（功能层）：虚拟网络功能实例，跑在 NFVI 提供的虚拟机或容器里。多个 VNF 可以串联成服务链（SFC），提供端到端网络服务。
- MANO（管理与编排层）：统筹全局，负责 VNF 生命周期、资源调度、服务编排。
2.2 NFVI 与虚拟化层
NFVI 是整个架构的地基。它包含两部分：
物理硬件资源：通用 x86 或 ARM 服务器（提供计算）、SAN/NAS/分布式存储（提供存储）、交换机和网卡（提供网络）。关键点是这些硬件都是 COTS（商用现货），不绑定特定网络设备厂商。
虚拟化层（Virtualization Layer，VL）：通常就是 hypervisor（如 KVM、VMware ESXi）或容器运行时（如 containerd、CRI-O）。它把物理硬件抽象成虚拟计算实例（VC）、虚拟存储（VS）、虚拟网络（VN），屏蔽底层硬件的异构性。
虚拟化层的价值在于硬件无关性。不管底层服务器是戴尔还是惠普，不管 CPU 是 Intel 还是 AMD，虚拟化层都向上提供统一的虚拟资源接口。VNF 不用关心跑在什么硬件上，只要关心虚拟化层给的资源。这让 VNF 可以在不同硬件平台间自由迁移。
💡 关键直觉：虚拟化层是 NFVI 的灵魂。没有它，硬件还是一堆各异的物理设备；有了它，硬件变成统一的资源池，VNF 才能像云上的应用一样自由调度。这也是为什么 NFVI 的选型核心往往落在虚拟化层（用 KVM 还是 VMware、用虚拟机还是容器）。
2.3 VNF 与描述符
VNF 是网络功能的软件实现。但 MANO 要管理成百上千个 VNF，怎么知道每个 VNF 长什么样、需要多少资源、怎么配置？答案是描述符（Descriptor）。
每个 VNF 都有一个 VNFD（VNF Descriptor，VNF 描述符），它是一个模板文件，描述了这个 VNF 的：
- 部署需要的资源（CPU、内存、存储）
- 组成结构（由哪些虚拟机或容器组成）
- 连接关系（内部组件怎么互联）
- 配置参数（启动时怎么配）
类似地，一个网络服务（NS，Network Service）有一个 NSD（NS Descriptor，网络服务描述符），描述这个服务由哪些 VNF 组成、它们怎么串联成服务链。
MANO 的工作就是读这些描述符，按图索骥地部署和管理 VNF/NS。描述符让"网络服务"变成了可编程、可版本化、可自动部署的东西——这正是"网络即代码"（Network as Code）理念的体现。
2.4 MANO 三组件
MANO 是架构里最复杂的部分，它拆成三个组件，各有明确分工：
NFVO（NFV Orchestrator，NFV 编排器） 是战略层。它负责全局编排：
- 接收来自 OSS/BSS 的网络服务请求
- 读取 NSD，创建和终止整个网络服务（NS）
- 跨多个 VNF 和资源池协调部署
- 监控服务级 SLA，触发扩缩容
VNFM（VNF Manager，VNF 管理器） 是战术层。它负责单个 VNF 的生命周期：
- 根据 VNFD 实例化（创建）VNF
- 扩缩容（增加或减少 VNF 实例）
- 愈合（检测故障并恢复）
- 终止（销毁 VNF）
- 配置变更
VIM（Virtualized Infrastructure Manager，虚拟基础设施管理器） 是执行层。它直接管 NFVI 资源：
- 分配和回收虚拟机/容器资源
- 管理虚拟网络（创建虚拟交换机、端口）
- 管理存储卷
- 监控资源使用情况
| 组件 | 管理对象 | 典型实现 |
|---|---|---|
| NFVO | 网络服务（多个 VNF 组成） | ONAP SO、OSM |
| VNFM | 单个 VNF 的生命周期 | 厂商专用、ONAP 内置 |
| VIM | NFVI 虚拟资源 | OpenStack、Kubernetes |
VIM 最常见的开源实现是 OpenStack（管虚拟机）和 Kubernetes（管容器）。一个 NFV 部署里可能有多个 VIM（比如一个 OpenStack 管数据中心 A，一个 K8s 管数据中心 B），NFVO 负责跨 VIM 协调。
2.5 参考点（接口）
组件之间通过 ETSI 定义的参考点（Reference Point）交互。参考点本质是标准化的接口规范，让不同厂商的组件能互操作。几个关键的：
| 参考点 | 连接谁和谁 | 干什么 |
|---|---|---|
| Os-Ma-nfvo | OSS/BSS ↔ NFVO | 业务需求下发、状态上报 |
| Vi-Vnfm-vnf | VIM ↔ VNFM | VNFM 请求 VIM 分配资源 |
| Or-Vnfm | NFVO ↔ VNFM | NFVO 指挥 VNFM 管理 VNF |
| Or-Vi | NFVO ↔ VIM | NFVO 直接调度资源（跨 VIM） |
这些参考点的存在，让运营商可以"混搭"不同厂商的组件——比如用 A 厂商的 NFVO、B 厂商的 VNFM、开源 OpenStack 当 VIM，只要大家都遵循参考点规范，就能协同工作。
⚠️ 常见坑：参考点是规范层面的接口定义，不是现成的协议。实际实现里，不同厂商可能用不同的协议（REST API、消息队列等）来实现同一个参考点，导致"理论上兼容、实际上要适配"。这也是为什么多厂商 NFV 集成仍然是个苦差事——标准有了，但实现的成熟度和一致性参差不齐。
三、工程实践要点
3.1 VNFM 的两种模式
VNFM 管理 VNF 生命周期时，有两种模式：
Element Manager（EM）模式：VNFM 不直接管 VNF，而是委托给 VNF 厂商自己的网元管理系统（EM）。VNFM 只负责"通知 EM 该做什么"，具体怎么做由 EM 决定。好处是 VNF 厂商对自己的功能最了解，管理更精准；坏处是引入了额外的 EM 组件，集成更复杂。
直接模式：VNFM 直接管理 VNF，不经过 EM。好处是架构简单、链路短；坏处是 VNFM 必须理解每种 VNF 的细节，通用性差。
实际部署中往往混用：标准化程度高的 VNF（如 vFirewall）用直接模式，复杂度高、厂商专有性强的 VNF（如 vEPC）用 EM 模式。
3.2 多 VIM 部署
大型运营商往往有多个资源池（不同地域、不同厂商），每个池子一个 VIM。NFVO 负责跨 VIM 协调：
- 一个网络服务可能跨多个 VIM 部署（比如 vFirewall 在数据中心 A，vLB 在数据中心 B）
- NFVO 要处理跨 VIM 的网络连通性
- 资源调度要考虑各 VIM 的负载和容量
多 VIM 让运营商避免锁定单一厂商的虚拟化方案，但跨 VIM 的网络编排复杂度高，是工程上的难点。
3.3 从虚拟机到容器的架构影响
当 VNF 演进到 CNF（容器化），VIM 的角色也在变。传统 VIM 是 OpenStack（管虚拟机），云原生场景下 Kubernetes 成为新的"VIM"（管容器）。ETSI Release 4 已经把容器编排纳入架构，定义了容器基础设施管理器（CISM）等新组件。
这意味着同一个 NFV 部署里，可能既有 OpenStack（管传统 VNF）又有 Kubernetes（管 CNF），NFVO 要同时协调两者。架构在演进中，不是一步到位的。
本节要点回顾
- ETSI NFV 三层架构：NFVI（资源池+虚拟化层）、VNF（功能软件）、MANO（编排管理），加外部 OSS/BSS 和 EM。
- 虚拟化层是 NFVI 的灵魂：屏蔽硬件异构性，把物理资源变成统一的虚拟资源池。
- 描述符让网络服务可编程：VNFD 描述单个 VNF，NSD 描述网络服务，MANO 按图索骥部署。
- MANO 三组件分工：NFVO（全局编排）、VNFM（VNF 生命周期）、VIM（基础设施资源），职责不重叠。
- 参考点是标准化的接口规范：让不同厂商组件能互操作，但实际实现的成熟度参差不齐。
- VNFM 有 EM 模式和直接模式：前者委托给厂商 EM，后者直接管，按 VNF 复杂度选。
- 云原生演进让 Kubernetes 成为新 VIM：同一部署可能并存 OpenStack 和 K8s。
下一节看 MANO 怎么把一个网络服务从描述符变成实际运行的实例——完整的编排工作流和闭环自动化。
四、读架构图的方法：数据面与控制面分轨
ETSI 架构图信息密度高，新手常被组件名称淹没。给一个读图方法：任何 NFV 架构图都分两条轨道看。管理轨道：VNFM 管 VNF 的生老病死、NFVO 管跨域服务和资源编排、VIM 管单域基础设施——这条轨道上流动的是"意图"（部署请求、伸缩策略、迁移指令），走的是带外管理网络。业务轨道：VNF 之间转发的真实用户流量，走的是数据网络，SDN 控制器在这里配合建路。两轨分离是整个架构的第一设计原则——管理面的故障绝不能传染业务面，反之业务面洪峰也不能压垮管理面（历史上共享管理通道导致的雪崩事故是这条原则的由来）。评审任何 NFV 方案图，先找两条轨道各画一条线，再检查交叉点是否有隔离措施，五分钟内就能发现大多数设计缺陷。这个方法也解释了为什么组件要拆这么细：拆分的实质是让意图的传递路径和流量的转发路径各自独立演进、独立扩容。
五、接口点：架构图的关节
三层架构图上最容易被忽视、实战中最重要的一组元素是参考点——组件之间的标准化接口。给一个速记清单：运营支撑层与编排器之间是业务意图的入口接口（订单翻译成网络服务请求）；编排器与 VNF 管理器之间是生命周期指令接口（实例化、伸缩、终止）；VNF 管理器与基础设施管理器之间是资源申请接口（要几台虚机、什么规格）；编排器与基础设施管理器之间是全局资源视图接口（跨域调度的前提）。记接口的实用价值在故障定位与集成测试：任何一次跨组件的操作失败，先看它走的哪条参考点，再查该接口的消息日志——四个参考点各配一条日志流，是排查 NFV 问题的第一现场。集成测试也按参考点逐条验证，比端到端黑盒测试能更早暴露兼容性问题。厂商方案的差异也藏在接口实现质量里：同样的标准接口，有的实现连超时重试都没做，集成期就是灾难——招标评审时把接口实现的健壮性清单列进打分表，是行业付出无数学费后的成熟做法。
补一个接口命名的记忆锚点：参考点的编号有规律——首字母 N 加两位数字，数字段位区分层级关系。记不住具体编号没关系，记住一个原则就够：看到任何厂商文档里的接口名，先定位它连接的两个组件，再回想这对组件的职责边界，接口的用途自然浮现。架构图的关节不在名字，在职责。