基於Jmeter的效能壓測平臺實現
很早就想要一套屬於自己的效能壓測平臺，原因是使用了阿里雲的效能測試PTS，就挺羨慕能有一個這樣的效能測試平臺，但畢竟人家的東西我們高攀不起（要錢的），而且阿里雲的效能測試平臺是不支援多種協議的（比如我有一個專案要用websocket測試，結果人家就支援http壓測）。
說到開發自己的效能測試平臺，肯定想到的是Jmeter，因為開源的效能測試工具沒有比它更強大的了，所以第一個想到的是怎麼把它變成效能測試平臺，很多人首先想到的是通過jenkins結合jmeter，我想那也只能叫排程平臺，不能叫效能測試平臺。通過對Jmeter和Java快速開發框架的深入瞭解，我發現做一個自己的效能壓測平臺是可行的，而且網上也有人正在做。開發的過程肯定是無限的踩坑（開源的東西就這樣），相對收穫來說應該值的。以下是我針對開源的Java快速開發框架和別人實現的部分成品，再結合JMeterEngine的深入學習，梳理的平臺架構：
以下是主要的技術選型及說明：
- 核心框架：Spring Boot 1.5
- 安全框架：Apache Shiro 1.3
- 檢視框架：Spring MVC 4.3
- 持久層框架：MyBatis 3.3
- 定時器：Quartz 2.3
- 資料庫連線池：Druid 1.0 （阿里開源）
- 日誌管理：SLF4J 1.7、Log4j
- 頁面互動：Vue2.x
- 前端監控：ECharts 3.8
- 壓測核心（即JMeterEngine）：Apache JMeter 4.0
- 指令碼呼叫核心：Apache Commons Exec 1.3
- 遠端執行命令：Jcraft 0.1.54
選用的快速框架是經量級的，而且是方便快速部署的：
【renren-fast開發框架】，具體可以上網獲取：https://www.renren.io/guide/
效能測試平臺的專案結構：
stress-test ├─doc 專案SQL語句 │ ├─common 公共模組 │ ├─aspect 系統日誌 │ ├─exception 異常處理 │ ├─validator 後臺校驗 │ └─xss XSS過濾 │ ├─config 配置資訊 │ ├─modules 功能模組 │ ├─api API介面模組(APP呼叫) │ ├─job 定時任務模組 │ ├─oss 檔案服務模組 │ ├─sys 許可權模組 │ └─test 壓測模組 │ ├─RenrenApplication 專案啟動類 │ ├──resources │ ├─mapper SQL對應的XML檔案 │ ├─static 第三方庫、外掛等靜態資源 │ ├─views 專案靜態頁面 │ └─application.yml 環境配置
平臺已實現的部分功能：
（1）用例管理：
用例管理支援jmx指令碼的上傳和引數化檔案及測試附件的上傳，一個用例建立一個目錄（指令碼、引數檔案、附件、測試報告都在同一用例下儲存）。刪除用例時會自動刪除用例下所關聯的指令碼，並一併刪除已同步到各個節點的檔案。
（2）指令碼檔案管理
每個指令碼具有啟動和停止壓測執行緒的功能（具有狀態標識），每個引數化檔案或附件具有同步到各個節點的功能（同步完成後標識為同步成功）。
指令碼檔案除了啟動和停止功能，還能配置是否開啟報告生成和是否開戶前端監控，監控為echarts圖形監控，如下：
呼叫指令碼進行壓測的方法分為兩種：
| 壓測模式 | 呼叫模組 | 特點 | 優缺點 |
| 指令碼呼叫模式 | Apache Commons Exec | 相當於通過遠端執行jmeter命令呼叫指令碼，完全依賴於jmeter bin目錄 | 優點：實現簡單，無需過多程式設計； 缺點：無法多執行緒控制，無法開啟echarts監控，完全依賴本地Jmeter終端 |
| 引擎呼叫模式 | JMeterEngine | 用的是Jmeter壓測核心，通過runTest方法開啟壓測執行緒，通過stopTest方法結束壓測執行緒 | 優點：更加輕量級，多執行緒控制，支援單獨停止某個指令碼的測試，支援echarts監控，支援個性化擴充套件開發； 缺點：需要依賴更多程式設計實現 |
（3）測試報告管理
預設執行指令碼過程中，生成了CSV報告，通過【生成報告】按鈕，觸發將csv報告轉換成html DashBoard（這一步也是通過Commons Exec排程jmeter命令完成）：
（4）分散式節點管理
分散式節點管理通過Jcraft遠端執行linux命令，來啟動或是停止各節點的Jmeter-server，啟動命令格式如下：
//啟動節點
String enableResult = ssh2Util.runCommand(
"cd " + slave.getHomeDir() + "/bin/testCases/" + "\n" +
"sh " + "../jmeter-server -Djava.rmi.server.hostname="+slave.getIp());如果是禁用節點，就是通過遠端執行殺程序的命令：
ssh2Util.runCommand("ps -efww|grep -w 'jmeter-server'|grep -v grep|cut -c 9-15|xargs kill -9");這種方式挺方便，省了在多臺linux節點機上，手動去連線和啟動jmeter（分佈節點越多越顯得方便快捷）。
另外跟原來相比，分散式節點管理增加了校準功能，就是為了解決節點因為人為因素停了，而管理端不能及時的作出判斷，現在通過校準可以將後臺節點的程序狀態跟前臺同步一次（避免程序異常關閉或錯誤啟動），目前不是自動校準。因為無論是實時監聽埠還是定時校準，效率都不是最好的。以後可以嘗試在壓測過程中新增監聽機制，來實時監測節點狀態，而非壓測時段就通過手動點選校準即可，這樣會相對經濟一些。
（5）監控擴充套件（Grafana+InfluxDB）
由於我在以前的一篇文章中寫過有關Grafana+InfluxDB與Jmeter的監控（關於Jmeter長時間壓測的視覺化監控報告），可以直接拿過來整合使用。整合的方式是開啟Grafana的匿名登入（在defaults.ini中配置），到官網下一個Jmeter的監控檢視JSON模板匯入，同時以跳轉的方式將Grafana嵌入到平臺的iframe中。
var URL_IP = parent.location.host;
var URL_PORT = parent.location.port;
window.location = "http://"+URL_IP.replace(":"+URL_PORT,"")+":3000/d/joulMbxmz/apache-jmeter-dashboard?orgId=1";
另外可以將Grafana和InfluxDB及一鍵啟動指令碼與效能壓測平臺一起部署，實現在部署層面上進行整合和無縫對接使用。
寫到這我們的效能壓測平臺前期部分基本介紹完了，還有些功能未開始開發，比如像阿里雲PTS的壓測場景配置，這比較複雜，相當於是把指令碼的場景設定移到WEB介面上，另外還要結合定時器進行指令碼的靈活排程（發起壓測、結束壓測、持續時間、測試周期等），目前來看還沒想好怎麼實現。
而且目前出現了一些BUG，大部分都是由於Jmeter本身的侷限性和穩定性引起的（比如長時間壓測的監控穩定性問題），所以還任重道遠......
更正說明：寫這篇文章的時候，阿里雲的PTS剛剛能支援原生jmeter（但前提是有專案支援你花這錢），也就是能支援websocket的壓測，具體使用說明他們也提供了教程：https://help.aliyun.com/document_detail/93627.html?spm=5176.7946858.1219570.3.4ced572dQgCraE
版權宣告：本文為博主原創文章，轉載請附上博文連結！https://blog.csdn.net/smooth00/article/details/83380879