凌晨三點、熬夜、數據備份、戰戰兢兢、一步一檢查、業務中斷、測試驗證、緊急回退、大BOSS親自到場…這是通信工程師們熟悉的割接場景。

[[327785]]

每一次軟件版本升級，尤其是核心網，牽一發而動全身，錯一處而毀全網，對于網絡運維是一件非常痛苦的事。

同樣是軟件升級，電信業為什么這么難，而互聯網巨頭們卻輕輕松松就實現了呢?

亞馬遜每小時要部署1萬個軟件，谷歌每月要更改一半源代碼，微信版本升級了N次，為什么他們能在用戶幾乎無感知下頻繁的進行軟件升級?

進入5G時代，隨著高清直播、VR/AR、云游戲、工業控制、無人機、自動駕駛、遠程醫療等各種眼花繚亂的5G新應用興起，業務需求之多、變化之快超出了以往2/3/4G任何一個時代，這不但要求網絡功能可根據業務需求快速升級，還要求業務能快速試錯。

面對5G時代的業務需求，電信業能不能像互聯網巨頭那樣輕松、頻繁的進行軟件升級呢?

可以。

這需要灰度升級。

灰度升級，也叫灰度發布，是指在黑與白之間，能夠平滑過渡的一種發布方式。在其上可以進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。灰度發布開始到結束期間的這一段時間，稱為灰度期。

灰度發布通過小粒度快速試錯來降低業務變更風險，已成為互聯網行業業務上線發布的基礎能力之一。那電信業的灰度發布如何實現呢?

在面向5G演進的核心網網絡中，華為進一步基于Cloud Native等概念方法，將電信業務特點與IT先進理念完美結合，打造了業界唯一的5G核心網灰度升級方案，可助力5G業務敏捷可靠上線，并已成功實現業界首商用落地。

以下就以華為灰度升級方案為例，來看一看它是如何實現的?

軟件架構微服務，讓發布升級小快靈

說到微服務，先來簡單了解一下網絡云化的演進歷程。

如上圖，網絡云化經歷了從網絡功能虛擬化(NFV)到云原生(Cloud Native)的演進歷程，總的來說就是“分解”、“再分解”的過程。

NFV將軟硬件一體的傳統專用網絡設備解耦為軟件(VNF)和通用硬件，網絡功能軟件不再受專用硬件限制，可靈活部署于通用硬件之上，從而讓運營商通過軟件升級即可推出新功能和新服務。

可這還不夠，脫離了專用硬件的VNF是大顆粒的電信軟件包，非常龐大、復雜，動輒涉及數百萬行軟件代碼，這意味著從軟件開發到發布、測試整個過程工作量巨大，估計要耗費一年的時間，無法敏捷響應快速變化的5G業務需求。

怎么辦?那就基于云原生的設計原則，將大顆粒的VNF進一步分解為多個小顆粒的微服務，比如接入管理微服務、對話管理微服務、數據庫管理微服務、接口管理微服務等。

微服務不僅顆粒小，且具有獨立的生命周期管理，可以實現更細粒度的軟件開發、發布、測試和升級，這就提升了運營敏捷性，可加速創新和新業務上線，適應瞬息萬變的市場業務變化。

如果把傳統的電信軟件比作雕版印刷，單個漢字錯誤則導致整版廢棄，耗時費力;那么，微服務則完全顛覆了傳統軟件架構，就像活字印刷一樣，個體錯誤不會導致整版返工，效率呈指數級提升。

華為灰度升級方案正是基于軟件微服務架構，將大顆粒的軟件包分解成相互獨立的小軟件模塊，以微服務的方式進行版本的開發，測試和發布，每個微服務有自己獨立的版本號，升級時自動判斷源版本和目標版本中每個微服務的版本號，只升級有變化的微服務，這樣即可實現小快靈的增量軟件發布。

周邊設備無感知，大白天也可升級操作

微服務解決了電信軟件過于龐大、復雜的問題，但要讓網絡功能更具彈性和魯棒性，還需無狀態設計和軟件三層解耦。

注意，這里的三層解耦架構不是指NFV的硬件層、虛擬化層和VNF層“三層解耦”，而是將軟件分為無狀態的三層架構。

眾所周知，傳統電信網元會一直保存相關UE的上下文信息，以確保連接不中斷，稱為有狀態。這種有狀態設計是電信軟件在虛擬機/容器之間靈活遷移的羈絆。

為此，行業參考IT軟件的無狀態設計，將上下文信息與服務軟件分離，并組成獨立的狀態數據庫層，從而使得服務處理軟件(VNF組件)成為敏捷、彈性的無狀態服務處理層。

同時，再通過接口層的獨立的負載均衡軟件模塊，可有效、快速的均衡服務處理軟件之間的負載，以支撐整個系統的大吞吐量。

這就將電信軟件分為了三層：數據層、服務處理層和負載均衡層。

華為灰度升級解決方案正是基于無狀態和軟件三層解耦設計的。

在傳統有狀態下，電信軟件的版本發布上線是排他性的，同一時間只能存在一個軟件版本，而且升級過程要想做到業務無損，首先要做的就是花費大量時間將待升級設備上的用戶遷移到Pool內其他設備上，需要評估這些在網設備的軟硬件資源，業務模型等，同時針對周邊無線，數通等設備進行相關的配置聯動修改，牽一發動全身。如果無法采用Pool方式遷移用戶，采用直接升級方式，必須在夜間進行操作，會導致業務中斷30分鐘以上，無法實現業務無損。

而華為灰度升級方案打破了非黑即白的軟件版本發布規則，基于軟件三層解耦及無狀態設計原則，實現多個版本會話的數據兼容，多版本服務或微服務實例共存，并通過負載均衡的智能業務分發能力實現外部網絡設備無感知。

系統內可同時存在兩個軟件版本，通過逐步滾動升級的方式，遷移至最終目標版本，無需提前準備用戶遷移設備，無需關聯修改無線，數通等設備，實現不分時段的全天候升級操作，業務“0”中斷。

用戶遷移分批次，業務變更低風險

傳統電信軟件版本升級完成后，所有用戶就不得不接受新版本的考驗，一旦出現問題，所有用戶業務受損，損失無法估量。因此用戶在版本間的遷移不應該是一蹴而就的，灰度升級場景下，系統支持在新版本上進行業務撥測，減少或避免測試床測試。使用測試用戶進行已有特性和新特性的測試。當撥測發現問題后，可進行回退操作。回退時僅刪除撥測用戶，對其它用戶無影響。支持小粒度試錯遷移，支持分批次遷移。第一批次可遷移少量用戶，以驗證遷移過程的正確性。有問題可回退，只影響該部分用戶。后續批次也可新舊版本長期共存，以便觀察業務，無問題再進行下一批次遷移，進一步提高升級過程的可靠性。

就這樣，通過灰度發布，既解決了傳統升級割接難的問題，降低業務變更風險，也讓網絡能敏捷、健壯的應對多樣化和快速變化的5G新業務，進一步促進5G行業數字化，實現小步快跑上5G。