聊聊全鏈路壓測

以前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，本身也看了不少相關的資料，這篇博客，說說本身對全鏈路壓測的理解，以及整理的一些知識點。。。

PS：主要羅列的是問題點，以及對應的一些解決方案，僅供參考。。。

相關連接：

阿里全鏈路壓測

有贊全鏈路壓測

京東全鏈路壓測

餓了麼全鏈路壓測

滴滴全鏈路壓測解決之道

美團全鏈路壓測自動化實踐

邏輯思惟在全鏈路壓測方面的實踐

 

1、什麼是全鏈路壓測

基於實際的生產業務場景、系統環境，模擬海量的用戶請求和數據對整個業務鏈進行壓力測試，並持續調優的過程。

 

2、全鏈路壓測解決什麼問題

針對業務場景愈加複雜化、海量數據衝擊下整個業務系統鏈的可用性、服務能力的瓶頸，讓技術更好的服務業務，創造更多的價值。

 

3、面對的問題點以及解決方案

一、業務模型梳理

首先應該明確的是：全鏈路壓測針對的是現代愈來愈複雜的業務場景和全鏈路的系統依賴。因此首先應該將核心業務和非核心業務進行拆分，確認流量高峯針對的是哪些業務場景和模塊，

針對性的進行擴容準備，而不是爲了解決海量流量衝擊而全部的系統服務集羣擴容幾十倍，這樣會形成沒必要要的成本投入。

 

二、數據模型構建

數據構建和準備，應該考慮這幾點問題：

①、數據的真實性和可用性

能夠從生產環境徹底移植一份當量的數據包，做爲壓測的基礎數據，而後基於基礎數據，經過分析歷史數據增加趨勢，預估當前可能的數據量；

②、數據脫敏

基於生產環境的全鏈路壓測，必須考慮的一點是不能產生髒數據，以避免對生產形成影響，影響用戶體驗等，所以在數據準備時須要進行數據脫敏；

③、數據隔離

一樣，爲了不形成髒數據寫入，能夠考慮經過壓測數據隔離處理，落入影子庫，mock對象等手段，來防止數據污染；

 

三、壓測工具選型

全鏈路壓測應對的都是海量的用戶請求衝擊，可使用分佈式壓測的手段來進行用戶請求模擬，目前有不少的開源工具能夠提供分佈式壓測的方式，好比jmeter、Ngrinder、locust等。

能夠基於這些壓測工具進行二次開發，由Contorller機器負責請求分發，agent機器進行壓測，而後測試結果上傳Contorller機器。

考慮到壓測量較大的狀況下回傳測試結果會對agent自己形成必定資源佔用，能夠考慮異步上傳，甚至事務補償機制。

 

四、壓測環境搭建

全鏈路壓測都是基於生產環境，解決了業務模型和數據以及壓測工具選型開發，就要考慮系統擴容和風險規避了，好比壓測不能影響實際的生產業務運行，還有資源申請等。

從新搭建一套徹底匹配生產環境的壓測環境，成本過高，且需求頻次較低，投入成本太大。

 

五、系統容量規劃

前面提到了業務拆分和流量預估，在系統容量規劃階段，首先應該對單個接口單個服務進行基準測試，調整配置參數，獲得一個基準線，而後進行分佈式集羣部署，經過nginx負載均衡。

至於擴容，要考慮到服務擴容和DB資源擴容，以及服務擴容帶來的遞減效應。

至於大流量衝擊狀況下，能夠考慮隊列等待、容器鎖、長鏈接回調、事務降級等方式來解決。

 

六、測試集羣部署

能作全鏈路壓測的業務系統，基本都是分佈式系統架構，服務集羣部署和負載均衡，就是須要實現和考慮的技術點。

須要解決的問題有：

①、服務間通訊問題

通常通訊方式有兩種：同步和異步。

同步調用：

REST（JAX-RS，Spring Boot）

RPC（Thrift, Dubbo）

異步調用：

(Kafka, Notify, MetaQ)

同步調用一致性強，可是要考慮性能和調用失敗的事務處理。

異步調用的話，能夠下降服務間的耦合，提高性能體驗，可是一致性是須要解決的（分佈式架構有個CAP理論，感興趣的能夠查詢相關資料看看）。

②、負載均衡問題

須要將大流量衝擊均勻的分發給集羣上的每臺機器，目前比較優秀的負載均衡服務器是nginx，但nginx的部署貌似也存在一些問題，咱們公司以前就遇到過訂單重複問題。

③、容災問題

須要確保的一點是：當服務中的某臺或者某部分服務宕機，能夠及時的進行服務轉發，而不至於連鎖反應下整個系統鏈路的服務掛掉（能夠參考我以前的博客：容災測試）。

 

七、數據收集監控

壓測數據收集，須要由agent機回送給Contorller機器，但數據量過大會佔用必定的資源，能夠考慮異步實現測試結果回送。

至於監控，如今有不少優秀的專業監控工具，好比Nmon、Zabbix，全鏈路監控工具Zipkin、PinPoint以及攜程開源的全鏈路監控工具CAT。

或者能夠針對須要，二次開發JVM自帶的一些監控工具，作到實時全方位監控。

 

上面的內容，主要仍是一些知識點整理和我的的一些思考，權當參考，若有錯誤或者更好的建議，能夠在評論區指正，不勝感激！