5G“灰度发布” 远离“割接”

这个世界上只有两种通信工程师。其中，第一种通信工程师一定是在割接。

割接有多苦逼？

割接，是一场战争。割接前，反复论证、周密测试、数据备份、失败紧急回退演练等等。割接时，战战兢兢，一步一检查，一次割接步骤甚至要专门印发成一本本小册子给每一位割接成员，详细到每一个人、每一个时间点、每一个步骤、每一个命令。割接后，每个测试通过，每个指标恢复正常，都如释重负。

然而，比割接更崩溃的是回退，比回退还崩溃的是回退失败...

2016年12月，当晚割接，我在机房里守了一夜，但没想到，那晚割接失败了，凌晨5点全部倒回，可倒回时竟然又出故障了。我永远忘不了那个下班的早晨，太阳从东方冉冉升起，朝霞透过薄雾给城市披上了一件红色面纱，但我坐在车里，眼前却是一片灰蒙，没有任何色彩，仿佛世界末日来临一般。

从1G到4G，通信工程师们经历了无数次割接，搬迁割接、BSC升级割接、OMC割接、BOSS系统割接、CRM割接... 尤其是核心系统割接，对支撑，对前台，对整个公司上上下下都是一次胆战心惊的挑战，因为稍有疏忽，就会造成第二天系统无法使用，或批量用户投诉。

5G来了！

让割接不再苦逼！

众所周知，由中国移动牵头提出的SBA构架已被3GPP确认为5G核心网基础构架。SBA（Service Based Architecture），即基于服务的架构，它基于云原生（Cloud Native）设计，借鉴了IT领域的“微服务”构架。

▲5G系统服务架构

这样的构架意味着什么？

灰度发布

不要“割接”，要“灰度发布”

什么叫灰度发布？

灰度发布：是指在黑与白之间，能够平滑过渡的一种发布方式。A/B测试就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。（百度百科）

什么叫割接？

就是把就是把旧系统“割”下来，把新系统“接”上去。

我们在割接时，新版本替换就版本，都是通过批量操作，一次性的、100%的从旧版本“割接”到新版本。

这种割接方式存在很大的风险：

1）必须暂停业务进行升级（所以割接都在晚上进行）

2）一旦割接失败就意味着满盘皆输

3）若割接失败，再回退到老系统时极易出错

人总是有侥幸心理，内心里是拒绝割接失败这种事的，加之反向回退总比正向升级难，一旦割接失败，心力交瘁之时，非常容易出错。

基于云原生的构架支持A/B测试（或split testing），意味着我们不必“一次性割接”，IT领域的DevOps概念支持循序渐进的引入新版本的VNF（虚拟化网络功能）组件，先挑选少量测试用户操作试点，将少量的流量切换到新版本上，并在这个过程中持续监控性能，确保稳定之后，再进一步将其他用户切换到新版本上。如果一旦发现少量测试用户的性能异常，也可快速回退到旧版本上，可大幅降低割接风险。

▲割接 vs A/B测试

事实上，灰度发布这个概念并不新鲜，在IT领域我们经常看到灰度发布的测试版，有些APP后缀Beta、Pro字样，其实就是在进行产品的灰度发布。

云原生在IT领域的演进过程

进一步讲，像Google、亚马逊、Facebook等IT巨头早就引入了云原生IT环境。

从他们的发展过程看，主要经历了四个阶段：传统专用设备、虚拟化、云原生就绪和云原生。

传统专用设备：单体式应用程序运行于每个x86服务器，软件被设计成“紧耦合”的功能集合，这种方式无法充分利用云的灵活性和提升资源利用率。

虚拟化：由于单体式应用程序缺乏灵活性、扩展伸缩性等，不得不引入Hypervisor以确保多个单体式应用程序运行于同一个x86服务器。

云原生就绪：这个时候开发人员意识到，对于云，传统单体式应用程序不是最佳的。2011年开始出现利用云的软件开发模式，并在一年后，第一个云原生编排系统开始开发。

云原生：2015年，CNCF（Cloud Native Computing Fundation，云原生计算基金会）成立，该基金会旨在支持采用云原生IT环境。

原生云主要有几大基本特征：面向微服务架构、容器化、DevOps和动态编排。

•面向微服务构架

我们先将应用程序分为两种构架：传统单体式构架和微服务构架。

传统单体式应用程序被分解为无状态（Stateless）（即每个应用程序没有持续的数据存储能力）和松散耦合、粒度更小的“微”服务。微服务的松耦合状态使得它们可以在不同的应用环境中重复利用，可在云中自动复制。无状态（Stateless）能够平稳地应对为服务添加或移除某些实例的场景，而无需对应用程序进行重大的变更或进行配置的改动。比如，一个实例崩溃了，另一个实例可以立即替代，并且可快速生成进一步的替换。

因此，微服务构架具有很强的弹性，支持新版本快速发布，缩短上市时间。

•容器化

Container（容器）的英文直接翻译就是集装箱，它就是将集装箱的思想应用到软件打包上。

集装箱最大的成功在于其产品的标准化以及由此建立的一整套运输体系。在集装箱没有标准化之前，多地重复上下船（车）卸货，批量运输货物是一个复杂而费力的过程。集装箱标准化后，集装箱在整个运输过程中是密封的，只有到达目的地才被打开，这样就提高了运输单元在运输中的通用性和互换性，从而大大提升装卸和运输效率。

软件中容器的原理也是一样，容器具备环境隔离和可重复性，你只需要将代码打包进容器里，就可以实现在几乎所有操作系统上随时运行。

每个微服务（应用程序，进程等）都被封装在自己的容器里，以便进行隔离和部署。容器是一个轻量级的虚拟化技术，它使得应用程序可以独立运行，并可移植到不同的云基础架构中。

•DevOps

运维和开发人员共同协作发布服务（包括微服务），它创造了一种文化和环境，以快速、频繁且更可靠地构建、测试和发布服务，提高运作效率。

•动态编排

指对容器进行有效的调度和管理，以优化资源利用。容器编排系统负责管理主机资源和分配调度容器、实例化一组容器、重新调度容器（如果失败），并通过API接口集成容器，进行任务扩展等。

电信业的云原生之路

由于电信网络比IT的业务性能要求更高，且面临庞大的用户群体（一个VNF动辄几百万用户），加之容器等技术还在不断发展的过程中，因而，电信业引入云原生相对IT领域较晚。

这大概要从2012年说起。2012年10月，AT&T、英国电信、中国移动、德国电信等12家运营商联合发布NFV白皮书，并建立ETSI（欧洲通信标准协会）的NFV ISG（NFV规范组）。

NFV的核心理念是将逻辑上的网络功能从传统专用电信设备解耦，用通用的IT服务器代替传统电信硬件设备，将虚拟网络功能（VNF）运行于IT云环境，以降低网络建设和运营成本，缩短网络部署周期。

一时间NFV成为电信业热门词汇，由于背后是一批重量级的运营商支持，NFV的发展和部署也超出预期，业界相继推出了虚拟化产品。

但是，初期NFV从传统电信设备中解耦出网络功能软件是单体式构架的，这和以上我们谈到的IT领域遇到的问题是一样的，一方面，这种方式并没有从本质上改变传统电信的运行模式，新业务上线速度依然缓慢，网络依然缺乏弹性和灵活性。另一方面，在实际部署中出现来自不同厂家的“专用软件”之间存在互操作问题。

因此，VNFs迫切需要分解，通过软件模块化、轻量化的方式来提升应用开发的整体敏捷性和弹性，并通过开放API接口和开源来简化集成过程，从而加速创新和新业务上线，适应瞬息万变的市场环境。

同时，2012年提出的NFV技术概念由于时代原因局限于4G时代的思维。

4G和5G有一个本质的区别：4G更偏向于向内关注网络本身，以更高速、高效率的移动通信为目标；而5G更偏向于向外延伸的应用和商业模式，它视网络为使能者，为驱动力。

出发点和目的都不一样，5G要Think Big，更关注应用落地和创新。

因此，5年后，当行业处于5G风口之时，一份由23家领先运营商支持的新版NFV白皮书《NFV White Paper 5G》发布了。

与2012版的白皮书不同，这份NFV 5G白皮书除了关注网络虚拟化本身，更关注5G应用，更强调了Cloud Native（云原生）概念，认为Cloud Native设计原则和基于cloud-friendly的授权模式至关重要。

所以我们今天看到，3GPP已确认5G核心网引入云原生，面向微服务构架。

事实上，在关于云原生、微服务、DevOps的讨论中，同时出镜的不仅仅是灰度发布、A/B测试，还有自动运维、持续集成/持续开发等，这些已经在现场试验和现网部署中得到验证。目前，已经有一些运营商已经在核心网部署了云原生解决方案。

5G要面向多样化和不确定的新用例，云原生来助力网络灵活组装、更新业务应用，提升效率，缩短业务上线时间，并走向开源，释放创新动力。

以后核心网割接不再苦逼，不用熬夜干活，不用提心吊胆，采用灰度发布，大白天妥妥的就把事干了。