鄭杰生，謝彬瑜，吳廣財，陳 非，花 磊

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

0 引 言

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

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

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

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

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

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

1 建模方法

1.1 基于Istio的微服務性能測試

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

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

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

1.2 基于Lasso回歸的微服務性能建模

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

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

2 建模工具

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

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

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

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

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

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

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

3 實驗評價

3.1 實驗環(huán)境

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

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

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

3.2 實驗結(jié)果

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

在應用性能保障方面，該文對于是否使用建模工具進行微服務水平擴展，應用的整體性能變化進行對比。性能指標使用90%請求響應時間，即在給定時間間隔內(nèi)，處理90%請求的響應時間。

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

圖2 性能比較

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

4 結(jié)束語

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

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