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

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

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

1 測(cè)試環(huán)境與實(shí)驗(yàn)場(chǎng)景

1.1 測(cè)試環(huán)境

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

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

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

后臺(tái)頁(yè)面負(fù)責(zé)執(zhí)行如下內(nèi)容：挑選信譽(yù)極好的用戶作為管理員，負(fù)責(zé)刪除不良用戶、非法文章和所有的評(píng)論任務(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ù)的支持。同時(shí)，在微服務(wù)組件中注冊(cè)這些服務(wù)，通過(guò)不同服務(wù)設(shè)備之間的相互通信，可以減少服務(wù)間的耦合[10]，從而充分提高系統(tǒng)內(nèi)聚性。

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

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

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

2.1 穩(wěn)定性分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖5 雪崩效應(yīng)

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

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

表1 單體應(yīng)用

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

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

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

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

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

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

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

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

表3 3種方式吞吐量對(duì)比分析

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

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

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

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

4 結(jié)束語(yǔ)

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