在服務數量增多到一定程度，出問題的可能性越來越大，現在各種常見的架構手段，高可用手段都是爲了提升系統的可用性，給用戶提供更好的體驗。而全鏈路壓測則相當於對服務進行一次體檢，瞭解當前系統的狀況
定義：基於線上環境和實際業務場景，通過模擬海量的用戶請求，來對整個系統鏈路進行壓力測試。
目的：
- 驗證新功能的穩定性
- 驗證峯值流量下服務的穩定性和伸縮性
- 對線上服務進行更準確的容量評估
- 找到系統瓶頸並且進行優化
壓測極限標準
- load不超過 (機器核數* 0.6)
- 網卡流量不超過網卡容量的0.6，超過的話可能延遲比較大
- 請求超時不超過請求總量的十萬分之一
- QPS不低於預估的85%，否則需要優化，或者給出合理的解釋
壓測方案
爲模擬更真實的環境，壓測機器與線上機器同等配置，仿照線上機器的部署情況部署。壓測數據儘可能採用線上真實數據。
方案一
複用線上環境壓測，在低峯期，比如凌晨3點鐘，回放讀請求，寫請求無法壓測，因爲寫請求會導致數據污染。
壓測可以採用本地日常環境，或者採用線上環境：
日常環境：要求低，如果想要效果真實，可以構建與線上服務一模一樣的配套設施，缺點是成本高
-
線上環境：完全採用線上環境，測量機器的抗壓能力，流量逐漸的分配到越來越少的服務器上，觀察10分鐘以上，直到服務器處理的極限。
- 需要強大的壓測平臺
- 立體監控系統
- 服務治理平臺
- 可參加各大公司的全鏈路壓測系統，在文末參考中。
流量複用工具：TCPcopy
方案二
方案一很難對整個集羣的進行壓測，容易以偏概全，無法評估系統的真實性能。如果想做全鏈路壓測：
儘可能構造真實數據
壓測線上真實環境
-
核心技術
-
壓測標識透傳
- 跨線程：採用InheritableThreadLocal父線程ThreadLocal中的變量傳遞給子線程，保證了壓測標識的傳遞
- 跨進程：存儲在請求的Header中，做一些標識。
-
壓測服務隔離，不能因爲壓測影響正常服務
- 根據業務需求在線上對整條鏈路創建一個壓測分組，隔離出一批機器用於壓測，在請求入口處，可以將請求進行分割
壓測數據隔離，不影響真實數據
使用影子表進行數據隔離，線上使用同一個數據庫，只是在寫入數據的時候將數據寫入到另外一張“影子表”中。
-
最後
附錄中給了很多互聯網大廠的真實案例，可以一起學習