壓測平臺在全鏈路大促壓測中的實踐 ｜ 得物技術

前言：

得物在生產環境進行壓測之前是通過在1:1還原的在單獨環境進行壓測的。這個壓測方案除了不模擬外，服務外包括資料儲存也是獨立的一套。為了降低壓測成本，同時保證壓測的高擬模擬度，我們採用了全鏈路生產環境壓測的方案。

全鏈路壓測的核心問題之一是要解決資料隔離問題。壓測的流量不能汙染線上資料。我們通過中介軟體平臺研發的fusion腳手架，在RPC、Redis、DB、MQ、跨執行緒中透傳壓測標，如果是壓測流量，產生的資料會寫入影子庫，實現了中介軟體層面可支撐全鏈路壓測的基礎能力。

之前我們是使用的一個開源的壓測平臺。但是我們經過幾年的使用發現這個平臺維護成本比較高，架構設計也不太適合得物的基礎設施。因此我們自研了得物的新壓測平臺（二開JMeter），並很好地支撐了大促壓測。自研平臺支援多種協議比如 Dubbo、HTTP、GRPC、Websocket、Java 等。並可支援多種發壓方式，如指定 QPS/TPS ，指定執行緒數壓測等等。壓測結束後，能夠自動生成全面的壓測報告資料，協助分析、排查問題。壓測平臺底層完全使用得物的基礎設施，壓測平臺使用的壓力機也全都容器化，讓發壓更穩定，成本更低。通過自建壓測平臺，實現了平臺層面的全鏈路壓測的支撐能力。

這裡著重講一下為什麼要支援 固定QPS 模式 壓測，隨著公司的業務發展，對線上穩定性方面有了更高的要求和挑戰，這勢必要求能夠摸底各個域應用的效能的瓶頸，針對線上的摸高，無疑是如履薄冰。因此按照併發數盲目的去壓力測試，很有可能造成線上故障，能夠把控壓測的流量，且很精準，結合各個域給出的 QPS/TPS 目標值壓測，很大程度減少了大促準備時間，投入人力也逐年減少，同時也減少了因壓測帶來的穩定性問題。

1. 壓測平臺功能簡介

壓測平臺為了降低壓測平臺維護成本，壓測流程提效，提升壓測的易用性和體驗性，保障壓測期間的穩定性而建設。面對當今大流量的時代背景，無疑不是一件摸底應用效能瓶頸的利器，也是一份技術保障。

新壓測平臺採用JMeter引擎，核心特色功能如下：

• 支援全鏈路高併發壓測

• 支援多協議HTTP、Dubbo、Websocket、GRPC、JDBC、Java

• 支援多種壓測模式，併發模式，吞吐量模式

• 支援內外網，全網通訪問壓測

• 支援線上指令碼施壓配置聯動更改

• 支援多種資源池模式，動態資源池即壓力機動態容器申請，即用即啟，即停即釋放的高效資源利用模式以及固定資源池模式

• 支援無主發壓模式，高效發壓破除主控機瓶頸

• 支援壓測機自監控

• 支援自動生成全面的壓測報告資料和壓測QPS&響應時間曲線圖

• 支援定時任務自動化指令碼執行

• 單筆除錯功能

2. 壓測平臺 架構 設計

整體架構和舊版開源壓測平臺對比：

系統架構設計要素	舊壓測平臺	新壓測平臺
基礎元件	JMeter(4.0版本)	JMeter(4.0版本)
叢集形式	msater-slave中心化部署	去中心化
效能	master單點存在效能瓶頸 存在多個程序，有額外開銷	無單點瓶頸，每個節點都是master節點 沒有額外程序
擴充套件性	非前後端隔離 業務對接支援較難 可水平擴充套件，但是master節點存在瓶頸（資源存在浪費）、需要開發維護ECS（容器）資源伺服器	前後端分離 支援業務對接壓測能力 深入JMeter二次開發，支援混合（併發+吞吐）、併發、吞吐等多種模式
可用性	開發需要自己維護ECS，整體業務支撐性較弱	對接得物容器，平臺開發無需維護ECS資源，做自己該做的事
伸縮性	需要手動申請容器資源	對接容器支援水平伸縮
成本	維護的程序應用較多，佔用伺服器資源	一個後管應用 容器（得物自建）動態建立隨用隨擴節省成本

3. 壓測平臺 核心 壓測 邏輯

3.1 施壓流程

該階段包括施壓前場景的建立、壓力機容器的動態建立、施壓、壓測報告上報。

壓測執行時序圖：

壓測節點的流轉：

吞吐模式限流的實現：

吞吐模式即固定QPS進行壓測，實現邏輯如下圖：

3.2 壓測生命週期

壓測生命週期大體分三個階段： 壓測前 、 壓測中 、 壓測後 ，接下來安裝這三個階段來進行講述壓測平臺在每個階段的主要工作和流程，希望能夠幫助你理解壓測邏輯和到底都做了哪些事情。

• 壓測前

壓測前的壓測平臺的準備工作：壓力機資源的預估和申請、壓測指令碼檔案JMX的開發和除錯、引數檔案的開發和上傳（上傳到壓測平臺），壓測執行緒組下介面QPS目標值的設定。

• 壓測 中

管控頁面針對上傳的JMX檔案自動填充JMeter監聽器BackendListener監聽器並設定InfluxDB時序庫例項地址進行壓測資料的收集，利用得物自建的grafana進行壓測資料的拉取進行渲染，其中監控包括：介面總請求數、總錯誤數、總QPS/TPS、介面維度QPS/TPS、壓力機維度QPS/TPS、平均RT、95lineRT進行監控繪圖直觀展示，圖如下：

• 壓測 後

壓測報告 在壓測結束後進行計算生產，在壓力機上報結束狀態心跳時候，壓測管控服務通過壓測唯一編號進行非同步獲取InfluxDB中的壓測資料，計算並存儲到MySQL，折線圖元資料資訊通過JSON檔案資訊儲存到得物自建的分散式檔案系統HDFS。

• 壓測結果

壓力機CPU平均使用率30%，記憶體平均使用率50%，自建influnDB伺服器記憶體、IO都很健康。

4. 壓測總結

壓測平臺主要解決JMeter叢集去master中心化，解決掉單點瓶頸，需要考慮三點：

首先，需要考慮叢集方式和啟動方式（這裡就不進行架構圖展示了），JMeter中心化叢集是通過配置檔案配置各個節點的IP和PORT通Java的RMI協議進行遠端啟動各個slave節點，去中心化後，沒有master節點進行管理，去除掉了叢集配置檔案，每個節點都是master節點，沒有相互依賴關係，通過傳送shell命令併發遠端啟動各個節點。

其次，要考慮儲存壓測元資料儲存DB（InfluxDB時序庫）的壓力。這點要說明一下，因為JMeter叢集上報壓測元資料資訊邏輯是通過slave節點通過Java的RMI協議上報給到Master節點（這裡也就是Master節點效能瓶頸的原因），master節點在通過配置的監聽器上報給到InfluxDB，去中心化後，不存在master-slave的概念，因此每個節點都要會上報壓測元資料到時序庫，因此influxDB存在較大的寫壓力和讀壓力，這裡需要考慮influxDB的效能優化了，如叢集化部署、效能調優等。

然後，壓測報告的收集聚合，壓測中的監控結合grafana進行定製化配置聚合指令碼語句完成，壓測報告也是同樣的原理，繼承influxdb客戶端寫聚合指令碼來進行計算儲存。 在解決了上述三個問題後，高併發的全鏈路壓測就可以根據壓測目標來進行壓力機數量的配置來滿足壓測需求了。

5.  未來展望

壓測平臺經歷多輪大促壓測的錘鍊，目前已滿足高吞吐壓測的能力。

針對後面得物壓測平臺的發展在提效、功能易用，效能自動化分析等方面，我們也做了後續規劃：

• 通過資料清洗與資料脫敏、資料放大，來構造壓測資料，以減少資料構造的壓力；

• 支援線上壓測吞吐量的修改；

• 支援線上編輯JMX主要元件（面向使用者更傻瓜容易上手，遮蔽JMeter的學習成本）；

• 支援使用者提出的其他協議壓測，eg: RocketMQ等；

• 支援壓測結果自動分析判斷介面達標率；

• 支援介面自熔斷，無需人工盯盤；

• 支援壓測預案自動化；

• 支援聯動流量錄製自動生成JMX指令碼進行壓測，能夠結合相關效能分析元件給出優化意見。

得物壓測平臺一直在持續完善和提升中，希望本文能拋磚引玉，提供壓測平臺建設方面的一些參考經驗。

*文 /史一鑫