鄭杰生，謝彬瑜，吳廣財(cái)，陳 非，花 磊

(1.廣東電力信息科技有限公司，廣東 廣州 510000；2.蘇州博納訊動(dòng)軟件有限公司，江蘇 蘇州 215000)

0 引 言

近年來，微服務(wù)越來越多地與云計(jì)算技術(shù)相結(jié)合以構(gòu)建彈性可伸縮的基于互聯(lián)網(wǎng)的軟件應(yīng)用，大規(guī)模微服務(wù)通常部署在共享物理資源的云計(jì)算平臺(tái)，廣泛應(yīng)用在眾多領(lǐng)域[6]。云計(jì)算通過互聯(lián)網(wǎng)方便訪問共享計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等物理資源，云計(jì)算數(shù)據(jù)中心的物理服務(wù)器由云服務(wù)提供商管理及維護(hù)，以虛擬機(jī)或容器的形式將共享物理資源提供給用戶使用，云計(jì)算用戶僅支付實(shí)際使用費(fèi)用，而無需維護(hù)物理設(shè)備。

當(dāng)前云計(jì)算平臺(tái)通常由虛擬機(jī)和容器等兩個(gè)虛擬化層組成。容器是輕量級(jí)可獨(dú)立部署執(zhí)行的軟件包，包含運(yùn)行容器所需的依賴組件及運(yùn)行環(huán)境，可以直接部署在主機(jī)或虛擬機(jī)上運(yùn)行?；谌萜鞯奶摂M化技術(shù)可以在多個(gè)容器中實(shí)例化微服務(wù)，使用多個(gè)內(nèi)核并行運(yùn)行容器，以增加服務(wù)器的資源利用率，這樣單個(gè)操作系統(tǒng)上可以運(yùn)行多個(gè)隔離的微服務(wù)實(shí)例[7]。例如，大規(guī)模容器調(diào)度系統(tǒng)Kubernetes使用配置文件通過Pod對(duì)容器進(jìn)行分組及資源約束，以共享物理或虛擬資源，調(diào)度和協(xié)調(diào)容器運(yùn)行。但是由于物理設(shè)備配置、虛擬機(jī)類型、運(yùn)行應(yīng)用的差別，在云計(jì)算環(huán)境下，實(shí)際部署應(yīng)用的性能與預(yù)期存在顯著差異，因此難以為所有云應(yīng)用創(chuàng)建通用的性能模型。

外部負(fù)載是影響交互式應(yīng)用性能的關(guān)鍵因素，當(dāng)并發(fā)數(shù)量超過某個(gè)數(shù)值后，服務(wù)質(zhì)量會(huì)顯著下降，通常表現(xiàn)為用戶請(qǐng)求的響應(yīng)時(shí)間超出服務(wù)提供商所定義的閾值。該文將微服務(wù)容量定義為在不違反服務(wù)質(zhì)量約束的條件下，微服務(wù)可以處理的最大請(qǐng)求速率。使用微服務(wù)容量指標(biāo)可有效檢測(cè)應(yīng)用性能瓶頸，實(shí)現(xiàn)自動(dòng)化、智能化、精準(zhǔn)化的應(yīng)用容量規(guī)劃。因此，使用能滿足服務(wù)質(zhì)量約束的負(fù)載并發(fā)量表示服務(wù)的容量，該值通過對(duì)應(yīng)用或服務(wù)進(jìn)行壓力測(cè)試來確定，即不斷增加負(fù)載直到違反服務(wù)質(zhì)量約束，而后計(jì)算此時(shí)的并發(fā)數(shù)量。

應(yīng)用容量規(guī)劃是實(shí)現(xiàn)云計(jì)算的動(dòng)態(tài)靈活伸縮，提升云應(yīng)用的服務(wù)承載能力，實(shí)現(xiàn)高效資源利用的關(guān)鍵技術(shù)之一[8]。性能瓶頸檢測(cè)用于分析造成應(yīng)用性能衰減的關(guān)鍵微服務(wù)，通過水平擴(kuò)展該微服務(wù)實(shí)例以提高應(yīng)用的整體性能。應(yīng)用容量規(guī)劃是建立在性能瓶頸檢測(cè)基礎(chǔ)上，預(yù)測(cè)負(fù)載變化[9]，制定應(yīng)用資源分配計(jì)劃，以實(shí)現(xiàn)自動(dòng)化的容量規(guī)劃。性能建模是準(zhǔn)確發(fā)現(xiàn)應(yīng)用的性能瓶頸，有效進(jìn)行容量規(guī)劃的關(guān)鍵，而現(xiàn)有技術(shù)難以對(duì)不同類型的虛擬機(jī)資源和部署環(huán)境進(jìn)行性能評(píng)估。

文獻(xiàn)[10]提出了面向多層應(yīng)用的瓶頸檢測(cè)和性能預(yù)測(cè)的分析模型。文獻(xiàn)[11]使用容量分析的方法識(shí)別潛在的資源瓶頸，并提出了性能優(yōu)化的建議。Root系統(tǒng)[12]自動(dòng)檢測(cè)部署在PaaS云計(jì)算環(huán)境中的Web應(yīng)用性能異常。但現(xiàn)有方法多關(guān)注于層次較少、部署環(huán)境單一、規(guī)模受限的應(yīng)用，且需要人工參與解釋、分析結(jié)果，難以應(yīng)對(duì)環(huán)境復(fù)雜的云計(jì)算環(huán)境下，規(guī)模巨大、類型多樣的微服務(wù)應(yīng)用。

為了應(yīng)對(duì)云計(jì)算環(huán)境下微服務(wù)瓶頸檢測(cè)和容量規(guī)劃所面臨的挑戰(zhàn)，該文提出一種基于Lasso回歸的微服務(wù)性能建模方法。首先將目標(biāo)微服務(wù)放置在獨(dú)立的Docker容器中，而后使用Istio為微服務(wù)模擬生成外部負(fù)載并搜集其性能監(jiān)測(cè)數(shù)據(jù)，進(jìn)而基于Lasso回歸建立資源與性能的關(guān)聯(lián)模型以評(píng)估微服務(wù)的請(qǐng)求處理能力，從而實(shí)現(xiàn)微服務(wù)的細(xì)粒度靈活水平擴(kuò)展。

1 建模方法

1.1 基于Istio的微服務(wù)性能測(cè)試

Docker容器技術(shù)將目標(biāo)微服務(wù)與依賴的系統(tǒng)資源或服務(wù)進(jìn)行隔離，以便對(duì)目標(biāo)服務(wù)進(jìn)行有針對(duì)性的測(cè)試與分析[13]。Istio為微服務(wù)開發(fā)與管理提供服務(wù)網(wǎng)格基礎(chǔ)平臺(tái)，能夠高效運(yùn)行分布式微服務(wù)應(yīng)用，并提供了統(tǒng)一的連接、監(jiān)測(cè)和保護(hù)微服務(wù)的方式，以降低微服務(wù)部署的復(fù)雜性以減輕開發(fā)團(tuán)隊(duì)的工作量。該文將目標(biāo)微服務(wù)實(shí)例放置在Docker容器環(huán)境中，通過Istio的服務(wù)代理機(jī)制使其與依賴的微服務(wù)隔離，而無需對(duì)原微服務(wù)做改動(dòng)。Istio以邊車模式為每個(gè)微服務(wù)部署服務(wù)代理，微服務(wù)接收對(duì)原微服務(wù)的API調(diào)用請(qǐng)求并響應(yīng)以評(píng)估該微服務(wù)的性能。服務(wù)代理的URL作為環(huán)境變量形式傳遞給微服務(wù)，以保證能夠截獲每個(gè)請(qǐng)求并返回響應(yīng)。

2016年，國務(wù)院總理李克強(qiáng)在政府工作報(bào)告中提出，“鼓勵(lì)企業(yè)開展個(gè)性化定制、柔性化生產(chǎn)，培育精益求精的工匠精神”。[1]由此，“工匠精神”首次被政府提出，同時(shí)上升到國家發(fā)展層面，迅速成為輿論和社會(huì)爭相關(guān)注的熱點(diǎn)，并作為各行業(yè)嚴(yán)謹(jǐn)精確、鍥而不舍的代名詞。

該文通過Kubernetes將具有服務(wù)代理的微服務(wù)Docker容器部署在服務(wù)器集群中，線性增加外部負(fù)載，收集資源利用率和性能指標(biāo)。當(dāng)檢測(cè)到性能度量違反服務(wù)質(zhì)量約束時(shí)，將收集的數(shù)據(jù)持久化存儲(chǔ)到數(shù)據(jù)庫中，作為目標(biāo)微服務(wù)的容量。在不同部署配置下，重復(fù)以上負(fù)載生成和數(shù)據(jù)搜集過程，不斷修改容器配置對(duì)模型進(jìn)行訓(xùn)練，直到生成的性能模型的精度不再明顯提高為止。

1.2 基于Lasso回歸的微服務(wù)性能建模

該文使用負(fù)載測(cè)試產(chǎn)生的Docker容器中微服務(wù)的監(jiān)測(cè)數(shù)據(jù)，基于Lasso回歸模型[14]刻畫微服務(wù)容量與資源使用(虛擬CPU、內(nèi)存、網(wǎng)絡(luò)等度量)的關(guān)聯(lián)關(guān)系。與其他回歸模型相比，如支持向量回歸(SVR)、簡單線性回歸、多項(xiàng)式回歸，Lasso回歸模型具有更高的準(zhǔn)確性，并且能夠在更短的時(shí)間內(nèi)擬合收斂。該文基于該模型預(yù)測(cè)在特定部署配置條件下目標(biāo)微服務(wù)的容量，判斷處理特定數(shù)量請(qǐng)求所需的微服務(wù)副本數(shù)量。模型的輸入為多維資源度量，輸出為微服務(wù)容量，基于Lasso回歸的性能建模過程具體如下：

約束條件的參數(shù)c通過廣義交叉驗(yàn)證法來選擇，其形式為：

2 建模工具

該文根據(jù)以上性能建模方法，設(shè)計(jì)并實(shí)現(xiàn)了性能建模工具，用來部署基于Kubernetes的微服務(wù)集群、生成工作負(fù)載、監(jiān)測(cè)運(yùn)行狀態(tài)、建模微服務(wù)性能及實(shí)現(xiàn)微服務(wù)容量規(guī)劃。

如圖1所示，建模工具采用微服務(wù)架構(gòu)，由配置及部署、容量規(guī)劃、運(yùn)行監(jiān)管、負(fù)載生成、Docker容器等模塊構(gòu)成，通過Restful API進(jìn)行模塊間通信，將數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫以供查詢、分析。

圖1 建模工具系統(tǒng)架構(gòu)

配置及部署模塊使用Yaml文件配置并構(gòu)建微服務(wù)應(yīng)用，將微服務(wù)包裝在Docker容器中進(jìn)行部署，并創(chuàng)建相應(yīng)的Docker容器作為Docker容器；配置分配給每個(gè)微服務(wù)的副本數(shù)量，以及CPU和內(nèi)存的物理資源限制，并部署Kubernetes集群。容量規(guī)劃模塊根據(jù)測(cè)試階段收集的監(jiān)測(cè)數(shù)據(jù)使用擬合的Lasso回歸構(gòu)建微服務(wù)的性能模型，基于Lasso回歸模型刻畫部署特征、資源消耗和性能之間的關(guān)聯(lián)以估計(jì)在一定部署配置條件下的微服務(wù)容量；提供Restful API以設(shè)置配置參數(shù)，用戶通過調(diào)用API可以啟動(dòng)測(cè)試，查看擬合的性能模型、估計(jì)的微服務(wù)容量、微服務(wù)副本數(shù)量。

運(yùn)行監(jiān)管模塊使用監(jiān)管代理監(jiān)測(cè)每個(gè)微服務(wù)占用的物理資源，并將監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫中；將Yaml文件、微服務(wù)名稱和API作為配置信息以創(chuàng)建Docker容器。負(fù)載生成模塊在Kubernetes集群上部署微服務(wù)后，使用JMeter生成線性增長的負(fù)載，用以測(cè)試在特定部署配置條件下的微服務(wù)。Docker容器模塊利用Docker容器以隔離每個(gè)微服務(wù)，使用Istio為每個(gè)容器創(chuàng)建服務(wù)代理以接受請(qǐng)求并返回響應(yīng)，并啟動(dòng)監(jiān)管代理線程對(duì)Docker容器進(jìn)行監(jiān)測(cè)和管理。

用戶通過Restful API設(shè)定目標(biāo)應(yīng)用及參數(shù)，如果應(yīng)用包含多個(gè)微服務(wù)，則使用Docker容器包裝每個(gè)微服務(wù)，并自動(dòng)生成測(cè)試負(fù)載；而后，對(duì)于每個(gè)Docker容器中的微服務(wù)進(jìn)行性能建模；最后，根據(jù)性能建模得到各微服務(wù)的容量，給出應(yīng)用中各微服務(wù)運(yùn)行實(shí)例數(shù)量的建議。

具體執(zhí)行步驟包括：建模工具運(yùn)行部署與配置模塊將Kubernetes和Istio部署到云計(jì)算平臺(tái)，設(shè)置Pod副本數(shù)量范圍及資源約束條件；啟動(dòng)包裝微服務(wù)的Docker容器鏡像，并在容器啟動(dòng)時(shí)為微服務(wù)啟動(dòng)服務(wù)代理；負(fù)載生成模塊產(chǎn)生線性增加的負(fù)載，監(jiān)管代理監(jiān)測(cè)容器的資源及性能度量，當(dāng)檢測(cè)到違反服務(wù)質(zhì)量約束時(shí)，記錄微服務(wù)的負(fù)載、性能、容量等監(jiān)測(cè)數(shù)據(jù)；建立以部署配置及環(huán)境為輸入，以容量為輸出的基于Lasso回歸的性能模型；在特定配置下預(yù)測(cè)微服務(wù)容量，根據(jù)當(dāng)前微服務(wù)負(fù)載狀況，規(guī)劃各微服務(wù)副本的數(shù)量。

3 實(shí)驗(yàn)評(píng)價(jià)

3.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)部署環(huán)境包括4臺(tái)物理主機(jī)，其中1臺(tái)為管理節(jié)點(diǎn)以部署建模工具的管理端程序，另外3臺(tái)為工作節(jié)點(diǎn)以部署微服務(wù)Docker容器和建模工具模塊。物理主機(jī)配置為Intel Xeon E5-2620 CPU，16 GB RAM內(nèi)存，500 GB磁盤，100 Mbps網(wǎng)絡(luò)連接，操作系統(tǒng)為CentOS 6.5，容器為Docker 1.13，容器編排為Yaml 1.11.1，容器管理系統(tǒng)為Kubernetes 1.11.0。

在目標(biāo)應(yīng)用方面，該文使用典型微服務(wù)架構(gòu)應(yīng)用MediaService[15]，選取其中4個(gè)典型微服務(wù)評(píng)價(jià)方法及工具的有效性。其中，VideoStreaming為I/O密集型微服務(wù)，用以從后端NFS中讀取流媒體格式的視頻數(shù)據(jù)；Rating為數(shù)據(jù)庫訪問型微服務(wù)，連接到后端數(shù)據(jù)庫MySQL，用以查詢電影信息；ComposePage為Web訪問型微服務(wù)，用戶接受用戶請(qǐng)求并返回相應(yīng)字符串；php-fpm為服務(wù)網(wǎng)關(guān)微服務(wù)，用以接收用戶請(qǐng)求，并將其分派給后端微服務(wù)，在收到所有微服務(wù)的響應(yīng)后，組合響應(yīng)信息并匯總返回結(jié)果。

在負(fù)載生成方面，實(shí)驗(yàn)根據(jù)每種微服務(wù)類型處理請(qǐng)求的資源利用情況，確定不同的負(fù)載生成率，負(fù)載數(shù)量引起資源利用率變化設(shè)定為每分鐘約為0.05%。負(fù)載測(cè)試從單個(gè)請(qǐng)求開始，請(qǐng)求數(shù)量呈線性增加，VideoStreaming每分鐘增加12次訪問，Rating每分鐘增加24次訪問，ComposePage每分鐘增加36次訪問，Php-fpm每分鐘增加48次訪問。

3.2 實(shí)驗(yàn)結(jié)果

在容量預(yù)測(cè)準(zhǔn)確性方面，該文使用平均絕對(duì)百分比誤差(MAPE)將實(shí)際監(jiān)測(cè)與模型預(yù)測(cè)的微服務(wù)容量進(jìn)行比較，實(shí)驗(yàn)中VideoStreaming，Rating，Compose Page和Php-fpm的誤差分別為2.71%，9.28%，9.74%和6.48%，實(shí)驗(yàn)結(jié)果表明建模工具具有較高的預(yù)測(cè)準(zhǔn)確性。

在應(yīng)用性能保障方面，該文對(duì)于是否使用建模工具進(jìn)行微服務(wù)水平擴(kuò)展，應(yīng)用的整體性能變化進(jìn)行對(duì)比。性能指標(biāo)使用90%請(qǐng)求響應(yīng)時(shí)間，即在給定時(shí)間間隔內(nèi)，處理90%請(qǐng)求的響應(yīng)時(shí)間。

如圖2所示，實(shí)驗(yàn)首先未使用建模工具進(jìn)行容量規(guī)劃，以整個(gè)應(yīng)用為管理單元，設(shè)置副本數(shù)量為3，監(jiān)測(cè)應(yīng)用性能變化。而后，使用建模工具進(jìn)行容量規(guī)劃，以微服務(wù)為管理單元，微服務(wù)副本數(shù)量根據(jù)微服務(wù)容量與負(fù)載數(shù)量動(dòng)態(tài)變化，監(jiān)測(cè)應(yīng)用性能變化。

圖2 性能比較

實(shí)驗(yàn)結(jié)果表明，負(fù)載數(shù)量在900以下時(shí)，由于應(yīng)用未達(dá)到性能瓶頸，二者的響應(yīng)時(shí)間差別不大。當(dāng)負(fù)載數(shù)量大于1 050時(shí)，對(duì)于未使用建模工具進(jìn)行容量規(guī)劃的應(yīng)用，由于在Rating微服務(wù)出現(xiàn)了性能瓶頸，應(yīng)用的響應(yīng)時(shí)間呈指數(shù)級(jí)增加。對(duì)于使用建模工具進(jìn)行容量規(guī)劃的應(yīng)用，由于能夠根據(jù)負(fù)載數(shù)量動(dòng)態(tài)擴(kuò)展Rating微服務(wù)實(shí)例數(shù)量，響應(yīng)時(shí)間保持平穩(wěn)，并未出現(xiàn)大幅上升。

4 結(jié)束語

微服務(wù)技術(shù)將應(yīng)用劃分為多個(gè)功能獨(dú)立的微服務(wù)，并使用與語言和平臺(tái)無關(guān)的API實(shí)現(xiàn)微服務(wù)間的通信，近年來在業(yè)界得到廣泛應(yīng)用。微服務(wù)的資源使用取決于其所實(shí)現(xiàn)的功能和外部負(fù)載，負(fù)載突增會(huì)造成應(yīng)用違反服務(wù)質(zhì)量約束，因此需要限制每個(gè)微服務(wù)的最大訪問速率以保證其服務(wù)質(zhì)量。然而，在云計(jì)算環(huán)境下，部署環(huán)境與應(yīng)用種類的多樣性與復(fù)雜性造成了難以準(zhǔn)確評(píng)估每個(gè)微服務(wù)的服務(wù)能力。為了應(yīng)對(duì)該挑戰(zhàn)，提出一種基于Lasso回歸的微服務(wù)應(yīng)用性能建模方法。

該方法首先將目標(biāo)微服務(wù)放置在Docker容器環(huán)境，而后生成外部負(fù)載并搜集微服務(wù)的性能及資源的監(jiān)測(cè)數(shù)據(jù)，基于Lasso回歸模型建立配置、資源與性能之間的關(guān)聯(lián)關(guān)系，進(jìn)而評(píng)估每個(gè)微服務(wù)的容量以實(shí)現(xiàn)細(xì)粒度靈活擴(kuò)展?；谝陨戏椒ǎ瑢?shí)現(xiàn)了原型系統(tǒng)，基于云計(jì)算平臺(tái)使用典型微服務(wù)進(jìn)行驗(yàn)證，實(shí)驗(yàn)結(jié)果表明該方法具有較低的預(yù)測(cè)誤差，能夠有效保證系統(tǒng)性能。