NFV的五大矛盾

（1）自主与商业的矛盾

NFV的主要目标是实现网络设备的软硬件分离，可以进行云化、按需动态伸缩和自动化部署，未来结合网络大数据可以实现智能化运营。

NFV的总体趋势是底层硬件实现相对通用化，采用虚拟化技术/容器技术或分布式架构技术实现对底层通用设备的共享和弹性，向上为VNF（虚拟网络功能）按需提供各种配置的资源，这意味着NFV三个方面的特点或关键点：

1）网络功能软件化（VNF），未来的网络功能升级、增强都是通过软件完成的，不需要（或者很少需要）底层硬件的升级，因此VNF软件才是未来网络发展的“焦点”，VNF的微服务化、分布式架构改造、开源化、自主研发、Devops是未来的发展趋势，但当前VNF基本还是掌控在已有电信设备商手中，运营商几乎没有能力染指。

2）将构建统一的NFVI资源池体系，服务于全网的云化（虽然不同的网元对NFVI有差异化的需求，但并不影响NFVI的统一规划、建设和运维，只是从资源的具体部署和资源调度方面必然存在不同专业网络的资源“隔离性”），这是运营商认为的可以实现成本降低的主要希望，但实际上除了集约化带来的电力成本降低以及机房空间节省外，从基础实施角度看是否降低成本难以评估（网络设备传统上无法严格区分硬件和软件的成本），需要考虑服务器/存储/网络新建成本、NFV软件、HA、灾备、机房改造等总体成本。

3）需要引入新型的OSS和EMS/NMS，实现对VNF、VR（虚拟资源）以及PR（物理资源）的监控、配置、管理以及更高层次的网络服务编排等，这部分目前是由NFV架构中的MANO来完成，在ETSI定义的MANO架构中，MANO由NFVO（NFV Orchestration）、VNFM（VNF Manager）以及VIM（Virtual Infrastructure Management）组成，分别完成网络服务与资源的编排，VNF的管理以及NFVI的资源管理功能。

在以上所述的三个方面中，NFVI、各类VNF、MANO是NFV架构中的关键，以软件实现为主，从利于NFV规模化发展和实现最低化成本考虑，运营商是应该选择部分组件进行自主研发。

自主研发的好处是可以基于自身的需求进行定制化开发，而不是受制于厂商，而采用商业化软件带来的好处是快速部署，成熟度高，可靠性能高，但成本也高，而且依赖厂商带来的周期性更新，而不能快速响应，迭代式发展。

1）NFVI：目前主要是Hypervisor，Hypervisor自主研发的好处是未来可以全网统一Hypervisor，有利于全网的统一资源调度。目前大部分厂商都是基于开源KVM进行商业化定制和优化，特别是针对NFV转发性能要求高的特点，各个厂商都做了针对性的技术优化，这部分工作仍然难度相当大，运营商没有任何技术基础和人才积累，所以目前基本是没有人提Hypervisor的自主研发设想。各个厂商的Hypervisor与各自的VIM是存在捆绑性的，形成各自的“小王国”，无法实现不同厂商Hypervisor的互通。

2）VNFs：各类网元原来都是软硬件一体化的，运营商对网元的内部实现机制并不熟悉，也没有人真正去探究网元设备的大型软件系统该如何实现，这部分软件目前对于运营商来说也没有可能采取自主研发来实现，但对于NFV化的运营商肯定不能停留于仅仅实现基础设施的统一和共享，VNFs是未来运营商必然要去逐步攻克的，否则实现软件化只是表面的工夫，这部分需要运营商逐步去积累和投入，重点是实现VNF的分布式部署，微服务化，为将来实现真正的基于容器的部署打下基础。

3）MANO：如前所述，MANO是由NFVO、VNFM和VIM组成的，VNFM与VNF是强关系的（存在部分通用VNFM）、VIM与hypervisor也是强关系的，这两部分运营商目前还无力进行自主研发，所以VNFM和VIM基本也是放弃的，只有NFVO，因为与运营商OSS关系紧密，又与业务关系较大，所以大部分运营商选择NFVO的自主研发，但即使是NFVO，近期来看，也还无法直接应用自主研发成果，需要经过现网的考验和不断迭代完善，初期很可能还是采用商业化NFVO方案。

对于运营商而言，NFV的可靠性可能更重要，NFV的弹性并非想象的那么重要，如果VNF自身在架构上不能实现横向扩展（例如借助弹性负载均衡），完全依赖于NFVI的弹性（这种弹性也只是VM/容器本身资源能力的伸缩，在实际应用中只能扩展，难以缩回，而且也存在瓶颈问题），如果VNF可以进行分布式、模块化、微服务化部署，借助容器/虚机/物理机就可以实现快速的系统能力扩展。

因此运营商应着重在NFV系统的多层次、多模块之间的联动故障检测和统一自愈策略上进行研发，同时推动VNF本身架构上的革新，以更有效地利用NFVI的优势。

(2)解耦与一体化的矛盾

NFV架构相比传统的云资源池要复杂一些，由于VNF相比传统的IT和业务平台，对基础设施（NFVI）要求高很多，同时为了实现可运营和自动化，引入相比云资源池的云管平台更复杂的MANO系统（内部又可以独立为三个模块），这就带来了非常复杂的体系架构，如果要按照模块或层次解耦来部署，不同层次或模块之间有大量的需要规范的接口，对于运营商来说，选择一体化的紧耦合的NFV的厂商整体解决方案还是力推解耦，模块化组合和集成的多厂商方案，是目前最为棘手和相对难度较大的问题。

选择一体化的单厂商整体方案的好处就是可以实现快速部署，整体系统的性能、稳定性与可靠性是比较理想的，不需要进行异构厂商的互通测试与集成；不利的地方是与传统网络设备一样，存在软硬件一体化和封闭性，难以实现灵活的架构部署，不利于实现共享，与厂商存在捆绑关系，不利于竞争，会再次形成烟囱式部署，总体成本较高，也不利于自主创新以及灵活的迭代式部署升级。

选择解耦的多厂商集成方案好处是可以实现通用化、标准化、模块化、分布式部署，架构灵活，而且部分核心模块可选择进行定制与自主研发，也有利于形成竞争，降低成本，实现规模化部署；不利的地方是需要规范和标准化，周期很长，也需要大量的多厂商互通测试，需要很强的集成开发能力，部署就绪时间长，效率较低，后续的运营复杂度高，故障定位和排除较为困难，对运营商的运营能力要求较高。

对于运营商来说，最终选择肯定倾向于解耦和接口标准化，但标准化过程较长，与厂商的博弈也需要时间，再加上自主能力（研发、测试、集成）也需要时间，在实现最终目标之前会先选择过渡方案，例如厂商一体化方案（不适合作为商业化规模部署方案）、部分解耦方案（硬件与软件解耦、MANO中的NFVO解耦出来等），在试点和小规模部署过程中培育能力，逐渐实现最终的解耦目标，并且在解耦基础上逐步提升自主研发比例，增强对网络NFV化的掌控力。

这里面有两个原则一开始就要坚持：1）NFVI一开始就要坚持与已有的云资源池实现统一，尽量减少Hypervisor的类型，减少服务器定制化的类别，从集中的云管平台上增强对NFV的支持和全局的资源调度能力，实现尽可能的集约和规模化部署；2）MANO的架构需要全网统一，包括NFVO架构、VNFM架构以及VIM架构，特别是尽早明确NFVO的架构（例如采用集团NFVO+区域NFVO两层架构），明确VNFM和VIM的跨专业、跨地域部署能力和部署位置，明确已部署的云管平台与VIM架构的关系，明确已有的EMS和NMS与VNFM架构的关系。

如此，可以做到对NFV整体架构的把握和解耦的目标，再分解为阶段性目标，结合技术的演进发展，明确路线。

（3）集约与分布部署的矛盾

云计算有几大本质特征：

（1）按需分配，动态伸缩，这是云最为重要的特征，它意味着云不仅可以及时满足各种需求，而且可以动态满足（例如这个时刻需要5个虚机，下一时刻需要20个虚机，再下一时刻仅需要3个虚机，传统的IT模式几乎没办法满足这种需求），另外这种按需和动态是自动化的，不需要或很少需要人去干涉，由监控系统监控资源负载甚至用户应用负载情况，然后自动去调度资源、扩展和回收资源（而且计费也是动态的），这对于互联网/移动互联网类应用是至为重要的，而实现按需分配的前提之一是资源池需要具备一定的规模。

（2）成本优势：成本优势是云之所以大获成功的关键之一，大大降低了中小企业和个人使用强大IT能力的门槛。云之所以有成本上的巨大优势，并非简单地引入虚拟化技术就能实现的（仅仅实现了单物理机的简单共享能力），涉及到全局资源调度能力、产品模型优化（例如大部分需求2vCPU虚机即可满足，但用户不见得一开始就了解，可能会更多采用4vCPU甚至更大的虚机，成本更高，也浪费资源）、规模化经济效应、服务器高度定制化、 软件定义技术、自动化部署与运维技术、DC机房选址以及制冷电力节能技术的引入等

（3）互联网体验，云服务也是一种互联网化的IT服务。IT服务化，具备按需随选特点，具有良好可视化，使用体验最优化，这些特点主要是互联网技术发展带来的结果，为了保证用户使用体验，同时还要保证规模化效应，公有云服务商通常在DC的布局上都会费尽周章，例如AWS典型的DC架构（Region+Available Zone），既要保证有规模，还要离用户更近一些，同时更要保证HA。

从云计算的几个特征看，云计算的基础设施需要尽量集约化和规模化，以保障最大化的共享、按需提供资源以及实现低成本，但过于集约化和规模化可能无法保障用户的体验，所以需要在集约和分布两者间实现平衡，AWS在这方面基本上为行业（公有云）树立了标杆，目前大部分公有云提供商都按照AWS的云DC架构进行全球布局。

NFV的基础是NFVI，本质上是云基础设施，而NFVI的部署同样面临着集约化与分布式部署的矛盾。集约化好处是建设部署门槛较低，运营成本更低，能够集中实现冗余和灾备，网络架构较为简单，管理更为方便，但是仅适合于计算型的VAS、IT以及VNF，例如vIMS以及转控分离的控制功能等，不适合于实现接入型、宽带流量型和高转发型的网元，例如OLT、BRAS、CDN、交换机、路由器等（严格说OLT和BRAS是转发功能的NFV化，如果实现控制功能的分离后，控制功能的NFV可以实现一定的集约），这是与网络本身的特性和层次化架构相关的，涉及到用户体验以及网络架构调整的问题，成本太高（例如要增加大量的光缆，况且现有的路由器/交换机交换能力和端口带宽限制也无法满足集约带来的流量过渡汇聚）。因此，对于运营商的网络NFV，无法做到像IT、VAS资源池那样集约化，需要根据网元位置进行分层的下沉部署，例如在本地化的DC上进行部署，这将导致NFVI的资源池节点体系非常分散，带来的挑战非常巨大：

1）本地网目前并没有合适的可部署NFVI的机房，需要充分利用本地网CO机房进行DC化改造，这带来CO选址、改造的挑战（有些CO机房改造成本过高，而新建机房又没有政策条件）。

2）本地网的NFV容量较小，这就带来了大量的分布式的资源池建设问题，资源池的分裂（以及网络条件限制）无法实现共享和调度，建设成本也较高（例如每个资源池都要独立部署VIM、VNFM模块），同时每个本地网的DC都需要有容灾的部署，增加了部署成本，另外在资源的维护上压力也较大，人工成本较高。

3）各省的本地网需求和CO差异较大，这可能带来的问题是未来NFVI资源池五花八门，很难统一（例如厂商类型过多，架构封闭性，实现资源统一规划、部署和管理难度极大），如何实现一个统一架构的资源池，包括与已有资源池的架构融合，将是一个挑战。

总而言之，未来的NFV资源池部署既要考虑网络层次化架构带来的分布式部署必然性，又要充分利用云资源池集约化部署优点，充分做好业务和DC规划，通过包括转控分离技术、业务流量分离技术（例如将VOIP、ITMS等业务从MSE/BRAS中分流）等技术实现一定的集约，同时也需要从资源池的部署架构（包括冗余）和管理架构上进行统一，避免因为分布式部署带来的架构分裂和管理分散，为将来条件成熟时统一部署NFVI DCI网络以及实现统一调度创造基础条件。

（4）现网NFV与否的矛盾

NFV（network function virtualization) 顾名思义是网络功能虚拟化，个人不太喜欢“虚拟化”这个词，也许当初定义这个名词时候觉得“云化”（cloudifition）不太容易被理解，因为大部分人把“虚拟化”等同于“云化”，而“虚拟化”比较容易理解一些。

NFV概念之所以会被提出来，一个是云发展到较为成熟的阶段，一个是软件定义网络（SDN）概念的兴起，让全球运营商几乎一致地（AT&T更早开始践行）选择NFV作为网络演进的方向。NFV实际上首先就是要让网络功能能够从封闭的专有硬件中分离出来，以软件的形态（例如VNF）存在，其次就是为了能够承载各类VNF，对现有的云基础设施和管理架构进行增强和扩展（例如引入MANO，增强了网元生命周期管理以及网络服务（Network Service)的编排能力，实现自动化的网络服务管理与部署）。运营商部署NFV不外乎两个目标：

1）节省成本，这个是一个伪命题，如果认为专业化设备成本太高，NFV化因为虚拟化共享就一定能够带来成本的降低，那一定是一个误解或者被忽悠。之前有论述过，NFV除了大量的服务器（虚拟化比例要比VAS和IT更低）、昂贵的FC SAN存储、新的接入/核心交换机外，还要大量的Hypervisor License、MANO组件License、VNF License，为承载NFV而进行CO改造的成本，还有为备份、HA、容灾需要付出的软硬件成本以及网络成本等，网络NFVI的最终规模要远远大于业务平台或IT云资源池，这意味着如果要把现有网络所有网元都进行云化，要付出巨大的云化成本（新增投资，几乎没有可利旧的），对于运营商来说，由于不掌握NFV核心技术（即使投入自主研发，由于研发效率和机制问题，不一定就比购买商业软件便宜），如果为了NFV而NFV，已有未退网的网元为了实现云化比例进行迁移，很难说在成本上会有节省。有人说，针对扩容或者新建（例如提供VoLTE业务的vIMS，未来5G核心网或者NB-IOT核心网）可以先行部署NFVI，成本上有优势，但至少我目前还没有看到厂商有可信服的成本节省公式，如果将来能够实现标准化和解耦，也许通过通用化和规模化集采，可以节省一部分成本（实际上集采也是一个问题，不展开说了）。

2）快速部署，弹性伸缩，能够让运营商变得跟互联网公司一样，可以迭代式开发业务，快速升级业务，可以快速和动态满足客户需求，这是一个看起来很美的好处，但实际上运营商有没有这样的业务值得怀疑（未来规模发展的物联网或大视频业务需要动态部署或扩展IOT核心网能力、Bras能力或vCDN，可能存在一定的需求，或者宽带业务有波峰波谷需求，BRAS被NFV化后可以按需弹性伸缩，但是削峰错谷需要在同一NFVI上存在多个不同峰谷需求的业务），有人说比如VoLTE业务按原来模式需要按照1亿用户部署，现在只需要先部署100万，然后随着业务发展，自动扩展资源，快速部署VNF，就可以满足了，可以节省大量资源的闲置，但是这种情况是假设运营商的规划、建设和采购模式也跟着“NFV”化才行，否则等你需要硬件资源的时候，没有资源，那是一种什么样的“捉急”。

我不是来拆台的，只是NFV看似很美好，运营商可以转型为“玩”软件的高大上公司，但实际上所有都是要“买”的，最后能节省的可能是由于技术的引入而带来运维人员成本的降低，但运营商最不缺的就是人啊，之前有人说设备商对NFV是咬牙切齿的，NFV是会埋葬设备商的，至少目前看来，短期内NFV是设备商的新增市场，长期看，设备商依然占据着VNF License，还可以在其他市场分一杯羹，不见得会受到多大的影响（要知道传统网元是有一个退网周期的，除了移动网3G几年来4G，4G还没有渗透完就又来5G）。

当然NFV也并非一无是处，至少对于运营商来说，提供了一个“潜力”，确实在部署和升级业务上可以比之前更快（理论上可以只升级VNF软件），在理想状态下，NFVI可以借助软件实现全网的自动化部署和智能化管理，最终实现硬件通用化甚至白盒化后，可以实现成本的下降，另外也提供了自主研发的可能。而从VNF看，未来物联网和大视频时代，网元的弹性需求可能比现在要求要高得多，NFV肯定要比现在固化的网络更能满足发展需要，另外VNF外后，也提供了一定的创新空间，同时创造了网络开放的更好条件，不过这一切都需要运营商具备足够的掌控力才能真正发挥出来，否则可能是海市蜃景。

因此，对现有网络而言，并没有NFV化的急切需求和必要性，现有网络可以随着扩容或退网而逐步引入或替换为NFV技术。当然，现有网络不推进NFV，仅是新业务部署NFV的话，很难在既定时间内实现网络云化的目标，将来也面临着两套网络系统的部署和运维问题。

不过，当前NFV更重要是在于全网架构以及技术应用和发展策略的明确，而不是云化的目标，或者所谓降低成本和为了弹性（绝大部分没有真正的分钟级甚至秒级的弹性需求），要把握好节奏确实蛮有压力。

（5））统一承载与分离承载的矛盾

前面跟大家聊了NFV发展的4个矛盾，包括集约与分散部署、一体化与解耦、自主研发与采用商业软件的矛盾以及现有网络是否NFV的矛盾。今天想跟大家分享第五个矛盾(矛盾这个词可能不妥，与实际所想不符更合适）。运营商前期基本都部署了内部云资源池，用于承载业务平台和IT系统（还包括部分网管系统等），现有的业务平台和IT资源池在之前讨论的四个“矛盾”方面表现的并不突出：

1）集约或分布部署：基本是集约部署的，包括集团级的资源池以及省集约的资源池，本地网层面不再部署资源池，不过由于组织架构和技术问题，总体上仍然集约不足（集团级的资源池基本不承载省级平台），各省之间的资源池也无法共享和调度，存在一定的重复投资建设。

2）解耦或一体化：基本实现了解耦，硬件、虚拟化软件、VAS/IT系统以及云管平台实现分离，一开始目标就是实现资源和项目分离，资源池通过引入SDC(Software Defined Computing)、SDN（Software Defined Network)和SDS(Software Defined Storage)基本实现了物理资源与虚拟资源的分离，具备集中管控计算、存储和网络资源，具备按需分配和一定的弹性调度。

3）采用自主研发或商用系统：底层硬件、虚拟化软件主要采用商用系统，云管平台采用基于开源系统（CloudStack、OpenStack）的自主研发系统（确实还存在诸多问题，全网部署纳管周期很长，至今仍不尽如人意，但至少培养了一支较强的团队，机制上还需要改变，以留住人才），部分省公司引入开源的KVM系统，但规模很小，主要用于测试和非关键业务承载，最主要还是缺人，谁来维护。而业务系统/IT系统的云化迁移需要厂商配合甚至主导，部分系统需要代码修改，除了传统上采用X86服务器的非核心平台外（利用类似P2V工具可以自行迁移），运营商无法自己完成云化迁移，这个过程全网花了不小的成本。

4）云化与否：从最初的业务部门积极性不够，采用部分云化以及混合基础设施（例如物理机、小型机和虚拟化服务器共存）到后来前端很积极（甚至抢占资源），云化率几年来一直在上升，扣除部分难以云化的平台，基本都纳入云化。在这个过程中，确实存在部分为了云化而云化，但总体上至少在硬件方面有更好的利旧可能。

由于不同部门分管（历史原因）、云化需求差异，一开始运营商在业务平台（VAS）和IT的云化上是分离进行的，各自规划、建设、部署和运维各自的资源池，采用不同的架构以及技术，各自发展到一定规模后，重复建设问题开始突出，开始提出资源池要进行融合和统一承载VAS和IT平台的方案，但一开始推动过程比较慢，最终还是靠解决组织架构，让云基础设施真正从“平台”脱离出来，统一一套人马来部署和运维，在IaaS层面实现统一规划（来自不同的需求）、统一建设与部署、统一运维和管理，当然还包括要统一服务器模型、虚拟化软件模型、统一管理平台等。

目前来看，实现VAS和IT的统一只要解决了组织架构问题，后续只是调整云管理架构、调整技术模型的问题，统一资源池体系和网络架构，难度降低了很多，也会逐渐顺畅起来，实现融合承载没有技术上的门槛。

随着NFV的推进，自然而然地运营商一方面希望未来VNF与VAS、IT也可以实现统一承载，另一方面希望可以利用现有云资源池承载VNF，从而实现“利旧”。

但是由于以下原因，这种希望当前还不太现实：

1）目前NFV不要说三层解耦，就是物理资源和之上“软件”的解耦还没有解决，由于承载的是传统网络网元，目前主流的NFV方案基本由设备厂商把持，传统的IT方案厂商被边缘化。而根本的原因是VNF是由设备商来主导，设备商或忽悠或强势要求只能采用自家的虚拟化软件甚至服务器，才能保证性能和可靠性，而要推进三层解耦，需要充分的多厂商的测试和集成工作；

2）虽然说现有云资源池从技术（服务器硬件特别是网卡支持、虚拟化软件对NFV的支持）上基本具备承载计算型的VNF（典型的例如vIMS)，但现有的云管平台还需要增强NFV支持（例如巨页内存、DPDK、SR-IOV、NUMA绑定等），需要测试对各种虚拟化软件NFV特性的配置和支持能力，同时由于NFV引入所谓的MANO架构（个人认为VNFM和NFVO现阶段可以不需要单独引入或由云管平台来提供），云管平台还需要测试与NFVO以及各种厂商VNFM的对接能力，以实现VIM功能，同时还需要现网部署验证，这需要一定的时间（前提还需要云管平台支持各种厂商的Hypervisor）；

3）针对转发性能要求高的VNF（例如vBRAS、vEPC）, 网卡数量上有更高的要求，服务器模型必须更新。

4）只有部分网元（例如vEPC的控制网元，以及未来的vIMS转发面等）适合放在省集约资源池，其他大部分网元需要放到端局层面的DC上，而这个层面没有VAS和IT承载需求，属于新建的NFV资源池节点（部分DC可实现VFN和云业务的融合承载）。

5）NFVI基本上采用的都是基于KVM的商业定制版（与基于OpenStack的商业定制版VIM配合），虽然VMWare本质上承载VNF也没问题，但VMWare是IT厂商，VNF没它事，而且VMWare已经被标签为昂贵的商业软件，这带来的问题就是现有以VMWare为主的资源池未来与NFVI资源池没有共享性（虚拟化层面，在网络层面仍具备一定共享）。

综上，现有云资源池虽然可用于承载部分VNF，但未来需要新建大量专属于NFV资源池节点（或在现有云资源池中独立部署集群），新的服务器模型（可能会出新的定制化服务器），新的虚拟化软件模型，新的管理架构（可共享部分现有云管理平台功能作为VIM），VNF、VAS、IT无法统一调度承载，更多的只能在规划、建设和运维层面去统一。

=====================================

致力于云计算的应用和推广