很早就想要一套屬於自己的效能壓測平臺，原因是使用了阿里雲的效能測試PTS，就挺羨慕能有一個這樣的效能測試平臺，但畢竟人家的東西我們高攀不起（要錢的），而且阿里雲的效能測試平臺是不支援多種協議的（比如我有一個專案要用websocket測試，結果人家就支援http壓測）。

說到開發自己的效能測試平臺，肯定想到的是Jmeter，因為開源的效能測試工具沒有比它更強大的了，所以第一個想到的是怎麼把它變成效能測試平臺，很多人首先想到的是通過jenkins結合jmeter，我想那也只能叫排程平臺，不能叫效能測試平臺。通過對Jmeter和Java快速開發框架的深入瞭解，我發現做一個自己的效能壓測平臺是可行的，而且網上也有人正在做。開發的過程肯定是無限的踩坑（開源的東西就這樣），相對收穫來說應該值的。以下是我針對開源的Java快速開發框架和別人實現的部分成品，再結合JMeterEngine的深入學習，梳理的平臺架構：

該平臺已經開源（無Java經驗的測試人員慎入，以免煩擾）：https://gitee.com/smooth00/stressTestSystem

針對小白，提供了一鍵部署包：https://gitee.com/smooth00/stressTestSystem/releases，只要安裝了JDK1.8，下載安裝包stressTestSystem-min-5.1.1.rar解壓後，通過批處理指令碼就能執行壓測平臺。一鍵部署包所對應的Docker映象檔案可以直接pull到：docker pull smooth00/stresstest-system

Docker部署方案參考：https://gitee.com/smooth00/stressTestSystemDocker

以下是主要的技術選型及說明：

• 核心框架：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（現已支援5.1.1版本）
• 指令碼呼叫核心：Apache Commons Exec 1.3（棄用）
• 遠端執行命令：Ganymed build210
• 批量上傳元件：bootstrap-fileinput v4.5.2
• JVM內部快取：Guava 18.0

選用的快速框架是經量級的，而且是方便快速部署的：

【renren-fast開發框架】，具體可以上網獲取：https://www.renren.io/guide/

效能測試平臺的專案結構：

1. stress-test
2. ├─doc 專案SQL語句
3. │
4. │─lib 專案引用外部jar包（預設沒有）
5. │
6. ├─common 公共模組
7. │ ├─aspect 系統日誌
8. │ ├─exception 異常處理
9. │ ├─validator 後臺校驗
10. │ └─xss XSS過濾
11. │
12. ├─config 配置資訊
13. │
14. ├─modules 功能模組
15. │ ├─api API介面模組(APP呼叫)
16. │ ├─job 定時任務模組
17. │ ├─oss 檔案服務模組
18. │ ├─sys 許可權模組
19. │ └─test 壓測模組
20. │
21. ├─RenrenApplication 專案啟動類
22. │
23. ├──resources
24. │ ├─mapper SQL對應的XML檔案
25. │ ├─static 第三方庫、外掛等靜態資源
26. │ ├─views 專案靜態頁面
27. │ └─application.yml 環境配置

平臺已實現的部分功能：

（1）用例管理：

用例管理支援jmx指令碼的上傳和引數化檔案及測試附件的上傳，一個用例建立一個目錄（指令碼、引數檔案、附件、測試報告都在同一用例下儲存）。刪除用例時會自動刪除用例下所關聯的指令碼，並一併刪除已同步到各個節點的檔案。

（2）指令碼檔案管理

每個指令碼具有啟動和停止壓測執行緒的功能（具有狀態標識），每個引數化檔案或附件具有同步到各個節點的功能（同步完成後標識為同步成功）。

支援指令碼檔案線上修改（基於jmx檔案的模板化編輯）：

啟動指令碼可以選擇指定節點壓測，只要空閒狀態的節點都可以選擇，真正實現並行任務執行：

指令碼檔案除了啟動和停止功能，還能配置是否開啟報告生成和是否開啟前端監控，監控是echarts圖形監控，如下：

呼叫指令碼進行壓測的方法分為兩種：

另外支援將指令碼新增到任務，用的是框架本身的任務管理，加上cron表示式生成器外掛的應用，可以方便的實現指令碼的定時任務建立，這樣就能定時執行指令碼（這個是LR所不具備的功能，一般可以用於介面的自動化測試）：

（3）測試報告管理

預設執行指令碼過程中，生成了CSV報告，通過【生成報告】按鈕，觸發將csv報告轉換成html DashBoard（這一步也是通過Commons Exec排程jmeter命令完成），展示效果如下：

除了測試報告，還支援除錯報告（顯示介面請求資訊，類似於Jmeter的檢視結果樹） ，原理是呼叫xls模板將JTL結果轉為html報告（區別於測試報告是將CSV結果轉為html報告），展示效果如下：

（4）分散式節點管理

分散式節點管理通過Ganymed遠端執行linux命令，來啟動或是停止各節點的Jmeter-server，啟動命令格式如下：

1. //啟動節點
2. String enableResult = ssh2Util.runCommand(
3. "cd " + slave.getHomeDir() + "/bin/testCases/" + "\n" +
4. "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中。

1. var URL_IP = parent.location.host;
2. var URL_PORT = parent.location.port;
3. window.location = "http://"+URL_IP.replace(":"+URL_PORT,"")+":3000/d/joulMbxmz/apache-jmeter-dashboard?orgId=1";

另外可以將Grafana和InfluxDB及一鍵啟動指令碼與效能壓測平臺一起部署，實現在部署層面上進行整合和無縫對接使用。

寫到這我們的效能壓測平臺前期部分基本介紹完了，還有些功能未開始開發，比如像阿里雲PTS的壓測場景配置，這比較複雜，相當於是把指令碼的場景設定移到WEB介面上，另外還要結合定時器進行指令碼的靈活排程（發起壓測、結束壓測、持續時間、測試周期等），目前來看還沒想好怎麼實現。但是可以先實現執行緒組的線上管理：

（6）執行緒組管理

執行緒組管理的原理也不復雜，就是上傳指令碼時，通過dom4j遞迴掃描Jmx指令碼（本質上是xml）的節點，獲取執行緒組的配置節點引數，儲存入庫，然後在介面上修改和管理，改完還可以同步回Jmx指令碼（也是通過dom4j對xml進行set配置）。目前實現的管理的執行緒組類別包括預設的ThreadGroup、jp@gc - Stepping Thread Group、jp@gc - Ultimate Thread Group，這三種已經算最常用的了。執行緒組管理的目的就是免去簡單的執行緒配置（如併發數配置、執行緒組禁用）還要線下設定，設定完又要上傳，另外指令碼的執行緒組配置在平臺介面上也能一目瞭然，避免又要臨時開啟Jmeter工具進行檢視。

（7）壓測節點監控【該功能未開源】

既然有了分散式節點管理，那邊我們也可以做到對節點的分散式監控，在Influxdb-Grafana的基礎上，引入telegraf來實現；我們通過介面上，加入監控開啟和停止的按鈕，再結合節點上部署的一些批處理命令，來實現一鍵啟動監控代理。

啟動和關閉的核心程式碼如下：

1. /**
2. * 批量切換節點的監控狀態
3. */
4. @Override
5. public void updateMonitorBatchStatus(List<Long> slaveIds, Integer monitorStatus) {
6. String execStr="";
7. for (Long slaveId : slaveIds) {
8. StressTestSlaveEntity slave = queryObject(slaveId);
9. // 本機節點無需遠端操作
10. if ("127.0.0.1".equals(slave.getIp().trim())) {
11. Runtime r = Runtime.getRuntime();
12. //執行本地作業系統命令，不關心返回結果，
13. Process p = null;
14. try {
15. if(OS_NAME_LC.startsWith("windows")){
16. if (StressTestUtils.ENABLE.equals(monitorStatus))
17. execStr = "cmd.exe /c \""+StressTestUtils.getJmeterHome()+"\\telegraf\\start.cmd\" -a";
18. else
19. execStr = "cmd.exe /c taskkill /im telegraf.exe /f";
20. }else{
21. if (StressTestUtils.ENABLE.equals(monitorStatus))
22. execStr = "sh "+StressTestUtils.getJmeterHome()+"/telegraf/startUp.sh "+slave.getSlaveName();
23. else
24. execStr = "sh "+StressTestUtils.getJmeterHome()+"/telegraf/stop.sh "+slave.getSlaveName();
25. }
26. p = r.exec(execStr);
27. p.waitFor();
28. } catch (Exception e) {
29. // TODO Auto-generated catch block
30. e.printStackTrace();
31. } finally {
32. if(null!=p){
33. p.destroy();
34. p=null;
35. }
36. }
37. //更新資料庫
38. slave.setMonitorStatus(monitorStatus);
39. update(slave);
40. continue;
41. }
42. //其他節點需要SSH遠端連線
43. SSH2Utils ssh2Util = new SSH2Utils(slave.getIp(), slave.getUserName(),
44. slave.getPasswd(), Integer.parseInt(slave.getSshPort()));
45. // 避免跨系統的問題，遠端由於都時linux伺服器，則檔案分隔符統一為/，不然同步檔案會報錯。
46. String telegrafServer = slave.getHomeDir() + "/telegraf/telegraf";
47. String md5Str = ssh2Util.runCommand("md5sum " + telegrafServer + " | cut -d ' ' -f1");
48. if (!checkMD5(md5Str)) {
49. throw new RRException(slave.getSlaveName() + " 監控模組出錯！找不到telegraf啟動檔案！");
50. }
51. //如果是開啟監控
52. if (StressTestUtils.ENABLE.equals(monitorStatus)) {
53. //啟動監控
54. execStr =
55. "sh " + slave.getHomeDir() + "/telegraf/startUp.sh "
56. + slave.getSlaveName()+" "+stressTestUtils.getLocalIp();
57. }else{
58. //禁用監控
59. execStr = "sh " + slave.getHomeDir() + "/telegraf/stop.sh";
60. }
61. String enableResult = ssh2Util.runCommand(execStr);
62. logger.error(enableResult);
64. if (!enableResult.contains("telegraf")) {
65. throw new RRException(slave.getSlaveName() + " telegraf執行失敗！請先嚐試在節點機命令執行");
66. }
68. //更新資料庫
69. slave.setMonitorStatus(monitorStatus);
70. update(slave);
71. }
72. }

從程式碼我們也可以看出，我們將telegraf啟動和配置檔案都放置在jmeter節點的根目錄下，這樣能方便遠端SSH呼叫，同時我們將監控平臺的IP和節點名稱也傳送過去，並更新到telegraf.conf檔案中，這樣啟動的telegraf程序就會將監控資料發回到我們的influxdb，並通過grafana監控到。以下是監控的效果：

這樣我們就實現了對壓測機的監控（在測試過程中不對壓測機監控是不合理的，特別是CPU、記憶體、網路IO等，萬一出現測試機的效能瓶頸由於不能及時發現就會導致無用功），除了壓測機的監控，我們可以由點及面，做出一個壓測平臺的監控服務平臺，對被測服務端也進行監控。

（8）平臺日誌監控【該功能未開源】

說是日誌監控，目前只是實現了日誌的前臺展現功能，將info、debug、warn、error不同的日誌級別用顏色標識。獲取日誌的方式是開通websocket通道，用spring-boot推送實時日誌到前端頁面顯示，這種方式其實也沒什麼特別的，在網上能找到大把的實現方式，但其作用還是挺大的，平臺執行或是壓測過程中如果出現異常，直接在前臺跟蹤日誌即可，沒必要再跑到後臺伺服器上用tail命令跟蹤了，易用性變強了。

（9）支援redis快取測試資料並生成報告【該功能未開源】

通過redis快取壓測的監聽資料，並自動生成報告（並套用自定義的報告模板），在速度上要遠快於csv生成html報告，主要是為了解決測試報告檔案太大生成報告太慢的問題（利用redis叢集可以加大測試資料快取的併發性），另一個好處是將自己需要的測試結果快取到redis中，可以方便自定義更多元化的報告展現形式，提升了平臺的擴充套件性（該功能不對外開源）。

更正說明：寫這篇文章的時候，阿里雲的PTS剛剛能支援原生jmeter（但前提是有專案支援你花這錢，按壓測流量收費，並只支援外網壓測），也就是能支援websocket的壓測，具體使用說明他們也提供了教程：https://help.aliyun.com/document_detail/93627.html?spm=5176.7946858.1219570.3.4ced572dQgCraE