在上期的文章中，我向各位读者解读了全球运营商NFV的整体情况、典型海外运营商NFV的发展思路以及我国运营商NFV的发展情况。尽管国内运营商在NFV的使用上以颇有成果，但相比海外运营商，国内运营商整体NFV商用进程并不快。究其原因是从多厂商互操作、VNF云化能力、端到端自动化水平等角度考虑，还存在着一些明显的问题和不足。这些问题具体表现为什么现象？企业应该如何处理？国内运营商后续的发展思路是什么？您将在文章中获得答案。
五、存在的问题及后续发展思路
相比海外运营商而言，国内运营商整体NFV商用进程并不快。国内三大运营商通过近两三年的PoC、试验网、现网试点以及试商用等一系列工作，已经基本掌握了NFV虚拟化阶段的核心技术和能力，2018年可以预见到更多的规模化商用部署落地。然而从多厂商互操作、VNF云化能力、端到端自动化水平等角度考虑，还存在着一些明显的问题和不足，尚不能像乐高积木那样实现虚拟网络功能和业务的无缝拼接组装。
这些问题是NFV从虚拟化阶段迈向云化阶段必然面临的，后续需要进一步推进从虚拟化到云化能力的突破来解决。下文针对几个主要问题进行讨论，并尝试提出后续发展思路。
（一）多厂商间的互操作
NFV开放式生态系统发展所面临的最大挑战是如何实现互操作性。为了应对这一挑战，ETSI一直致力于在关键接口规范定义方面取得实质性的进展，这些规范是确保不同实现之间互操作性必不可少的。
如图10所示，互操作性需求的关键在于基于ETSI 定义的功能需求及模型驱动设计思路，实现接口的标准化及模型的标准化（VNFD、NSD、VNF包等）。
图 10 : 实现NFV多厂商之间互操作的关键
ETSI NFV规范定义分为三个成熟度阶段（参见图11）。2015年到2017年上半年，ETSI NFV发布的规范还主要集中在Stage 2层面，尚不能直接指导多厂商之间的互操作。直到2017年8月，SOL工作组发布了Stage 3阶段的部分关键成果，成为解决多厂商互操作问题的关键里程碑！
图 11 : ETSI NFV规范的三个阶段
ETSI SOL工作组针对NFV互操作层面主要发布和待发布的规范文档如图12所示。
图 12 : ETSI NFV Stage 3阶段支持互操作的关键标准规范
由于ETSI NFV在前一段时间的标准化工作进展缓慢，国内运营商在最近2年的现网试点过程中，基本上都是依托ETSI在Stage 2阶段的标准，自主完善设计了MANO等关键功能的数据模型和相关接口的RESTful协议，以实现多厂家之间的互操作。这和多数海外运营商的做法类似，是标准滞后于实践导致的折中办法。
对比国内三大运营商的MANO规范和最新的SOL Stage 3规范，我们可以看到存在着不少的问题，例如：
模型驱动的核心是模型本身的开放。受部分厂商影响，国内运营商规范目前基本不支持NFVO对VNFD模型的直接解析，而是变相增加了一个查询VNFD的接口。这有违模型驱动思想的本质，不利于未来基于乐高积木方式实现VNF快速验证与部署；
从ETSI设计角度，授权接口本质上是对VNF生命周期管理操作的授权（例如：删除VNF的操作需要NFVO确认该VNF是否被某个实例化的NS所使用，没有被使用的情况下才有可能授权允许删除），而目前国内运营商规范中仅仅是对虚拟资源的申请进行授权。单纯从资源角度考虑授权有违于ETSI设计初衷，会带来很多潜在问题；
ETSI规范定义了完善的扩缩容机制设计，包括Deployment Flavour、Scale Aspect, Instantiation Level等信息元素，同时支持Scale to Level以及Scale两个层面的操作，目前国内运营商规范完全没有体现出这种细粒度和精准的扩缩容设计思路，无法支持VNF云原生能力；
国内运营商规范中，针对各类Notification的订阅通知接口不符合互联网程序设计管理，也不符合ETSI规范的设计思路。
在NFV实践过程中，运营商最重要和基本的目标之一是实现将开放式生态系统内的不同组件快速组装在一起的互操作性能力。而在开放的环境中，实现互操作首先必须基于对ETSI定义的功能规范、模型驱动思路以及接口和模型规范的全面和完整的理解，而不是简化和曲解。
ETSI部分关键互操作标准在2017年8月份已经发布，后续如VNFD的TOSCA模型也即将在2018年初发布，这为解决开放式生态环境奠定了重要的基石。何时、以什么方式将现有运营商MANO规范过渡到标准的ETSI Stage 3规范，以彻底解决互操作这一基本问题，是国内各运营商在NFV后续发展过程中需要重点考虑和规划的。
（二）VNF云化就绪能力
从这两三年国内运营商的NFV实践中可以发现，VNF的云化就绪能力一直没有得到系统性的研究和测试，而这正是NFV从虚拟化阶段到云化能力阶段突破的关键。
目前国内各大运营商在NFV实验室测试及现网试点过程中，并没有采用有效的手段了解厂商VNF是否按云化或者云原生进行设计与实现（更不用谈在这方面进行规范和约束），例如：
VNFC的设计是否合理？是否每个VNFC能提供单一能力并且相互独立（如：是否将依赖特定加速能力的功能组件设计为独立的VNFC）？
VNFC组件在部署时是否存在单点故障？
关键组件的冗余备份模式是什么？多个并行处理组件之间的负载均衡是如何实现的？如何检测到组件故障并完成自动恢复？如果不能自动恢复，如何通知MANO介入？
微服务能力：VNF是否基于微服务架构进行设计？每个VNFC是否可以独立部署、配置、升级以及监控？
部署及扩缩容机制：能否支持多种部署规格以满足不同的业务场景？能否针对与特定业务流量能力相关的一组VNFC进行独立扩缩容？是否可以按不同的等级和粒度对不同的VNFC组进行扩缩容？
状态管理：VNFC是否尽可能采用无状态方式设计和实现？针对有状态的VNFC，是否实现了逻辑与状态的分离，对状态是如何进行持久化的？
上述VNF云化就绪能力是否具备，将极大地影响VNF的可靠性、水平弹性扩展能力以及自动化管理能力，而这对基于VNF部署的业务运行至关重要。
云模式有别于传统企业计算模式的一个非常重要之处就在于假设基础设施是不牢靠的、无法提供足够的可靠性，需要从应用层角度，采用云化设计思路，确保应用具备高可用性能力。这样的应用可以部署在任何不可靠的基础设施环境中，同时确保业务的高度可靠运行。领先的运营商很早就在考虑这方面的工作，例如：上文提到，AT&T在Domain 2.0中，专门针对VNF的云化就绪等制定了一系列要求及指南，另外，ETSI在其规范EVE 011也专门定义了云原生VNF从实现角度需要考虑的一系列非功能性要求。
建议国内运营商在虚拟化阶段目标基本实现的基础上，尽快展开VNF云化就绪能力的规范性及测试工作。
（三）自动化能力水平
从商用部署及业务创新角度看，仅仅具备虚拟化能力的NFV无法完全满足业务运维的自动化需求以及新业务快速上线的要求，需要在云化阶段重点打造和提升自动化能力水平。
自动化能力水平的提升涉及到多个方面，例如：
针对不同厂商的VNF（基于上文提到的VNF云化就绪要求和互操作规范），建立统一的VNF认证与测试平台（类似于AT&T的ICE环境），可以极大地提高VNF验证和测试的自动化水平，缩短认证时间，加速新业务网元的规范引入。将来还可以进一步考虑将该平台与运营商下一代OSS的DevOps平台打通，实现VNF厂家与运营商之间跨域的CI/CD流水线，这对多厂商NFV生态环境的建设有重要的促进作用。
端到端业务管理自动化能力的提升。ETSI规范以及国内针对NFVO+的实践中，即使是增加了对虚拟网元的FCAPS管理能力，也并未包含对VNF的业务配置以及业务管理控制能力。从自动化业务运维角度考虑，存在一定的缺陷。图13展示了一种可行的思路，即通过业务编排与NFV编排及EMS同时对接，通过综合网络业务相关的语义信息和虚拟化NFV环境的语义信息，对业务进行端到端的自动化编排和运维。
图 13 : 通过业务编排实现端到端业务管理自动化
目前几乎所有NFV相关的开源项目，如ONAP、OSM都在NFV架构基础上扩展了业务编排层，相关的标准化组织如：TM Forum ZOOM以及MEF LSO也都在进行这方面的研究。国内运营商在后期实践中可以借鉴这方面的成果。
六、总结
NFV是下一代云化可编程网络的关键支撑技术手段，ETSI制定的NFV核心框架及相关模型/接口是蓬勃发展的NFV产业的基石。随着互联网、云计算领域更多新技术的发展，NFV框架也在不断丰富和完善之中。从国内外运营商的PoC及现网部署情况综合起来看， NFV技术尚处于相对初级的阶段，有许多问题有待解决。目前全球NFV发展整体上处于虚拟化阶段之间，尚未进入到云化阶段。
国内三大运营商通过近两三年的PoC、试验网、现网试点以及试商用等一系列工作，已经基本掌握了NFV虚拟化阶段的核心技术和能力，2018年可以预见到更多的规模化商用部署落地。然而从互操作、VNF云化就绪、自动化水平等角度考虑，还存在着一些明显的问题和不足，需要进一步推进NFV从虚拟化到云化能力的突破。
NFV不仅是一项技术，更是不断涌现的IT创新技术和能力在通信行业源源不断应用的过程。NFV在发展过程中更加需要IT厂商的开源思想、创新思路和开放心态。
在NFV从虚拟化到云化砥砺前行的过程中，进一步加强运营商主导能力，优化NFV生态建设，营造一个IT与CT共同参与的良性NFV环境具有非常重要的战略意义。
本文作者： HPE大中华区NFV首席专家 赵华
