从虚拟化到云原生——电信网络转型能学到些什么

近年来，PaaS热、容器热、Kubernetes热、微服务热、DevOps热，这么多的热汇聚到一起，一举将云原生（Cloud Native）推至IT时尚界的宠儿。有的人将其奉为圭臬，认为云原生是云计算的未来。也有人称之为“炒作”，认为它会逐渐失去牵引力直至消失。

但无论怎样，云原生的热度依然在持续升温。根据 CNCF 统计数据，2018 年，云原生技术采用率增长了 200％，全球有近三分之一的企业正在运营50多个容器，运营 50 至 249 个容器的企业占比也超过 25%。

从容器说起：分布式的进化

云原生的火热离不开容器技术的相辅相成。当容器于 2008 年首次推出时，VM分布式架构还是云服务商和内部数据中心寻求优化DC资产的最佳选择。VM 确实已经足够灵活，也正是这种极尽“渲染”仿真方式使得硬件性能并不能高效利用，如每个 VM 都需要在整个层（管理程序）中模拟完全可操作的系统，并大幅占用物理 CPU 资源。即使采用 Intel VT-x 和 AMD-V 等技术，VM的性能亦远不如裸机。

此时，容器共享内核的方式显得尤为高效。来自不同镜像的进程可以在同一空间中运行，而内核负责保证它们之间的正确隔离。由于容器占用内存少，又不存在硬件仿真层，因此一经提出就迅速走红。

然而随着容器广泛进入生产领域，人们很快意识到一个事实，尽管在同一台计算机上部署容器很容易，但它在高可用性管理、灾难恢复和可伸缩性方面仍存在不少问题，优秀的编排层才是在生产中大规模部署容器的必要前提。这些问题催生了各类容器编排系统软件，它们负责进行集群操作，协调调度、内存分配、安全性和网络，以确保所有镜像按规定工作。这些软件也在过去几年间有各自的用武之地。

经过激烈竞争， 2014年开源的 Kubernetes项目力克Docker Swarm 和 Apache Mesos，成了容器编排事实的标准。它背靠 Google 多年实践，实现了对即时部署、弹性伸缩、健康检查与高可用性（HA）系统的全部覆盖，能为生产完整生命周期保驾护航。2015年7月，由Google牵头并联合linux基金会以及一大票牛掰的技术公司（IBM、microsoft、redhat等等）成立了CNCF（Cloud Native Computing Foundation），并贡献了Kubernetes源代码。容器技术、可持续交付、编排系统等开源生态的持续推动下，云原生（Cloud Native）迅速走红，容器也成为了云原生的最佳载体。

从云计算到云原生，如何安放我的应用

云原生热与以往众多的技术热潮不同，因为它是由业务需求驱动的，相对于技术创新驱动而言，前者显然更具活力。自从云的概念开始普及，许多公司都部署了实施云化的策略，纷纷搭建起云平台，希望完成传统应用到云端的迁移，然而在上云过程中不可避免地会遇到一些难题，效率并没有变得奇高，故障也没有迅速定位。在诉求和现实的频繁碰撞下，无论是公有云还是私有云厂商，推动技术发展的每一个环节都在做着努力。自2015年由Pivotal的MattStine首次系统性提出后，云原生的火苗就开始越燃越旺。我们不去纠结起初创造这个词汇是否只是包装，但无疑这种解决问题的思想引起了业界大量公司的共鸣。

我们看看Pivotal的定义，云原生需要符合这几个特征：12因素应用、微服务、自服务敏捷架构、基于API的协作、抗脆弱性。CNCF也给出了云原生应用三大特征：容器化封装、动态管理、面向微服务。这些定义都对企业高效上云提供了思路。

这时我们需要重新思考一番云应该做什么。云其实一直在进化，不同于以往把原先在物理服务器上跑的东西放到虚拟机里跑，真正的云化不仅和基础设施和平台相关，应用也要做出改变——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正地发挥云的弹性、动态调度、自动伸缩……。很多新技术在这个进程中都扮演着重要的角色，如容器技术、微服务等。

正如技术是为解决问题而生的，技术创新是为更好的解决问题而发展的。CNCF官方云：云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。由此观之云原生不是一项具体的技术，它提出了一种用技术解决问题的方法论。这里面涉及的容器、微服务、动态管理都是顺应云计算发展的技术产物，如何高效、协调地应用好这些技术以期达到更优的体验，是云原生的使命。

云原生的产生来自于云基础设施进化，其关注的就是架构的设计和对云基础设施的利用。云原生应用最大的特点就是可以迅速部署新业务。在企业里，提供新的应用程序环境及部署软件新版本所需的时间通常以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险，因为犯错及改错也需要花费同样的时间成本，云原生竞争优势就由此产生。下图就对比了传统应用开发与云原生应用开发。

2018年，CNCF对云原生给出了具体定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

上面提到的技术只是云原生技术的冰山一角，无论是开源还是商业产品，优秀的组件和解决方案数不胜数。下图是CNCF官方提供的一张项目全景图，仍在不断更新中。

先行者OTT，掀起云原生的浪潮

“云原生技术已经慢慢地融入了大众衣食住行。”这是阿里云研究员马涛在KubeCon 2018峰会上的发表的观点。

对于新技术、新模式的尝试，互联网厂商往往是最具激情的。从技术的尝试到大规模的应用，从架构的优化到革新，从最初的降本增效，到更好的服务用户，互联网厂商发展与云技术的进化相辅相成。

在经历了前期技术积累，各大厂都推出了各自的容器基础设施。国外的Google的GKE、微软的Azure AKS、AWS的Fargate和EKS、Pivotal 与 VMware 联合推出PKS、Rancher联合Ubuntu推出的RKE，国内的华为云、腾讯云、阿里云等都已推出了公有云上的Kuberentes服务，Kubernetes已经成为公有云的容器部署的标配，私有云领域也有众多厂商在做基于Kubernetes的PaaS平台。众多企业也通过并购填充弹药，IBM、红帽、CoreOS的连环收购，VMware收购 Heptio。

另外，云管理服务商(Cloud MSP)们正努力成为云原生的先行者，不断尝试并挖掘云原生的精髓所在，突破更多的云原生部署壁垒，以帮助企业快速构建云原生应用，实现微服务架构改造以及DevOps落地。埃森哲通过AWS云服务，它提供了一个集中化的仪表板和管理控制平台，用于云计算解决方案的全面管理和自动化。博思艾伦咨询公司已经成为美国联邦政府最大的咨询服务提供商，它主要提供云计算、移动和数字战略，网络内容管理和其他服务，以及BAH和DevOps支持。IBM公司为BlueMix云基础设备提供云服务，为关键任务工作负载提供完全托管服务，与IT基础架构库（ITIL）兼容的解决方案。关键任务型应用程序可以在IBM应用程序以及SAP和Oracle上开发和部署。

云原生浪潮下，电信网络如何转型

近年来，电信业面临着越来越苛刻的市场条件和日益激烈的竞争。一方面，客户需求不断发展即寻求娱乐，创新服务和简单性。电信客户既想要确切地知道他们支付的费用，也想自己管理账户。另一方面，顶级（OTT）运营商现在可以提供以前属于电信业务服务的替代品，并且他们正在攫取越来越多的通信服务收入。目前，OTT已经满足并丰富了信息服务（通过微信、QQ、WhatsApp、Snapchat、FB Messenger和iMessage等等），通话服务（微信、Skype、Viber和FaceTime），而且还丰富的视频应用和直播服务。以往几乎处于垄断的网络连接也不得不面临竞争与合作的博弈。

在步步紧逼下，电信运营商面临着业务模式转变的巨大压力。电信业未来将是什么样子？电信公司未来是管道还是更贴近用户？运营商这只大象似乎仍然没找到合适的落脚点。

无论是前些年大火的SDN、NFV还是近些年热议的网络软化，网络的软件化、可编程化趋势已经成为不争的事实。同时给运营商带来了机遇也带来了极大的挑战，这不仅是技术的升级换代，也是企业的全面转型和变革。网络如何服务应用，应用如何使用网络，这是非常有趣的议题。电信运营商作为拥有核心鱼塘的大佬，在基础网络上革新有着太多的机会。不具备OTT厂商般的强自主研发能力，大量运营商如何走好这步棋显得尤为重要。围绕业务和底层网络架构进行云原生的迁移有很大的战略意义。

电信网络向云原生转型有哪些好处？

如何创造更多的利润是摆在电信公司面前的难题。最理想的当然是以低成本即时向最终客户提供高质量的可重复服务。云原生应用的出现，可以提供一个不错的解法。

• 更快的部署。云原生软件作为容器部署，这意味着用户可以独立扩展，升级和部署它们。用户只需为部署选择最少的资源，而不是部署整个应用程序，这样可以减少时间并有助于保持性能。
• 效率更高。与基于虚拟机的SW相比，云原生应用程序消耗的资源减少了40％。
• 更高的弹性。如果检测到故障，云原生应用程序处理可以立即从一个数据中心无缝地移动到另一个数据中心，而不会中断任何服务。
• 极其灵活。云原生应用程序支持自动扩展，允许提供商更快地测试新服务，快速扩展。

由于这些技术优势，云原生的商业利益比比皆是：缩短获利时间，降低业务风险，优越的创新因素，更快的服务交付，更大的客户粘性，增加收入流。

电信如何向云原生过渡？

电信网络转型有三个不得不注意的方面
1）5G大趋势
5G网络逻辑架构中，融合了SDN/NFV技术、思想，这关系5G的业务是否可以灵活开展、是否可以实现海量创新。中国、美国、日本、韩国、欧洲等国家计划将在2020年前后实现5G的正式商用，因此，5G商用在即，将倒逼电信运营商加快网络架构重构。进行5G技术试验，利用5G低频核心频段，建成区域性5G连续覆盖示范网，具备5G规模商用能力，同时兼顾4G网络性能提升，为2020年后4G向5G演进做好准备，这都是目前运营商的动作。
2）网络架构DC化
近些年运营商关注的CORD也是适应网络架构演进提前布局DC基础资源。随着网络加速演进及数据中心的投入使用，网元部署方式较目前会发生巨大变化，控制面将逐步集中全省数据中心/通信机房，媒体面逐步下沉到本地数据中心/通信机房以及核心汇聚机房，机房资源需提前储备以适应网络架构的变化。
3）IT架构转型。
IT架构转型要定位于企业级服务，通过资源整合，实现完全适配、敏捷开发、智能化运营，最终形成“共享IaaS、厚PaaS、薄应用”的全云化跨域融合架构，全面提升云平台、大数据平台、通信开放平台等内外部服务支撑能力。

CNCF与LFN合作发起了CNF（Cloud Native Network Function）项目就是一次大的尝试，随着网络不断发展以支持下一代服务和应用程序，云原生架构可扩展性，自动化和弹性的特性表现出极大的优势。与传统VNF（例如，封装在虚拟机（VM）中的网络功能，而该虚拟机是运行在OpenStack或VMware上的虚拟化环境中）相比，CNF（在公共，私有或混合云环境中在Kubernetes上运行的网络功能）可以更轻，更快地实例化。基于容器的流程也更容易扩展，链接，修复，移动和备份。

挑战依旧，道阻且长

ONAP项目的发展对于思考网络转型有很多启示，ONAP首个版本，代表了网络架构2.0：它运行在VM中。ONAP即将发布的版本将进入网络架构3.0阶段：它运行在Kubernetes上，适用于任何公共云，私有云或混合云。也可以从这个项目出发梳理其中的一些挑战。
1）这期间会涉及很多项目间的协作，包括OPNFV的容器化支持，跨云持续集成CI，Istio，网络服务网格（解决Kubernetes中复杂的L2 / L3用例的新方法，使用现有的Kubernetes网络模型很难解决），Ligato（提供用于开发云原生VNF的平台和代码示例。它包括用于矢量数据包处理的VNF代理（FD.io）和用于拼接虚拟和物理网络的服务功能链（SFC）控制器。），
2）网络业务的低延时和高带宽为底层实现带来了极高的要求，虚机为单元的架构我们可以通过硬件设备的介入满足需求，而容器化的环境一切都是新的问题，必须要借助DPDK或SR-IOV的方式达到高性能。
3）容器化的便捷灵活也带来了新的问题，直接访问用户控件ABI会带来安全性和稳定性的风险，怎样做好工作负载的平衡，怎样防止安全隐患都是需要思考的。
4）在NFV还未大范围普及的情况下，如何做好物理设备到云原生、虚机到云原生的过度显得尤为重要。

正如LFN执行主席Joshipura所讲，“对于运营商而言云原生不是万金油”，我们需要更好的明白云原生是什么，预见性的发现问题，用好它才是关键。其实网络转型知识电信运营商在转型路上的一个方面，为了在通往数字转型的道路上迈出更多的步伐，他们还需要改变思维方式，以适应新的场景和挑战。

运营商进入云端不仅仅和OPEX和CAPEX有关，还涉及各方之间分担责任的价值。电信公司和OTT公司、企业和信息技术公司可以更密切地合作，共同征服市场。对于电信业来说，云原生意味着业务灵活性、弹性、可伸缩性、配置模式的可重用性、业务和IT扩展的标准化和开放性。借助全新的开放式数字架构，最终可以从传统的CSP平稳扩展到面向未来的DSP。

参考
http://www.kokojia.com/article/32436.html
https://www.telecomtechoutlook.com/news/significance-of-cloud-native-service-in-telecom-industry-nwid-100.html
https://amartus.com/3-questions-about-telco-journey-to-cloud-native-with-answers/
https://mp.weixin.qq.com/s/szXfUxF6P88ZZw06BuSDtA