凌晨三點、熬夜、數據備份、戰戰兢兢、一步一檢查、業務中斷、測試驗證、緊急回退、大BOSS親自到場…這是通信工程師們熟悉的割接場景。
每一次軟件版本升級，尤其是核心網，牽一髮而動全身，錯一處而毀全網，對於網絡運維是一件非常痛苦的事。
同樣是軟件升級，電信業為什麼這麼難，而互聯網巨頭們卻輕輕鬆鬆就實現了呢？
亞馬遜每小時要部署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。
通信路上，一起走！