韓相國

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

關(guān)鍵詞：微服務(wù);5G;電信軟件;核心網(wǎng);架構(gòu)設(shè)計

引言

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

一般認(rèn)為，微服務(wù)架構(gòu)是一種由面向服務(wù)架構(gòu)（SOA）演進(jìn)而來的軟件架構(gòu)設(shè)計方法，用于構(gòu)建靈活的、松耦合、可獨(dú)立部署的軟件系統(tǒng)。與傳統(tǒng)的SOA架構(gòu)相比，兩者存在顯著區(qū)別：在服務(wù)間通信方面，SOA架構(gòu)往往采用重量級的通信協(xié)議，例如SOAP、WSDL定義接口標(biāo)準(zhǔn)等，而微服務(wù)架構(gòu)則使用輕量級的通信協(xié)議，如REST、gRPC等，相比較之下，微服務(wù)使用的通訊協(xié)議實現(xiàn)難度小，復(fù)雜度低;在服務(wù)規(guī)模上，SOA傾向于使用粗粒度的服務(wù)，并盡可能地粗粒度建模，通過組合一組粗粒度服務(wù)，構(gòu)建出新的應(yīng)用程序;而微服務(wù)架構(gòu)則強(qiáng)調(diào)細(xì)粒度的建模，每個微服務(wù)提供的功能盡可能單一，應(yīng)用程序通過多個微服務(wù)的組合調(diào)用實現(xiàn)所需功能。

相較于傳統(tǒng)的軟件架構(gòu)，微服務(wù)架構(gòu)的典型特征與優(yōu)勢如下：

1）軟件規(guī)模?。哼@里的小并不是單純的指代碼量少，更多的是指將緊密相關(guān)、緊耦合的軟件功能放到一個微服務(wù)中，使得程序更內(nèi)聚、更容易理解，便于開發(fā)、測試。

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

3）分布式開發(fā)：受益于基于接口的實現(xiàn)方式，微服務(wù)間的接口明確后，多團(tuán)隊可以并行開發(fā)，獨(dú)立部署、測試，降低團(tuán)隊之間的協(xié)作要求，提升開發(fā)效率。

4）團(tuán)隊自治：各團(tuán)隊依據(jù)自身的技術(shù)能力實現(xiàn)軟件功能，沒有統(tǒng)一框架束縛，團(tuán)隊更容易使用自身熟悉的技術(shù)，當(dāng)然也更容易引入新技術(shù)。

盡管微服務(wù)架構(gòu)有諸多優(yōu)勢，但是微服務(wù)架構(gòu)只是一種軟件架構(gòu)，需要有一個合適的運(yùn)行平臺做支撐才能發(fā)揮其優(yōu)勢，恰在此時，容器技術(shù)應(yīng)運(yùn)而生，容器技術(shù)為微服務(wù)提供了部署、運(yùn)行基礎(chǔ)，就像為之量身定制，這也直接催生了微服務(wù)架構(gòu)在后續(xù)的軟件架構(gòu)領(lǐng)域大放異彩。

電信核心網(wǎng)引入微服務(wù)架構(gòu)

電信核心網(wǎng)產(chǎn)品介紹

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

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

電信核心網(wǎng)引入微服務(wù)架構(gòu)

移動互聯(lián)網(wǎng)進(jìn)入了5G時代后，3GPP協(xié)議標(biāo)準(zhǔn)明確要求5G核心網(wǎng)網(wǎng)元使用服務(wù)化架構(gòu)，網(wǎng)元之間的通訊也統(tǒng)一使用服務(wù)化接口。順應(yīng)協(xié)議要求，核心網(wǎng)軟件架構(gòu)也從單體架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型。接下來以核心網(wǎng)中的NRF網(wǎng)元為例，介紹該網(wǎng)元的微服務(wù)拆分過程以及最終的軟件架構(gòu)。

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

根據(jù)NRF網(wǎng)元提供的功能進(jìn)行服務(wù)拆分，總體可分為四個業(yè)務(wù)服務(wù)[2]：①NFManagement：網(wǎng)元服務(wù)實例注冊管理;②NFDiscovery：服務(wù)發(fā)現(xiàn)功能的處理;③AccessToken：安全認(rèn)證管理;④Bootstraping：提供本網(wǎng)元的服務(wù)端點(diǎn)信息。除了基礎(chǔ)業(yè)務(wù)服務(wù)外，系統(tǒng)還需要一些輔助功能：⑤DB：負(fù)責(zé)網(wǎng)元運(yùn)行中狀態(tài)數(shù)據(jù)的存儲;⑥OAM：業(yè)務(wù)管理，提供配置管理、跟蹤、日志等功能。

為了保證業(yè)務(wù)高可用，以上服務(wù)均采用負(fù)荷分擔(dān)工作模式。

系統(tǒng)架構(gòu)設(shè)計

底層平臺架構(gòu)設(shè)計

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

除了基礎(chǔ)運(yùn)行平臺外，還有幾部分公共功能需要考慮：

1）通訊平臺：用于實現(xiàn)微服務(wù)之間的通訊，服務(wù)網(wǎng)格是很好的選擇。服務(wù)網(wǎng)格是致力于解決服務(wù)間通信的基礎(chǔ)設(shè)施層，負(fù)責(zé)微服務(wù)間靈活、高效和可靠地通訊 [3]。本網(wǎng)元使用Istio作為底層通訊平臺。

2）業(yè)務(wù)接口/負(fù)載均衡組件：NRF網(wǎng)元對外通訊全部使用服務(wù)化接口，使用的通訊協(xié)議為HTTP/HTTPS，接口組件優(yōu)先選擇NGINX。

3）系統(tǒng)公共服務(wù)：包括性能指標(biāo)、告警、KPI監(jiān)控、跟蹤、日志收集等，這些公共服務(wù)實時監(jiān)測系統(tǒng)運(yùn)行狀態(tài)。

整體架構(gòu)設(shè)計

整體軟件架構(gòu)如下：

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

前文已經(jīng)描述了各業(yè)務(wù)服務(wù)的功能，這里介紹下其他服務(wù)：

1）負(fù)載均衡服務(wù)（LB）：LB綁定了本網(wǎng)元的業(yè)務(wù)地址，負(fù)責(zé)從外部系統(tǒng)接收信令，同時將內(nèi)部的外發(fā)報文送到系統(tǒng)外部。

2）共享服務(wù)（Share Service）：主要分為三部分功能：①M(fèi)etric統(tǒng)計：業(yè)務(wù)和istio-proxy上報運(yùn)行過程中的統(tǒng)計數(shù)據(jù)，用戶可以通過這些數(shù)據(jù)判斷系統(tǒng)運(yùn)行狀態(tài)，也可以自定義告警規(guī)則，當(dāng)滿足特定條件后，觸發(fā)告警;②調(diào)用鏈跟蹤：用于呈現(xiàn)系統(tǒng)對特定報文的處理過程，數(shù)據(jù)上報到j(luò)aeger，jaeger最終形成完整的調(diào)用過程圖;③日志系統(tǒng)：業(yè)務(wù)將運(yùn)行過程中的產(chǎn)生的日志推送到elastic search中，后續(xù)有故障發(fā)生時，運(yùn)維可以根據(jù)日志進(jìn)行回溯。

3）網(wǎng)元管理（ADM）：使用operator對接k8s系統(tǒng)管理，將本網(wǎng)元需要的運(yùn)行數(shù)據(jù)直接寫入到k8s系統(tǒng)中，減少人工干預(yù)。

結(jié)語

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

參考文獻(xiàn)

[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]楊怡濱等.服務(wù)網(wǎng)格性能優(yōu)化關(guān)鍵技術(shù)研究[J].計算機(jī)應(yīng)用與軟件，2021，38（11）：24-30，85