本文轉(zhuǎn)載至老_張
之前有和認識的同行聊過他們?nèi)溌穳簻y的一些技術(shù)實現(xiàn)方案傻工，自己也看了很多相關的資料霞溪，這篇博客，說說自己對全鏈路壓測的理解精钮，以及整理的一些知識點威鹿。。轨香。
PS：主要羅列的是問題點忽你，以及對應的一些解決方案，僅供參考臂容。科雳。。
相關鏈接：
一脓杉、什么是全鏈路壓測
基于實際的生產(chǎn)業(yè)務場景糟秘、系統(tǒng)環(huán)境，模擬海量的用戶請求和數(shù)據(jù)對整個業(yè)務鏈進行壓力測試球散，并持續(xù)調(diào)優(yōu)的過程尿赚。
二、全鏈路壓測解決什么問題
針對業(yè)務場景越發(fā)復雜化蕉堰、海量數(shù)據(jù)沖擊下整個業(yè)務系統(tǒng)鏈的可用性凌净、服務能力的瓶頸，讓技術(shù)更好的服務業(yè)務屋讶，創(chuàng)造更多的價值冰寻。
三、面對的問題點以及解決方案
1皿渗、業(yè)務模型梳理
首先應該明確的是：全鏈路壓測針對的是現(xiàn)代越來越復雜的業(yè)務場景和全鏈路的系統(tǒng)依賴斩芭。所以首先應該將核心業(yè)務和非核心業(yè)務進行拆分轻腺，確認流量高峰針對的是哪些業(yè)務場景和模塊，
針對性的進行擴容準備划乖，而不是為了解決海量流量沖擊而所有的系統(tǒng)服務集群擴容幾十倍贬养，這樣會造成不必要的成本投入。
2迁筛、數(shù)據(jù)模型構(gòu)建
數(shù)據(jù)構(gòu)建和準備煤蚌，應該考慮這幾點問題：
①耕挨、數(shù)據(jù)的真實性和可用性
可以從生產(chǎn)環(huán)境完全移植一份當量的數(shù)據(jù)包细卧，作為壓測的基礎數(shù)據(jù)，然后基于基礎數(shù)據(jù)筒占，通過分析歷史數(shù)據(jù)增長趨勢贪庙，預估當前可能的數(shù)據(jù)量；
②翰苫、數(shù)據(jù)脫敏
基于生產(chǎn)環(huán)境的全鏈路壓測止邮，必須考慮的一點是不能產(chǎn)生臟數(shù)據(jù)，以免對生產(chǎn)造成影響奏窑，影響用戶體驗等导披，因此在數(shù)據(jù)準備時需要進行數(shù)據(jù)脫敏；
③埃唯、數(shù)據(jù)隔離
同樣撩匕，為了避免造成臟數(shù)據(jù)寫入，可以考慮通過壓測數(shù)據(jù)隔離處理墨叛，落入影子庫止毕，mock 對象等手段，來防止數(shù)據(jù)污染漠趁；
3扁凛、壓測工具選型
全鏈路壓測應對的都是海量的用戶請求沖擊，可以使用分布式壓測的手段來進行用戶請求模擬闯传，目前有很多的開源工具可以提供分布式壓測的方式谨朝，比如 jmeter、Ngrinder甥绿、locust 等字币。
可以基于這些壓測工具進行二次開發(fā)，由 Contorller 機器負責請求分發(fā)妹窖，agent 機器進行壓測纬朝，然后測試結(jié)果上傳 Contorller 機器。
考慮到壓測量較大的情況下回傳測試結(jié)果會對 agent 本身造成一定資源占用骄呼，可以考慮異步上傳共苛，甚至事務補償機制判没。
4、壓測環(huán)境搭建
全鏈路壓測都是基于生產(chǎn)環(huán)境隅茎，解決了業(yè)務模型和數(shù)據(jù)以及壓測工具選型開發(fā)澄峰，就要考慮系統(tǒng)擴容和風險規(guī)避了，比如壓測不能影響實際的生產(chǎn)業(yè)務運行辟犀，還有資源申請等俏竞。
重新搭建一套完全匹配生產(chǎn)環(huán)境的壓測環(huán)境，成本太高堂竟，且需求頻次較低魂毁，投入成本太大。
5出嘹、系統(tǒng)容量規(guī)劃
前面提到了業(yè)務拆分和流量預估席楚，在系統(tǒng)容量規(guī)劃階段，首先應該對單個接口單個服務進行基準測試税稼，調(diào)整配置參數(shù)烦秩，得到一個基準線，然后進行分布式集群部署郎仆，通過 nginx 負載均衡只祠。
至于擴容，要考慮到服務擴容和 DB 資源擴容扰肌，以及服務擴容帶來的遞減效應抛寝。
至于大流量沖擊情況下，可以考慮隊列等待狡耻、容器鎖墩剖、長連接回調(diào)、事務降級等方式來解決夷狰。
6岭皂、測試集群部署
能做全鏈路壓測的業(yè)務系統(tǒng)，基本都是分布式系統(tǒng)架構(gòu)沼头，服務集群部署和負載均衡爷绘，就是需要實現(xiàn)和考慮的技術(shù)點。
需要解決的問題有：
①进倍、服務間通信問題
一般通信方式有兩種：同步和異步土至。
同步調(diào)用：
REST（JAX-RS，Spring Boot）
RPC（Thrift, Dubbo）
異步調(diào)用：
(Kafka, Notify, MetaQ)
同步調(diào)用一致性強猾昆，但是要考慮性能和調(diào)用失敗的事務處理陶因。
異步調(diào)用的話，可以降低服務間的耦合垂蜗，提升性能體驗楷扬，但是一致性是需要解決的（分布式架構(gòu)有個 CAP 理論解幽，感興趣的可以查詢相關資料看看）。
②烘苹、負載均衡問題
需要將大流量沖擊均勻的分發(fā)給集群上的每臺機器躲株，目前比較優(yōu)秀的負載均衡服務器是 nginx，但 nginx 的部署貌似也存在一些問題镣衡，我們公司之前就遇到過訂單重復問題霜定。
③、容災問題
需要確保的一點是：當服務中的某臺或者某部分服務宕機廊鸥，可以及時的進行服務轉(zhuǎn)發(fā)望浩，而不至于連鎖反應下整個系統(tǒng)鏈路的服務掛掉（可以參考我之前的博客：容災測試）。
7黍图、數(shù)據(jù)收集監(jiān)控
壓測數(shù)據(jù)收集曾雕，需要由 agent 機回送給 Contorller 機器奴烙，但數(shù)據(jù)量過大會占用一定的資源助被，可以考慮異步實現(xiàn)測試結(jié)果回送。
至于監(jiān)控切诀，現(xiàn)在有很多優(yōu)秀的專業(yè)監(jiān)控工具揩环，比如 Nmon、Zabbix幅虑，全鏈路監(jiān)控工具 Zipkin丰滑、PinPoint 以及攜程開源的全鏈路監(jiān)控工具 CAT。
或者可以針對需要倒庵，二次開發(fā)JVM自帶的一些監(jiān)控工具褒墨，做到實時全方位監(jiān)控。
