基于5G的微服務(wù)核心網(wǎng)部署及負(fù)載均衡算法研究

朱慶華，常瑩，張景峰

(北京電子科技職業(yè)學(xué)院電信工程學(xué)院，北京100176)

1 引言

5G核心網(wǎng)是第一個(gè)互聯(lián)網(wǎng)技術(shù)和通信技術(shù)融合(ICT)的實(shí)際應(yīng)用，采用基于服務(wù)的網(wǎng)絡(luò)架構(gòu)，其相較于4G，最主要的變化就是虛擬化，即網(wǎng)元功能虛擬化(NFV)，即使用HP，IBM等廠商的x86通用服務(wù)器，目前主要為刀片服務(wù)器[2]，而對于軟件而言，主要采用開源平臺，構(gòu)建屬于自己的虛擬化平臺，將核心網(wǎng)網(wǎng)元在上面進(jìn)行構(gòu)建[3]。5G主要基于SBA架構(gòu)，基于云原生設(shè)計(jì)，采取微服務(wù)理念[4]，將5G 核心網(wǎng)拆分為多個(gè)不同功能的個(gè)體，每個(gè)個(gè)體實(shí)現(xiàn)自己的微服務(wù),使其具有高可用性[5]。云原生部署簡單快捷，應(yīng)用按需伸縮，但依舊存在著安全性不足，可靠性不夠，需要研究負(fù)載均衡算法來應(yīng)用多場景多業(yè)務(wù)的需求。

容器化技術(shù)可以輕松打包應(yīng)用程序的代碼、配置和依賴關(guān)系，將其變成容易使用的構(gòu)建塊，從而實(shí)現(xiàn)環(huán)境一致性、運(yùn)營效率、開發(fā)人員生產(chǎn)力和版本控制等諸多目標(biāo)。容器可以幫助保證應(yīng)用程序快速、可靠、一致地部署人們所需的應(yīng)用[6]，為5G核心網(wǎng)部署帶來便捷。

本文基于現(xiàn)目前開源5G核心網(wǎng)進(jìn)展，研究云原生5G核心網(wǎng)原型系統(tǒng)平臺的構(gòu)建，主要包括現(xiàn)有網(wǎng)絡(luò)功能的容器化實(shí)現(xiàn)，符合5G核心網(wǎng)的云原生系統(tǒng)構(gòu)建，以及云化環(huán)境中的動(dòng)態(tài)擴(kuò)縮容算法的研究，以實(shí)現(xiàn)具備高可靠的云原生5G 核心網(wǎng)系統(tǒng)平臺。

2 系統(tǒng)工作原理及流程

該系統(tǒng)通過將5G核心網(wǎng)元部署到docker上，之后通過k8s中的pod將docker中運(yùn)行的核心網(wǎng)鏡像進(jìn)行管控，對于5G核心網(wǎng)內(nèi)部的工作原理由于過于冗長，且不是本文主要內(nèi)容，所以在這里不再進(jìn)行解釋。如果對于AMF，SMF，UDR，AUSF 的請求過多，會(huì)通過k8s 中的HPA 自動(dòng)擴(kuò)縮容進(jìn)行pod 的增加或者減少，同時(shí)如果那個(gè)節(jié)點(diǎn)出現(xiàn)問題，通過K8s 自帶的負(fù)載均衡算法也同時(shí)會(huì)將上面的節(jié)點(diǎn)的pod轉(zhuǎn)移至其他的節(jié)點(diǎn)上，在這里，用了一個(gè)master，兩個(gè)node節(jié)點(diǎn)進(jìn)行管控，通過將一個(gè)節(jié)點(diǎn)關(guān)閉調(diào)度，觀察其中的pod 轉(zhuǎn)移情況，及新增pod 的情況，除此之外，通過一個(gè)新增的虛擬機(jī)對于系統(tǒng)產(chǎn)生過多的激增請求，觀察k8s基于HPA對于新增的pod節(jié)點(diǎn)的調(diào)度。

3 負(fù)載均衡及擴(kuò)縮容算法

3.1 四層負(fù)載均衡

使用ip+port 接收，然后將其傳輸?shù)较鄳?yīng)的服務(wù)，并在傳輸層進(jìn)行操作。客戶端和服務(wù)器進(jìn)行一次TCP連接。該算法類似于路由器的作用。主要是在四層和七層起作用，而四層和七層的概念來自O(shè)SI七層模型。該算法主要是利用DNS解析，通過kube-proxy 實(shí)現(xiàn)。該算法默認(rèn)解析到虛擬IP 是一個(gè)service服務(wù)，該虛擬IP 通過kube-proxy 將其均衡到各個(gè)不同的Pod上。Pod 的IP 不穩(wěn)定，每次重啟pod 后會(huì)隨機(jī)改變。但service的IP是穩(wěn)定的。所以主要是通過Node Port暴露服務(wù)。使相應(yīng)的pod可以被外界所訪問[7]。

Service 根據(jù)kube-proxy 的不同的代理，展現(xiàn)出不同的性能：

1)userspace模式

service的請求會(huì)從用戶空間進(jìn)入內(nèi)核，然后再返回到用戶空間，由kube-proxy 完成后端的選擇和代理工作，但是這樣所耗費(fèi)的流量和資源巨大，導(dǎo)致性能急劇下降。但是，需要注意的是：請求到達(dá)iptables時(shí)會(huì)進(jìn)入內(nèi)核，而kube-proxy 在這里的主要作用監(jiān)聽是在用戶的工作狀態(tài)。因此請求就會(huì)相應(yīng)地形成從用戶到內(nèi)核再到用戶的一個(gè)傳遞過程,從而降低了服務(wù)性能。因此，userspace 性能差。

2)iptables模式

通過Iptables實(shí)現(xiàn)一個(gè)四層的TCP連接；kube-proxy負(fù)責(zé)創(chuàng)建iptables 中NAT 的相應(yīng)規(guī)則，但不負(fù)責(zé)流量轉(zhuǎn)發(fā)。這種基于iptables 的負(fù)載均衡，操作簡單，但是當(dāng)集群規(guī)模大導(dǎo)致請求響應(yīng)變得多起來的時(shí)候，這種基于iptables 的負(fù)載均衡的性能就會(huì)相應(yīng)變差。當(dāng)添加一個(gè)service的時(shí)候，命令行工具需要從內(nèi)核中讀取當(dāng)前所有的service 列表，然后重新編輯列表，之后再將內(nèi)核中的列表進(jìn)行更新。例如：假如要添加N 個(gè)service 同時(shí)，相應(yīng)的復(fù)雜度為O(N^2)。但是在轉(zhuǎn)發(fā)面上，所有service ip地址組成了一個(gè)list，每一個(gè)報(bào)文都需要查找這個(gè)list，在其中找到相應(yīng)的IP，才可以進(jìn)行下一步操作。但是假如一個(gè)IP 在list 末尾，就需要遍歷N 次，復(fù)雜度為O(N/2)。

沖擊波波陣面前方A和后方B的應(yīng)變、應(yīng)力和粒子速度分別為和{εB, σB, vB} = {εB, σB, 0}，其中v為沖擊速度，其值在沖擊過程中逐漸減少。波陣面上的質(zhì)量和能量守恒關(guān)系[13]分別給出：

四層這種負(fù)載均衡有一些缺點(diǎn)，缺點(diǎn)如下：

Service 如果有很多，并且為了暴露端口供外面的主機(jī)訪問，就需要綁定Node 的主機(jī)端口，這樣的話，外圍的相應(yīng)端口必須開放從而就可以進(jìn)行服務(wù)調(diào)用。為解決這個(gè)問題，比較通用的方式是通過一個(gè)外部的負(fù)載均衡器，例如nginx，綁定相應(yīng)的端口號，之后再根據(jù)相應(yīng)的地址接口進(jìn)行向后面的Service IP進(jìn)行一系列的轉(zhuǎn)發(fā)操作。

Service的同時(shí)存在著很多分發(fā)策略：例如輪詢機(jī)制。將請求轉(zhuǎn)發(fā)到后端的各個(gè)pod之中，由此衍生除了加權(quán)輪詢，即給不同的pod加入權(quán)重，幫助加速實(shí)現(xiàn)負(fù)載均衡。

3.2 七層負(fù)載均衡

七層負(fù)載均衡主要來自現(xiàn)代通信的OSI 七層模型中的第七層應(yīng)用層，負(fù)載均衡器根據(jù)虛擬的URL和主機(jī)名來接收或者發(fā)送請求，將請求進(jìn)行相應(yīng)的負(fù)載均衡處理之后，進(jìn)行相應(yīng)轉(zhuǎn)發(fā)，最終實(shí)現(xiàn)整個(gè)系統(tǒng)的負(fù)載均衡。

七層負(fù)載均衡是通過建立兩次TCP 連接來進(jìn)行相應(yīng)的負(fù)載均衡。客戶到負(fù)載均衡器，負(fù)載均衡器依據(jù)于相關(guān)的請求中所傳輸?shù)膬?nèi)容主要來自URL或cookie中的信息，選擇合適的負(fù)載均衡的算法，選擇相應(yīng)的服務(wù)器；建立負(fù)載均衡器到服務(wù)器之間的連接。但必須注意的是負(fù)載均衡設(shè)備需要先實(shí)現(xiàn)使得服務(wù)器和客戶端建立TCP 連接后，客戶端發(fā)送的含有應(yīng)用層內(nèi)容的報(bào)文會(huì)被接受，然后系統(tǒng)會(huì)根據(jù)該報(bào)文中的特定字段，通過負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，內(nèi)部服務(wù)器就因此會(huì)被最終確定，反向代理也由此而來。

Ingress 是k8s 的一種資源對象，Ingress 允許外部訪問k8s服務(wù)，通過創(chuàng)建規(guī)則集合來配置訪問權(quán)限，這些規(guī)則定義了相應(yīng)的服務(wù)被訪問的權(quán)限設(shè)置，支持HTTP 和HTTPS 協(xié)議；In‐gress 配置相應(yīng)的URL 訪問設(shè)置、同時(shí)設(shè)立相關(guān)的主機(jī)名等一系列配置，促使系統(tǒng)正常運(yùn)行。

七層負(fù)載均衡相較于四層負(fù)載均衡更占CPU，但并不會(huì)導(dǎo)致服務(wù)器性能下降。七層負(fù)載均衡可以讓負(fù)載均衡器做出相應(yīng)的更恰當(dāng)?shù)姆磻?yīng)抉擇，并通過相應(yīng)操作對于相關(guān)內(nèi)容進(jìn)行優(yōu)化，例如壓縮、加密等。七層負(fù)載均衡同樣可以利用buffering等一些操作來卸載其他服務(wù)器的例如慢速連接等一些壞連接，從而提高性能。

圖2 七層負(fù)載均衡原理圖

對于上述負(fù)載而言，還有若干種均衡算法：

第一種：輪循均衡；負(fù)載均衡器將任何一次來自客戶端的請求輪流平均分配給其內(nèi)部中的服務(wù)器，每次服務(wù)請求到達(dá)時(shí)，一次查找內(nèi)部服務(wù)器，找到?jīng)]有負(fù)載的服務(wù)器，這種算法在服務(wù)器配置均衡的情況下，大有裨益。

第二種：權(quán)重輪循均衡：由于每組組服務(wù)器中不同的服務(wù)器處理的性能有很大的差別，如果給每個(gè)服務(wù)器分配不同的權(quán)值，服務(wù)器可以因?yàn)椴煌臋?quán)值而規(guī)劃相應(yīng)的負(fù)載。

第三種：隨機(jī)均衡(Random)：把來自網(wǎng)絡(luò)的請求通過哈希等相關(guān)算法不均勻的分配給內(nèi)部中的多個(gè)服務(wù)器。

第四種：最少連接數(shù)均衡是值得是客戶端的每一次服務(wù)請求在使服務(wù)器工作的時(shí)間很可能大有不同，一旦工作時(shí)間變得更長，如果僅僅是簡單地套用相關(guān)的輪詢和隨機(jī)均衡算法，不同的服務(wù)器會(huì)有極大的不同，所以隨之帶來的負(fù)載均衡仍舊有很大的問題。

第五種：處理能力均衡，這種負(fù)載均衡算法是一種在七層負(fù)載下使用較多的均衡算法，該均衡算法的主要原理是依據(jù)于相關(guān)的系統(tǒng)指標(biāo)，將請求的服務(wù)分發(fā)給負(fù)載較輕的服務(wù)器，該指標(biāo)包括，服務(wù)器的處理性能，和網(wǎng)絡(luò)的擁塞情況，所以，更加因地制宜，性能更加優(yōu)秀。

4 負(fù)載均衡測試

四層負(fù)載均衡主要應(yīng)用于單master 節(jié)點(diǎn)，即，通過關(guān)閉其中一個(gè)node節(jié)點(diǎn)，發(fā)現(xiàn)：停止一個(gè)節(jié)點(diǎn)的調(diào)度之后：

圖3所示，k8snode2節(jié)點(diǎn)停止調(diào)度

圖3 關(guān)閉節(jié)點(diǎn)調(diào)度

增加pod副本數(shù)驗(yàn)證新增pod的節(jié)點(diǎn)分布

輸入命令：kubectl scale deploy/amf --replicas=5，將新增數(shù)設(shè)為5

由圖中可知，其新增節(jié)點(diǎn)均未在k8snode2上分布

恢復(fù)節(jié)點(diǎn)2(k8snode2)調(diào)度

輸入命令：kubectl uncordon k8snode2

輸入命令：kubectl get pods

圖4 重新調(diào)度后pod

可見原本的k8snode2節(jié)點(diǎn)上的pod，轉(zhuǎn)入k8snode2節(jié)點(diǎn)。

5 結(jié)論

本文通過四層負(fù)載均衡和七層負(fù)載均衡算法的介紹并通過但master節(jié)點(diǎn)，關(guān)閉一個(gè)節(jié)點(diǎn)之后，通過考察剩余pod所處節(jié)點(diǎn)位置得到service 和kube-proxy 將其中的pod 進(jìn)行調(diào)度，實(shí)驗(yàn)證明所得到所部署的基于k8s 的5G 核心網(wǎng)系統(tǒng)擁有初步的負(fù)載均衡和擴(kuò)縮容能力。