這個世界上只有兩種通信工程師。其中，第一種通信工程師一定是在割接。

割接有多苦逼？

割接，是一場戰(zhàn)爭。割接前，反復論證、周密測試、數(shù)據(jù)備份、失敗緊急回退演練等等。割接時，戰(zhàn)戰(zhàn)兢兢，一步一檢查，一次割接步驟甚至要專門印發(fā)成一本本小冊子給每一位割接成員，詳細到每一個人、每一個時間點、每一個步驟、每一個命令。割接后，每個測試通過，每個指標恢復正常，都如釋重負。

然而，比割接更崩潰的是回退，比回退還崩潰的是回退失敗...

2016年12月，當晚割接，我在機房里守了一夜，但沒想到，那晚割接失敗了，凌晨5點全部倒回，可倒回時竟然又出故障了。我永遠忘不了那個下班的早晨，太陽從東方冉冉升起，朝霞透過薄霧給城市披上了一件紅色面紗，但我坐在車里，眼前卻是一片灰蒙，沒有任何色彩，仿佛世界末日來臨一般。

從1G到4G，通信工程師們經(jīng)歷了無數(shù)次割接，搬遷割接、BSC升級割接、OMC割接、BOSS系統(tǒng)割接、CRM割接... 尤其是核心系統(tǒng)割接，對支撐，對前臺，對整個公司上上下下都是一次膽戰(zhàn)心驚的挑戰(zhàn)，因為稍有疏忽，就會造成第二天系統(tǒng)無法使用，或批量用戶投訴。

5G來了！

讓割接不再苦逼！

眾所周知，由中國移動牽頭提出的SBA構架已被3GPP確認為5G核心網(wǎng)基礎構架。SBA（Service Based Architecture），即基于服務的架構，它基于云原生（Cloud Native）設計，借鑒了IT領域的“微服務”構架。

▲5G系統(tǒng)服務架構

這樣的構架意味著什么？

灰度發(fā)布

不要“割接”，要“灰度發(fā)布”

什么叫灰度發(fā)布？

灰度發(fā)布：是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。A/B測試就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。（百度百科）

什么叫割接？

就是把就是把舊系統(tǒng)“割”下來，把新系統(tǒng)“接”上去。

我們在割接時，新版本替換就版本，都是通過批量操作，一次性的、100%的從舊版本“割接”到新版本。

這種割接方式存在很大的風險：

1）必須暫停業(yè)務進行升級（所以割接都在晚上進行）

2）一旦割接失敗就意味著滿盤皆輸

3）若割接失敗，再回退到老系統(tǒng)時極易出錯

人總是有僥幸心理，內(nèi)心里是拒絕割接失敗這種事的，加之反向回退總比正向升級難，一旦割接失敗，心力交瘁之時，非常容易出錯。

基于云原生的構架支持A/B測試（或split testing），意味著我們不必“一次性割接”，IT領域的DevOps概念支持循序漸進的引入新版本的VNF（虛擬化網(wǎng)絡功能）組件，先挑選少量測試用戶操作試點，將少量的流量切換到新版本上，并在這個過程中持續(xù)監(jiān)控性能，確保穩(wěn)定之后，再進一步將其他用戶切換到新版本上。如果一旦發(fā)現(xiàn)少量測試用戶的性能異常，也可快速回退到舊版本上，可大幅降低割接風險。

▲割接 vs A/B測試

事實上，灰度發(fā)布這個概念并不新鮮，在IT領域我們經(jīng)常看到灰度發(fā)布的測試版，有些APP后綴Beta、Pro字樣，其實就是在進行產(chǎn)品的灰度發(fā)布。

云原生在IT領域的演進過程

進一步講，像Google、亞馬遜、Facebook等IT巨頭早就引入了云原生IT環(huán)境。

從他們的發(fā)展過程看，主要經(jīng)歷了四個階段：傳統(tǒng)專用設備、虛擬化、云原生就緒和云原生。

傳統(tǒng)專用設備：單體式應用程序運行于每個x86服務器，軟件被設計成“緊耦合”的功能集合，這種方式無法充分利用云的靈活性和提升資源利用率。

虛擬化：由于單體式應用程序缺乏靈活性、擴展伸縮性等，不得不引入Hypervisor以確保多個單體式應用程序運行于同一個x86服務器。

云原生就緒：這個時候開發(fā)人員意識到，對于云，傳統(tǒng)單體式應用程序不是最佳的。2011年開始出現(xiàn)利用云的軟件開發(fā)模式，并在一年后，第一個云原生編排系統(tǒng)開始開發(fā)。

云原生：2015年，CNCF（Cloud Native Computing Fundation，云原生計算基金會）成立，該基金會旨在支持采用云原生IT環(huán)境。

原生云主要有幾大基本特征：面向微服務架構、容器化、DevOps和動態(tài)編排。

?面向微服務構架

我們先將應用程序分為兩種構架：傳統(tǒng)單體式構架和微服務構架。

傳統(tǒng)單體式應用程序被分解為無狀態(tài)（Stateless）（即每個應用程序沒有持續(xù)的數(shù)據(jù)存儲能力）和松散耦合、粒度更小的“微”服務。微服務的松耦合狀態(tài)使得它們可以在不同的應用環(huán)境中重復利用，可在云中自動復制。無狀態(tài)（Stateless）能夠平穩(wěn)地應對為服務添加或移除某些實例的場景，而無需對應用程序進行重大的變更或進行配置的改動。比如，一個實例崩潰了，另一個實例可以立即替代，并且可快速生成進一步的替換。

因此，微服務構架具有很強的彈性，支持新版本快速發(fā)布，縮短上市時間。

?容器化

Container（容器）的英文直接翻譯就是集裝箱，它就是將集裝箱的思想應用到軟件打包上。

集裝箱最大的成功在于其產(chǎn)品的標準化以及由此建立的一整套運輸體系。在集裝箱沒有標準化之前，多地重復上下船（車）卸貨，批量運輸貨物是一個復雜而費力的過程。集裝箱標準化后，集裝箱在整個運輸過程中是密封的，只有到達目的地才被打開，這樣就提高了運輸單元在運輸中的通用性和互換性，從而大大提升裝卸和運輸效率。

軟件中容器的原理也是一樣，容器具備環(huán)境隔離和可重復性，你只需要將代碼打包進容器里，就可以實現(xiàn)在幾乎所有操作系統(tǒng)上隨時運行。

每個微服務（應用程序，進程等）都被封裝在自己的容器里，以便進行隔離和部署。容器是一個輕量級的虛擬化技術，它使得應用程序可以獨立運行，并可移植到不同的云基礎架構中。

?DevOps

運維和開發(fā)人員共同協(xié)作發(fā)布服務（包括微服務），它創(chuàng)造了一種文化和環(huán)境，以快速、頻繁且更可靠地構建、測試和發(fā)布服務，提高運作效率。

?動態(tài)編排

指對容器進行有效的調(diào)度和管理，以優(yōu)化資源利用。容器編排系統(tǒng)負責管理主機資源和分配調(diào)度容器、實例化一組容器、重新調(diào)度容器（如果失?。?，并通過API接口集成容器，進行任務擴展等。

電信業(yè)的云原生之路

由于電信網(wǎng)絡比IT的業(yè)務性能要求更高，且面臨龐大的用戶群體（一個VNF動輒幾百萬用戶），加之容器等技術還在不斷發(fā)展的過程中，因而，電信業(yè)引入云原生相對IT領域較晚。

這大概要從2012年說起。2012年10月，AT&T、英國電信、中國移動、德國電信等12家運營商聯(lián)合發(fā)布NFV白皮書，并建立ETSI（歐洲通信標準協(xié)會）的NFV ISG（NFV規(guī)范組）。

NFV的核心理念是將邏輯上的網(wǎng)絡功能從傳統(tǒng)專用電信設備解耦，用通用的IT服務器代替?zhèn)鹘y(tǒng)電信硬件設備，將虛擬網(wǎng)絡功能（VNF）運行于IT云環(huán)境，以降低網(wǎng)絡建設和運營成本，縮短網(wǎng)絡部署周期。

一時間NFV成為電信業(yè)熱門詞匯，由于背后是一批重量級的運營商支持，NFV的發(fā)展和部署也超出預期，業(yè)界相繼推出了虛擬化產(chǎn)品。

但是，初期NFV從傳統(tǒng)電信設備中解耦出網(wǎng)絡功能軟件是單體式構架的，這和以上我們談到的IT領域遇到的問題是一樣的，一方面，這種方式并沒有從本質(zhì)上改變傳統(tǒng)電信的運行模式，新業(yè)務上線速度依然緩慢，網(wǎng)絡依然缺乏彈性和靈活性。另一方面，在實際部署中出現(xiàn)來自不同廠家的“專用軟件”之間存在互操作問題。

因此，VNFs迫切需要分解，通過軟件模塊化、輕量化的方式來提升應用開發(fā)的整體敏捷性和彈性，并通過開放API接口和開源來簡化集成過程，從而加速創(chuàng)新和新業(yè)務上線，適應瞬息萬變的市場環(huán)境。

同時，2012年提出的NFV技術概念由于時代原因局限于4G時代的思維。

4G和5G有一個本質(zhì)的區(qū)別：4G更偏向于向內(nèi)關注網(wǎng)絡本身，以更高速、高效率的移動通信為目標；而5G更偏向于向外延伸的應用和商業(yè)模式，它視網(wǎng)絡為使能者，為驅(qū)動力。

出發(fā)點和目的都不一樣，5G要Think Big，更關注應用落地和創(chuàng)新。

因此，5年后，當行業(yè)處于5G風口之時，一份由23家領先運營商支持的新版NFV白皮書《NFV White Paper 5G》發(fā)布了。

與2012版的白皮書不同，這份NFV 5G白皮書除了關注網(wǎng)絡虛擬化本身，更關注5G應用，更強調(diào)了Cloud Native（云原生）概念，認為Cloud Native設計原則和基于cloud-friendly的授權模式至關重要。

所以我們今天看到，3GPP已確認5G核心網(wǎng)引入云原生，面向微服務構架。

事實上，在關于云原生、微服務、DevOps的討論中，同時出鏡的不僅僅是灰度發(fā)布、A/B測試，還有自動運維、持續(xù)集成/持續(xù)開發(fā)等，這些已經(jīng)在現(xiàn)場試驗和現(xiàn)網(wǎng)部署中得到驗證。目前，已經(jīng)有一些運營商已經(jīng)在核心網(wǎng)部署了云原生解決方案。

5G要面向多樣化和不確定的新用例，云原生來助力網(wǎng)絡靈活組裝、更新業(yè)務應用，提升效率，縮短業(yè)務上線時間，并走向開源，釋放創(chuàng)新動力。

以后核心網(wǎng)割接不再苦逼，不用熬夜干活，不用提心吊膽，采用灰度發(fā)布，大白天妥妥的就把事干了。