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

割接有多苦逼？

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

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

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要面向多樣化和不確定的新用例，云原生來助力網絡靈活組裝、更新業務應用，提升效率，縮短業務上線時間，并走向開源，釋放創新動力。

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