微服務架構在核心網產品中的應用

韓相國

摘要：微服務架構是目前應用較為廣泛的一種軟件架構，在IT領域已經有廣泛的應用，但是由于電信行業的特殊性，一直沒有采用微服務架構。隨著5G的到來，電信核心網軟件也向著微服務架構轉變。通過研究電信核心網軟件的特征，從架構層面分析微服務架構在電信核心網產品上應用的理論可行性，并在5G核心網NRF網元進行了實踐。首先選擇k8s作為基礎運行平臺，然后根據應用需要增加共享服務，最后對NRF網元的功能進行微服務拆分，最終形成一套完整的NRF網元軟件架構。經項目驗證，基于微服務架構的NRF網元能夠滿足商用要求，電信核心網產品完全可以基于微服務架構構建。

關鍵詞：微服務;5G;電信軟件;核心網;架構設計

引言

微服務概念的提出由來已久，早在2005年，Peter Rodgers博士在Web Services Edge大會上提出“Micro-Web-Services”的概念，他強調獨立的軟件組件以“Micro-Web-Services”的形式存在，組件之間完全松耦合，每個組件提供通用格式的REST 接口，通過多個組件的調用完成完整的軟件功能。2011年在威尼斯舉辦的軟件架構大會上，某工作組使用“microservice”來描述這種軟件架構，隨后在2012年，該工作組正式將這種軟件架構命名為“microservice”（微服務）架構[1]。

一般認為，微服務架構是一種由面向服務架構（SOA）演進而來的軟件架構設計方法，用于構建靈活的、松耦合、可獨立部署的軟件系統。與傳統的SOA架構相比，兩者存在顯著區別：在服務間通信方面，SOA架構往往采用重量級的通信協議，例如SOAP、WSDL定義接口標準等，而微服務架構則使用輕量級的通信協議，如REST、gRPC等，相比較之下，微服務使用的通訊協議實現難度小，復雜度低;在服務規模上，SOA傾向于使用粗粒度的服務，并盡可能地粗粒度建模，通過組合一組粗粒度服務，構建出新的應用程序;而微服務架構則強調細粒度的建模，每個微服務提供的功能盡可能單一，應用程序通過多個微服務的組合調用實現所需功能。

相較于傳統的軟件架構，微服務架構的典型特征與優勢如下：

1）軟件規模小：這里的小并不是單純的指代碼量少，更多的是指將緊密相關、緊耦合的軟件功能放到一個微服務中，使得程序更內聚、更容易理解，便于開發、測試。

2）基于接口：每個微服務將自身的功能封裝為外部接口，外部模塊/服務通過接口調用獲得本服務提供的功能，這種方式很大程度上保證了微服務的獨立性，功能擴展更容易。

3）分布式開發：受益于基于接口的實現方式，微服務間的接口明確后，多團隊可以并行開發，獨立部署、測試，降低團隊之間的協作要求，提升開發效率。

4）團隊自治：各團隊依據自身的技術能力實現軟件功能，沒有統一框架束縛，團隊更容易使用自身熟悉的技術，當然也更容易引入新技術。

盡管微服務架構有諸多優勢，但是微服務架構只是一種軟件架構，需要有一個合適的運行平臺做支撐才能發揮其優勢，恰在此時，容器技術應運而生，容器技術為微服務提供了部署、運行基礎，就像為之量身定制，這也直接催生了微服務架構在后續的軟件架構領域大放異彩。

電信核心網引入微服務架構

電信核心網產品介紹

電信核心網產品由多個獨立的網元組成，這些網元一起配合完成用戶的信令處理和業務流量轉發。一般運營商會以省/市為單位建核心網，所以設備數量比較少，為了保證服務質量，運營商對核心網軟件的要求也比較高：①高可靠性：電信設備要求全年7*24小時不間斷運行，可靠性要達到99.999%;②大容量：單套設備處理百萬用戶業務;③高并發：有足夠的能力保證百萬級用戶信令的處理;④低時延：電信設備需要盡最大速率轉發用戶流量。

與一般的軟件相比，核心網軟件的規模龐大（代碼量千萬行級別）、復雜度高，選擇合理的軟件架構就顯得極為重要。在2/3/4G時代，核心網軟件大部分都是采用單體架構，通過橫向擴展單體軟件數量實現容量和處理能力的增強。

電信核心網引入微服務架構

移動互聯網進入了5G時代后，3GPP協議標準明確要求5G核心網網元使用服務化架構，網元之間的通訊也統一使用服務化接口。順應協議要求，核心網軟件架構也從單體架構向微服務架構轉型。接下來以核心網中的NRF網元為例，介紹該網元的微服務拆分過程以及最終的軟件架構。

NRF網元主要提供網元服務發現注冊功能，核心網網元服務上線后需要向NRF注冊，服務下線時撤銷注冊，這樣NRF網元就具有了本系統中所有網元的服務實例信息。在運行過程中，任意網元都可以通過服務化接口從NRF網元獲取特定的服務信息。

根據NRF網元提供的功能進行服務拆分，總體可分為四個業務服務[2]：①NFManagement：網元服務實例注冊管理;②NFDiscovery：服務發現功能的處理;③AccessToken：安全認證管理;④Bootstraping：提供本網元的服務端點信息。除了基礎業務服務外，系統還需要一些輔助功能：⑤DB：負責網元運行中狀態數據的存儲;⑥OAM：業務管理，提供配置管理、跟蹤、日志等功能。

為了保證業務高可用，以上服務均采用負荷分擔工作模式。

系統架構設計

底層平臺架構設計

目前比較成熟的虛擬化運行平臺主要有兩種，分別是虛機虛擬化和容器虛擬化，兩者適用的場景也有很大差異。前者適合于單體軟件架構，以虛機為單位進行部署，后者適用于微服務架構，以容器為單位進行部署。本文中的NRF網元使用微服務架構，所以本網元考慮使用業界成熟的k8s作為基礎運行平臺。

除了基礎運行平臺外，還有幾部分公共功能需要考慮：

1）通訊平臺：用于實現微服務之間的通訊，服務網格是很好的選擇。服務網格是致力于解決服務間通信的基礎設施層，負責微服務間靈活、高效和可靠地通訊 [3]。本網元使用Istio作為底層通訊平臺。

2）業務接口/負載均衡組件：NRF網元對外通訊全部使用服務化接口，使用的通訊協議為HTTP/HTTPS，接口組件優先選擇NGINX。

3）系統公共服務：包括性能指標、告警、KPI監控、跟蹤、日志收集等，這些公共服務實時監測系統運行狀態。

整體架構設計

整體軟件架構如下：

上圖中每個虛線框代表一個邏輯服務，每個邏輯服務對應k8s系統中的一個Service。每個Service內部由一個或者多個POD組成，每個POD內運行一個或者兩個容器。對于業務POD，內部包含業務容器和istio-proxy容器，前者用于處理業務邏輯，后者負責業務容器與其他容器之間的通訊。

前文已經描述了各業務服務的功能，這里介紹下其他服務：

1）負載均衡服務（LB）：LB綁定了本網元的業務地址，負責從外部系統接收信令，同時將內部的外發報文送到系統外部。

2）共享服務（Share Service）：主要分為三部分功能：①Metric統計：業務和istio-proxy上報運行過程中的統計數據，用戶可以通過這些數據判斷系統運行狀態，也可以自定義告警規則，當滿足特定條件后，觸發告警;②調用鏈跟蹤：用于呈現系統對特定報文的處理過程，數據上報到jaeger，jaeger最終形成完整的調用過程圖;③日志系統：業務將運行過程中的產生的日志推送到elastic search中，后續有故障發生時，運維可以根據日志進行回溯。

3）網元管理（ADM）：使用operator對接k8s系統管理，將本網元需要的運行數據直接寫入到k8s系統中，減少人工干預。

結語

微服務架構是目前應用較為廣泛的一種分布式軟件架構，本文結合了電信核心網產品的特點，以NRF網元為例，進行了以微服務架構為核心的整體軟件架構設計。從網元運行平臺的選型、網元業務微服務拆分和共享服務構建三個方面，分析了核心網網元微服務架構的構建過程，并給出了一個完整的架構設計方案。從項目的開發情況看，本架構能夠滿足商用要求。當然隨著需求增加，系統還會不斷增加功能，后續根據實際系統運行情況再進行有針對性的改進。最后，架構是為產品服務的，未來也會根據需要對現有架構進行改進，確保架構始終滿足產品需求。

參考文獻

[1]Dragoni， Nicola ... "Microservices： yesterday， today， and tomorrow". Present and Ulterior Software Engineering： 195–216.ISBN 978-3-319-67424-7. S2CID 14612986

[2]3GPP TS 29.510-Network Function Repository Services Stage 3

[3]楊怡濱等.服務網格性能優化關鍵技術研究[J].計算機應用與軟件，2021，38（11）：24-30，85