5G 融合計費系統架構設計與實現(一)

　　隨著5G商用臨近，5G的各個子系統也在加緊研發除錯，本人有興全程參與5G中的融合計費系統(CCS)的設計、開發、聯調工作。接下來將用幾篇文章介紹我們在CCS實現過程遇到的挑戰與架構設計的考量。相信這些寶貴的經驗可以適用於更廣的軟體系統，免於重複地陷入軟體開發的焦油坑。

　　5G系統由3Gpp定製統一的架構和協議規範，這也是電信行業一直以來通行的作法。不同的是，5G以前的規範3Gpp總是喜歡獨樹一幟，比如最出名的DCC(Diameter Credit Control)協議。雖然二進位制的格式封裝可以帶來極佳的效能，但這個協議應用的範圍也十分有限，僅限於電信行業。

　　5G規範從一開始，3Gpp就一改以往的風格，極力與目前主流的技術進行匹配，甚至不惜重構整個通訊系統。接下來我們會聽到很多熟悉的詞彙，包括：微服務、註冊與發現、Http2、JSON、RESTFul、容器化、微服務編排等等。沒錯，新5G系統在盡一切可能擁抱最新的技術潮流。正由於這個原因，在設計新的5G CCS時，我們發現以前的技術儲備全都用上了。這對於一個新系統來說極大地降低了原始開發的風險，在真正動手寫程式碼之前，我們就已經知道專案一定會成功。這點對於新系統的研發至關重要！

　　一切從微服務架構說起……在微服務架構興起前，大部分應用軟體系統都採用單體應用架構。如下圖所示，單體應用有他的優勢——簡單。但也有他的缺點，下面這段引自Introduction to Microservices，作者 Chris Richardson。

"邁向單體應用的地獄，不幸的是，這個簡單的方法有巨大的限制。成功的應用會隨著時間推進，變得越來越大。在每次需求更改或者功能增加時，你的開發團隊會實現更多的業務功能，這意味要增加很多行程式碼。在幾年後，你的簡單的應用將會成長為一個巨大的單體應用。為了提供一個極其簡單的例子，我（指作者）最近和一個開發者進行了交流，這個開發者正在寫一個工具來分析他們的應用使用的JAR彼此之間的依賴，但是這個應用竟然有數以百萬行的程式碼，我確信一定很多的開發者經過很多年的辛苦努力才創造出來了這樣的巨無霸。

一旦你的應用成為一個巨大的、複雜的單體應用，你的開發團隊一定會陷入痛苦的泥淖不能自拔，任何對於敏捷開發和交付的嘗試最終都會陷入掙扎之中。一個主要的問題是這個應用過於複雜了。它太大以至於對於任何一個開發者都無法完全理解。結果就是，修復bug和正確地實現新功能變得非常困難，並且會消耗大量的時間。更重要的是，這將會趨向於一個向下的螺旋。如果程式碼庫理解起來很困難，那麼也就不會給出恰當的改善方案。你最終會得到一個巨大的、難以理解的big ball of mud."

　　單體應用給我帶來更直觀的感受是當系統規模達到一定程度時，維護這個系統不斷更新、接受新需求是一個惡夢。首先系統的穩定性會受到挑戰：一個微不足道的錯誤，就可能導致整個系統癱瘓，對此可能一點辦法沒有。其次，系統的可擴充套件性不夠：對於一個應用系統，不斷接受千奇百怪的新需求是這個系統具有生命力的向徵，但對於一個龐大的舊系統而言，這點又是每個程式設計師的惡夢。你不知道在一個幾十萬行程式碼的系統裡面改幾行的後果會是什麼，也許什麼事也沒有，也許錯誤從此埋下，等發現的時候已經造成不可挽回的損失。想像一下因為你改的幾行程式碼，給電信帶來幾百上千萬的費用計算錯誤，並且不可回退。

　　解決之道就是微服務架構，同樣引用上面同一篇文章的觀點：

“微服務架構有很多重要的優點。首先，它解決了複雜性的問題。它將一個本會成為巨大的單體應用分解成一系列服務。在保證整體的功能沒有改變的前提下，應用被分成很多的模組或者服務。每個服務都有明確的邊界，這種邊界是通過遠端呼叫（RPC）或者訊息驅動的API來確定的。微服務架構模式強制實行模組化，這種在單體應用中是很難去實現的。結果就是，單個服務開發起來更快、也更容易理解和維護。

第二，這個架構使得每個服務可以被獨立地開發。開發者可以自由地選擇合適的技術，只要這個服務滿足API互動規範。當然，大多陣列織想通過限制技術選項來避免過於無拘無束。然而，這種自由意味著開發者沒必要在開始新工程時繼續使用過時的技術。當開發一個新的服務時，他們可以選擇使用當前的技術。另外，因為服務相對來說很小，那麼使用當前的技術重寫舊的服務會更加可行。

第三，微服務架構模式使得每個微服務可以被獨立部署。當本地的服務發生變化時，開發者不再需要協調這種變化引起的部署問題。只要被測試通過，這些變化就可以被部署。UI團隊可以執行AB測試，並且可以快速地迭代UI的變化。微服務架構模式使得持續部署成為可能。

最後，微服務架構模式使得每個服務可以被獨立地擴充套件。為了滿足吞吐量和可用性，你可以對每個服務部署任意的例項數量。另外，你可以使用最能滿足服務資源要求的硬體。例如，你可以部署CPU密集型影象處理服務到EC2 Compute Optimized instances，部署記憶體資料庫到EC2 Memory-optimized instances。”

　　總結下微服務架構幾點要素：註冊與發現、API Gateway、服務間通訊……

　　3Gpp制定的5G架構規範也是採用微服務的模式。下圖是5G系統的總體架構圖。5G系統被拆分為許多個F(Function)，你問為啥不叫Service，哈哈，3Gpp還是要保持自己的個性的吧，我猜。其中NRF(Network Resource Function)負責各個服務的註冊與發現。標紅的是我們要實現的服務CHF(Charging Function)，與我們打交道的是SMF。各個服務通過定好的協議進行互動，如：NRF的介面協議就叫Nnrf，CHF的介面協議就叫Nchf。

　　  不止於5G的整體架構是微服務架構，每個子服務的內部也都是按微服務的架構重新設計實現的。容器化、微服務架構、服務編排是這兩年我們系統的改造重點。相信也是其它子服務的改造重點。5G核心網未來要滿足網路切片的要求，NFV和微服務化，服務編排都是實現這一切的基礎。

&n