之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇博客，說說自己對全鏈路壓測的理解，以及整理的一些知識點。。。
PS：主要羅列的是問題點，以及對應的一些解決方案，僅供參考。。。
相關鏈接：
一、什么是全鏈路壓測
基於實際的生產業務場景、系統環境，模擬海量的用戶請求和數據對整個業務鏈進行壓力測試，並持續調優的過程。
二、全鏈路壓測解決什么問題
針對業務場景越發復雜化、海量數據沖擊下整個業務系統鏈的可用性、服務能力的瓶頸，讓技術更好的服務業務，創造更多的價值。
三、面對的問題點以及解決方案
1、業務模型梳理
首先應該明確的是：全鏈路壓測針對的是現代越來越復雜的業務場景和全鏈路的系統依賴。所以首先應該將核心業務和非核心業務進行拆分，確認流量高峰針對的是哪些業務場景和模塊，
針對性的進行擴容准備，而不是為了解決海量流量沖擊而所有的系統服務集群擴容幾十倍，這樣會造成不必要的成本投入。
2、數據模型構建
數據構建和准備，應該考慮這幾點問題：
①、數據的真實性和可用性
可以從生產環境完全移植一份當量的數據包，作為壓測的基礎數據，然后基於基礎數據，通過分析歷史數據增長趨勢，預估當前可能的數據量；
②、數據脫敏
基於生產環境的全鏈路壓測，必須考慮的一點是不能產生臟數據，以免對生產造成影響，影響用戶體驗等，因此在數據准備時需要進行數據脫敏；
③、數據隔離
同樣，為了避免造成臟數據寫入，可以考慮通過壓測數據隔離處理，落入影子庫，mock對象等手段，來防止數據污染；
3、壓測工具選型
全鏈路壓測應對的都是海量的用戶請求沖擊，可以使用分布式壓測的手段來進行用戶請求模擬，目前有很多的開源工具可以提供分布式壓測的方式，比如jmeter、Ngrinder、locust等。
可以基於這些壓測工具進行二次開發，由Contorller機器負責請求分發，agent機器進行壓測，然后測試結果上傳Contorller機器。
考慮到壓測量較大的情況下回傳測試結果會對agent本身造成一定資源占用，可以考慮異步上傳，甚至事務補償機制。
4、壓測環境搭建
全鏈路壓測都是基於生產環境，解決了業務模型和數據以及壓測工具選型開發，就要考慮系統擴容和風險規避了，比如壓測不能影響實際的生產業務運行，還有資源申請等。
重新搭建一套完全匹配生產環境的壓測環境，成本太高，且需求頻次較低，投入成本太大。
5、系統容量規划
前面提到了業務拆分和流量預估，在系統容量規划階段，首先應該對單個接口單個服務進行基准測試，調整配置參數，得到一個基准線，然后進行分布式集群部署，通過nginx負載均衡。
至於擴容，要考慮到服務擴容和DB資源擴容，以及服務擴容帶來的遞減效應。
至於大流量沖擊情況下，可以考慮隊列等待、容器鎖、長連接回調、事務降級等方式來解決。
6、測試集群部署
能做全鏈路壓測的業務系統，基本都是分布式系統架構，服務集群部署和負載均衡，就是需要實現和考慮的技術點。
需要解決的問題有：
①、服務間通信問題
一般通信方式有兩種：同步和異步。
同步調用：
REST（JAX-RS，Spring Boot）
RPC（Thrift, Dubbo）
異步調用：
(Kafka, Notify, MetaQ)
同步調用一致性強，但是要考慮性能和調用失敗的事務處理。
異步調用的話，可以降低服務間的耦合，提升性能體驗，但是一致性是需要解決的（分布式架構有個CAP理論，感興趣的可以查詢相關資料看看）。
②、負載均衡問題
需要將大流量沖擊均勻的分發給集群上的每台機器，目前比較優秀的負載均衡服務器是nginx，但nginx的部署貌似也存在一些問題，我們公司之前就遇到過訂單重復問題。
③、容災問題
需要確保的一點是：當服務中的某台或者某部分服務宕機，可以及時的進行服務轉發，而不至於連鎖反應下整個系統鏈路的服務掛掉（可以參考我之前的博客：容災測試）。
7、數據收集監控
壓測數據收集，需要由agent機回送給Contorller機器，但數據量過大會占用一定的資源，可以考慮異步實現測試結果回送。
至於監控，現在有很多優秀的專業監控工具，比如Nmon、Zabbix，全鏈路監控工具Zipkin、PinPoint以及攜程開源的全鏈路監控工具CAT。
或者可以針對需要，二次開發JVM自帶的一些監控工具，做到實時全方位監控。
上面的內容，主要還是一些知識點整理和個人的一些思考，權當參考，如有錯誤或者更好的建議，可以在評論區指正，不勝感激！