之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。。。
阿里全鏈路壓測
有讚全鏈路壓測
京東全鏈路壓測
餓了麼全鏈路壓測
一、什麼是全鏈路壓測
基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，並持續調優的過程。
二、全鏈路壓測解決什麼問題
針對業務場景越發複雜化、海量資料衝擊下整個業務系統鏈的可用性、服務能力的瓶頸，讓技術更好的服務業務，創造更多的價值。
三、面對的問題點以及解決方案
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機器，但資料量過大會占用一定的資源，可以考慮非同步實現測試結果回送。
至於監控，現在有很多優秀的專業監控工具，比如jvm自帶的jconsole、jps、jstack、jmap，前端監控工具yslow以及一些資料庫監控工具。
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。。。
阿里全鏈路壓測
有讚全鏈路壓測
京東全鏈路壓測
餓了麼全鏈路壓測
一、什麼是全鏈路壓測
基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，並持續調優的過程。
二、全鏈路壓測解決什麼問題
針對業務場景越發複雜化、海量資料衝擊下整個業務系統鏈的可用性、服務能力的瓶頸，讓技術更好的服務業務，創造更多的價值。
三、面對的問題點以及解決方案
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機器，但資料量過大會占用一定的資源，可以考慮非同步實現測試結果回送。
至於監控，現在有很多優秀的專業監控工具，比如jvm自帶的jconsole、jps、jstack、jmap，前端監控工具yslow以及一些資料庫監控工具。
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...
再談全鏈路壓測
之前的部落格，有對業內比較出名的幾家網際網路大廠的全鏈路壓測方案進行過整理和總結，傳送門 聊聊全鏈路壓測。時隔一年多，由於效能測試及相關知識的學習實踐，對其有了新的認識，這裡，再次聊聊我對全鏈路測試的理解。目前的現狀 以我現在所在的銀行業務系統來說，目前的現狀大概有這些 業務邏輯太複雜 系統龐大 子...