考慮穩定性與響應時間的微服務應用性能測試方法

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

（1.安徽繼遠檢驗檢測技術有限公司，安徽合肥 230097；2.國網浙江省電力有限公司電力科學研究院，浙江杭州 310014）

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

1 測試環境與實驗場景

1.1 測試環境

考慮穩定性與響應時間的微服務應用性能測試是在Windows10 企業版的64 位操作系統下進行的，測試包為JMeter，開發工具為Maven3.3.9，數據庫為MySQL5.7。

1.2 實驗場景

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

后臺頁面負責執行如下內容：挑選信譽極好的用戶作為管理員，負責刪除不良用戶、非法文章和所有的評論任務[8]。

系統整體采用的微服務架構如圖1 所示。

圖1 微服務架構

由圖1 可知，微服務組采用MVC 體系結構，每一種服務都擁有獨立的數據源[9]，并可以獨立運行，不需要其他服務的支持。同時，在微服務組件中注冊這些服務，通過不同服務設備之間的相互通信，可以減少服務間的耦合[10]，從而充分提高系統內聚性。

2 微服務應用性能測試

采用JMeter 測試工具，對基于微服務應用的性能進行測試。為了使測試數據盡可能客觀，微服務主要實現了業務的功能邏輯代碼[11]，微服務系統測試結構如圖2 所示。

圖2 微服務系統測試結構

2.1 穩定性分析

關于穩定性測試，提出了基于EBPF 的微服務應用系統性能測試方法。在微服務監控節點中進行應用[12]，測試步驟如下：

步驟一：接收群集監控節點發送的控制指令。

步驟二：當該指令的事件或函數被執行時，指令需要包含要收集的數據類型信息，并收集要使用的性能度量信息。

步驟三：當執行事件或功能時，EBPF 工具收集其性能度量參數。

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

從圖3 可以看到，有效狀態機啟動時為初始化狀態，接收到報文后處于接收請求狀態，此階段的時間為接收請求時間。在發送請求時，進入發送請求狀態，發送到接收時處于結束狀態，完成后在循環中進行新的發送和接收任務。也可以假定每個節點都會收到確認信息，所有收到的消息都是嵌套的，如圖4 所示。

圖3 有效狀態機

圖4 網絡報文鏈路結構示意圖

由圖4 可知，當一個節點接收到一條消息時，該節點將其他節點發送的所有消息都保存起來，然后通過嵌套不同的消息間隔關系計算出各個網絡的消息連接情況。

2）性能指標參數還包括網絡請求處理時間、CPU 利用率、內存利用率以及對日志的讀寫。在函數執行過程中，將收集和存儲函數在每次事件或上下文切換過程中生成的函數調用堆棧，用來判斷微服務系統是否存在異常。

步驟四：采用統一格式處理性能指標參數；

步驟五：將性能度量參數發送到集群監控節點，根據應用程序能力度量參數確定微服務的穩定性。

步驟六：每星期測試一次，如果測試結果表明微服務提供商由于網絡原因不能被調用，則會導致用戶發生“串聯故障”，即“雪崩效應”，如圖5 所示。

由圖5 可知，如果服務節點調用失敗，那么系統將立即執行代碼，以提高整個系統的可用性，防止基于代碼的設置、請求失敗和超時等雪崩效應的發生。若服務器模塊通過了高壓測試，就不會出現系統錯誤和宕機故障。

圖5 雪崩效應

2.2 響應時間分析

響應時間分析需借助JMeter 測試工具，單體中共設置50 個用戶，對200 000 個樣本進行測試，測試結果如表1 所示。

表1 單體應用

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

表2 應用性能數據

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

3 測試結果與分析

從穩定性與響應時間兩個方面對微服務應用性能進行測試，微服務網絡拓撲結構如圖6 所示。

圖6 微服務網絡拓撲結構

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

基于微服務網絡拓撲結構，分別使用考慮Spring Cloud 技術微服務應用性能測試方法（W1）、考慮Java 開發框架微服務應用性能測試方法（W2）和eBPF 工具微服務應用性能測試方法（W3）對微服務吞吐量進行對比分析，結果如表3 所示。

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

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

分別使用3 種方法對微服務響應時間進行對比分析，結果如圖7 所示。

圖7 3種方法響應時間對比分析

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

4 結束語

微服務是一個細粒度的面向服務架構，具有良好的穩定性，能夠高效準確地完成任務。其采用基于域驅動的設計思想，在服務間采用REST 通信機制分別部署微服務，在不同的主機上實現微服務的分布式管理。在EBPF 基礎上，利用微服務應用性能測試方法，建立了微服務場景的統一度量標準。該方法便于索引的開發和擴展，具有相對統一的數據結構，可以從內核中獲得索引，而且指標粒度越細，系統性能分析的準確度就越高。在未來應用中，應用微服務中的開源容器引擎，用于加速封裝、測試和部署，實現服務過程的虛擬化，減少項目部署時間。