考慮穩(wěn)定性與響應(yīng)時間的微服務(wù)應(yīng)用性能測試方法

劉恒旺，靳 鑫，吳 琦，孫 歆，孫昌華

（1.安徽繼遠(yuǎn)檢驗(yàn)檢測技術(shù)有限公司，安徽合肥 230097；2.國網(wǎng)浙江省電力有限公司電力科學(xué)研究院，浙江杭州 310014）

針對單體應(yīng)用的缺點(diǎn)，提出了一個與單體應(yīng)用體系結(jié)構(gòu)完全不同的微服務(wù)體系結(jié)構(gòu)[1]。這個應(yīng)用程序被劃分成邏輯、設(shè)計(jì)和開發(fā)的小型服務(wù)組，每個服務(wù)組只關(guān)注其所負(fù)責(zé)的功能，而不關(guān)注其他服務(wù)及其內(nèi)部實(shí)現(xiàn)功能[2]。這些服務(wù)可以單獨(dú)部署在平臺（服務(wù)器）上，也可以在獨(dú)立進(jìn)程中運(yùn)行，進(jìn)程之間相互隔離，減少了服務(wù)間的耦合。添加bug 更改新特性，在此過程中要求重新部署該特性，而微服務(wù)架構(gòu)則將重點(diǎn)放在服務(wù)分段上，僅對修改后的服務(wù)進(jìn)行重新部署，并且不會影響其他服務(wù)的運(yùn)行。因此，研究微服務(wù)的良好應(yīng)用性能是非常必要的。以往使用的考慮Spring Cloud 技術(shù)的微服務(wù)應(yīng)用性能測試方法[3]，利用Spring Cloud 技術(shù)將微服務(wù)分為不同獨(dú)立業(yè)務(wù)模塊，對各個模塊進(jìn)行性能測試分析；考慮Java 開發(fā)框架微服務(wù)應(yīng)用性能測試方法[4]，結(jié)合Java語言和Web 工具，實(shí)現(xiàn)微服務(wù)應(yīng)用性能測試。然而，上述這兩種方法受到微服務(wù)大量數(shù)據(jù)影響，處理數(shù)據(jù)時間需要耗費(fèi)大量時間，導(dǎo)致性能測試結(jié)果不精準(zhǔn)，為此，提出了考慮穩(wěn)定性與響應(yīng)時間的微服務(wù)應(yīng)用性能測試方法。

1 測試環(huán)境與實(shí)驗(yàn)場景

1.1 測試環(huán)境

考慮穩(wěn)定性與響應(yīng)時間的微服務(wù)應(yīng)用性能測試是在Windows10 企業(yè)版的64 位操作系統(tǒng)下進(jìn)行的，測試包為JMeter，開發(fā)工具為Maven3.3.9，數(shù)據(jù)庫為MySQL5.7。

1.2 實(shí)驗(yàn)場景

使用了前臺檢測和后臺檢查的方法，前臺測試系統(tǒng)是用戶可以查看和操作的基本頁面[5]。后臺是系統(tǒng)管理頁面，需要系統(tǒng)管理員進(jìn)行驗(yàn)證，得到確認(rèn)后才能運(yùn)行[6]。其中前臺頁面負(fù)責(zé)執(zhí)行如下內(nèi)容：使用者在登錄頁面輸入個人資料，待網(wǎng)頁顯示已成功登錄后，使用者可自行修改文章，并及時回復(fù)其他使用者的意見，當(dāng)使用者進(jìn)入主頁時，填寫關(guān)鍵詞搜尋想瀏覽的資訊[7]。

后臺頁面負(fù)責(zé)執(zhí)行如下內(nèi)容：挑選信譽(yù)極好的用戶作為管理員，負(fù)責(zé)刪除不良用戶、非法文章和所有的評論任務(wù)[8]。

系統(tǒng)整體采用的微服務(wù)架構(gòu)如圖1 所示。

圖1 微服務(wù)架構(gòu)

由圖1 可知，微服務(wù)組采用MVC 體系結(jié)構(gòu)，每一種服務(wù)都擁有獨(dú)立的數(shù)據(jù)源[9]，并可以獨(dú)立運(yùn)行，不需要其他服務(wù)的支持。同時，在微服務(wù)組件中注冊這些服務(wù)，通過不同服務(wù)設(shè)備之間的相互通信，可以減少服務(wù)間的耦合[10]，從而充分提高系統(tǒng)內(nèi)聚性。

2 微服務(wù)應(yīng)用性能測試

采用JMeter 測試工具，對基于微服務(wù)應(yīng)用的性能進(jìn)行測試。為了使測試數(shù)據(jù)盡可能客觀，微服務(wù)主要實(shí)現(xiàn)了業(yè)務(wù)的功能邏輯代碼[11]，微服務(wù)系統(tǒng)測試結(jié)構(gòu)如圖2 所示。

圖2 微服務(wù)系統(tǒng)測試結(jié)構(gòu)

2.1 穩(wěn)定性分析

關(guān)于穩(wěn)定性測試，提出了基于EBPF 的微服務(wù)應(yīng)用系統(tǒng)性能測試方法。在微服務(wù)監(jiān)控節(jié)點(diǎn)中進(jìn)行應(yīng)用[12]，測試步驟如下：

步驟一：接收群集監(jiān)控節(jié)點(diǎn)發(fā)送的控制指令。

步驟二：當(dāng)該指令的事件或函數(shù)被執(zhí)行時，指令需要包含要收集的數(shù)據(jù)類型信息，并收集要使用的性能度量信息。

步驟三：當(dāng)執(zhí)行事件或功能時，EBPF 工具收集其性能度量參數(shù)。

1）該性能度量參數(shù)要求獲得與微服務(wù)相關(guān)的所有信息，即網(wǎng)絡(luò)消息鏈，在網(wǎng)絡(luò)消息跟蹤中建立網(wǎng)絡(luò)消息鏈接[13-14]。由于微服務(wù)的類型較多，且每一個微服務(wù)對應(yīng)著不同類型和數(shù)量的消息[15]，因此要求分組進(jìn)行篩選過濾，并選擇任何與微服務(wù)相關(guān)的、受監(jiān)測的分組來建立鏈接。另外可以利用微服務(wù)對IP 信息進(jìn)行分組、過濾、篩選等。每個會話都是在過濾出消息后，對消息信息進(jìn)行分類，并且在同一個會話中將消息分成不同的類別。對每一次會話中的每條消息進(jìn)行分析（例如消息接收、發(fā)送、接收時間等）[16]，構(gòu)建高效的狀態(tài)機(jī)（如圖3 所示），在有限狀態(tài)機(jī)的基礎(chǔ)上確定網(wǎng)絡(luò)消息鏈接。

從圖3 可以看到，有效狀態(tài)機(jī)啟動時為初始化狀態(tài)，接收到報(bào)文后處于接收請求狀態(tài)，此階段的時間為接收請求時間。在發(fā)送請求時，進(jìn)入發(fā)送請求狀態(tài)，發(fā)送到接收時處于結(jié)束狀態(tài)，完成后在循環(huán)中進(jìn)行新的發(fā)送和接收任務(wù)。也可以假定每個節(jié)點(diǎn)都會收到確認(rèn)信息，所有收到的消息都是嵌套的，如圖4 所示。

圖3 有效狀態(tài)機(jī)

圖4 網(wǎng)絡(luò)報(bào)文鏈路結(jié)構(gòu)示意圖

由圖4 可知，當(dāng)一個節(jié)點(diǎn)接收到一條消息時，該節(jié)點(diǎn)將其他節(jié)點(diǎn)發(fā)送的所有消息都保存起來，然后通過嵌套不同的消息間隔關(guān)系計(jì)算出各個網(wǎng)絡(luò)的消息連接情況。

2）性能指標(biāo)參數(shù)還包括網(wǎng)絡(luò)請求處理時間、CPU 利用率、內(nèi)存利用率以及對日志的讀寫。在函數(shù)執(zhí)行過程中，將收集和存儲函數(shù)在每次事件或上下文切換過程中生成的函數(shù)調(diào)用堆棧，用來判斷微服務(wù)系統(tǒng)是否存在異常。

步驟四：采用統(tǒng)一格式處理性能指標(biāo)參數(shù)；

步驟五：將性能度量參數(shù)發(fā)送到集群監(jiān)控節(jié)點(diǎn)，根據(jù)應(yīng)用程序能力度量參數(shù)確定微服務(wù)的穩(wěn)定性。

步驟六：每星期測試一次，如果測試結(jié)果表明微服務(wù)提供商由于網(wǎng)絡(luò)原因不能被調(diào)用，則會導(dǎo)致用戶發(fā)生“串聯(lián)故障”，即“雪崩效應(yīng)”，如圖5 所示。

由圖5 可知，如果服務(wù)節(jié)點(diǎn)調(diào)用失敗，那么系統(tǒng)將立即執(zhí)行代碼，以提高整個系統(tǒng)的可用性，防止基于代碼的設(shè)置、請求失敗和超時等雪崩效應(yīng)的發(fā)生。若服務(wù)器模塊通過了高壓測試，就不會出現(xiàn)系統(tǒng)錯誤和宕機(jī)故障。

圖5 雪崩效應(yīng)

2.2 響應(yīng)時間分析

響應(yīng)時間分析需借助JMeter 測試工具，單體中共設(shè)置50 個用戶，對200 000 個樣本進(jìn)行測試，測試結(jié)果如表1 所示。

表1 單體應(yīng)用

由表1 可知，在200 000 個樣本中，平均響應(yīng)時間為20 ms，誤差為0，對這些測試數(shù)據(jù)進(jìn)行匯總處理后，得到的應(yīng)用性能數(shù)據(jù)如表2 所示。

表2 應(yīng)用性能數(shù)據(jù)

由表2 可知，在兩種樣本數(shù)量下，微服務(wù)響應(yīng)時間比單體應(yīng)用響應(yīng)時間要低，但吞吐量比單體應(yīng)用吞吐量要高。產(chǎn)生這種情況的主要原因是微服務(wù)具有容錯機(jī)制，一旦出現(xiàn)無法訪問目標(biāo)的情況，微服務(wù)就會立刻終止。因此，無論系統(tǒng)是否出現(xiàn)故障，用戶都會得到一個良好的界面，由此也保障用戶具有良好的體驗(yàn)效果。

3 測試結(jié)果與分析

從穩(wěn)定性與響應(yīng)時間兩個方面對微服務(wù)應(yīng)用性能進(jìn)行測試，微服務(wù)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖6 所示。

圖6 微服務(wù)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

由圖6 可知，被測試設(shè)備被配置為網(wǎng)絡(luò)服務(wù)器端，接收來自客戶端的HTTP 請求。被測試設(shè)備安裝操作系統(tǒng)，Nginx 作為網(wǎng)絡(luò)服務(wù)器，被測試頁面分為動態(tài)和靜態(tài)兩個頁面。為了獲取微服務(wù)理想情況下的性能指標(biāo)，使用小于1 kB 的靜態(tài)頁面和1 MB 的動態(tài)頁面，其吞吐量分別為25～35 kB/s 和42～62 kB/s。

基于微服務(wù)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，分別使用考慮Spring Cloud 技術(shù)微服務(wù)應(yīng)用性能測試方法（W1）、考慮Java 開發(fā)框架微服務(wù)應(yīng)用性能測試方法（W2）和eBPF 工具微服務(wù)應(yīng)用性能測試方法（W3）對微服務(wù)吞吐量進(jìn)行對比分析，結(jié)果如表3 所示。

表3 3種方式吞吐量對比分析

由表3可知，使用基于Spring Cloud技術(shù)微服務(wù)應(yīng)用性能測試方法，靜態(tài)頁面下的吞吐量為19～40 kB/s，動態(tài)頁面下的吞吐量為36～54 kB/s，超出理想情況下的范圍；使用基于Java 開發(fā)框架微服務(wù)應(yīng)用性能測試方法，靜態(tài)頁面下的吞吐量為22～36 kB/s，動態(tài)頁面下的吞吐量為38～54 kB/s，超出理想情況下的范圍；使用基于eBPF 工具微服務(wù)應(yīng)用性能測試方法，靜態(tài)頁面下的吞吐量為26～33 kB/s，動態(tài)頁面下的吞吐量為45～59 kB/s，在理想范圍內(nèi)。由此可知，使用該方法時數(shù)據(jù)傳輸十分穩(wěn)定，說明該方法下測得的系統(tǒng)是穩(wěn)定的，與理想情況一致。

分別使用3 種方法對微服務(wù)響應(yīng)時間進(jìn)行對比分析，結(jié)果如圖7 所示。

圖7 3種方法響應(yīng)時間對比分析

由圖7 可知，使用基于Spring Cloud 技術(shù)微服務(wù)應(yīng)用性能測試方法，最高響應(yīng)時間為0.014 8 s，最低響應(yīng)時間為0.011 5 s；使用基于Java 開發(fā)框架微服務(wù)應(yīng)用性能測試方法，最高響應(yīng)時間為0.015 3 s，最低響應(yīng)時間為0.012 0 s；使用基于eBPF工具微服務(wù)應(yīng)用性能測試方法，最高響應(yīng)時間為0.016 8 s，最低響應(yīng)時間為0.012 5 s，與理想情況下數(shù)值相差0.000 2 s，由此可知，使用該方法的測試結(jié)果較為精準(zhǔn)。

4 結(jié)束語

微服務(wù)是一個細(xì)粒度的面向服務(wù)架構(gòu)，具有良好的穩(wěn)定性，能夠高效準(zhǔn)確地完成任務(wù)。其采用基于域驅(qū)動的設(shè)計(jì)思想，在服務(wù)間采用REST 通信機(jī)制分別部署微服務(wù)，在不同的主機(jī)上實(shí)現(xiàn)微服務(wù)的分布式管理。在EBPF 基礎(chǔ)上，利用微服務(wù)應(yīng)用性能測試方法，建立了微服務(wù)場景的統(tǒng)一度量標(biāo)準(zhǔn)。該方法便于索引的開發(fā)和擴(kuò)展，具有相對統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)，可以從內(nèi)核中獲得索引，而且指標(biāo)粒度越細(xì)，系統(tǒng)性能分析的準(zhǔn)確度就越高。在未來應(yīng)用中，應(yīng)用微服務(wù)中的開源容器引擎，用于加速封裝、測試和部署，實(shí)現(xiàn)服務(wù)過程的虛擬化，減少項(xiàng)目部署時間。