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

全鏈路壓測解決什么問題：針對業務場景越發復雜化、海量數據沖擊下整個業務系統鏈的可用性、服務能力的瓶頸，讓技術更好的服務業務，創造更多的價值。　

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

1、業務模型梳理

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

針對性的進行擴容準備，而不是為了解決海量流量沖擊而所有的系統服務集群擴容幾十倍，這樣會造成不必要的成本投入。 

2、數據模型構建

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

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

可以從生產環境完全移植一份當量的數據包，作為壓測的基礎數據，然后基于基礎數據，通過分析歷史數據增長趨勢，預估當前可能的數據量；

②、數據脫敏

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

③、數據隔離

同樣，為了避免造成臟數據寫入，可以考慮通過壓測數據隔離處理，落入影子庫，mock對象等手段，來防止數據污染；

3、壓測工具選型

全鏈路壓測應對的都是海量的用戶請求沖擊，可以使用分布式壓測的手段來進行用戶請求模擬，目前有很多的開源工具可以提供分布式壓測的方式，比如jmeter、Ngrinder、locust等。

也可以考慮澤眾出品的性能測試工具：PerformanceRunner。

考慮到壓測量較大的情況下回傳測試結果會對agent本身造成一定資源占用，可以考慮異步上傳，甚至事務補償機制?！?nbsp;

4、壓測環境搭建

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

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

5、系統容量規劃

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

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

至于大流量沖擊情況下，可以考慮隊列等待、容器鎖、長連接回調、事務降級等方式來解決。 

6、測試集群部署

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

需要解決的問題有：

①、服務間通信問題

一般通信方式有兩種：同步和異步。

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

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

②、負載均衡問題

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

③、容災問題

需要確保的一點是：當服務中的某臺或者某部分服務宕機，可以及時的進行服務轉發，而不至于連鎖反應下整個系統鏈路的服務掛掉。　 

7、數據收集監控

壓測數據收集，需要由agent機回送給Contorller機器，但數據量過大會占用一定的資源，可以考慮異步實現測試結果回送。

更多性能測試文章推薦：

WEB性能測試怎么做？常用的WEB性能測試工具有哪些？

性能測試工具PerformanceRunner與LoadRunner有什么區別？

性能測試工具PR腳本和錄制失敗原因有哪些？