服務全鏈路壓測設計

在服務數量增多到必定程度，出問題的可能性愈來愈大，如今各類常見的架構手段，高可用手段都是爲了提高系統的可用性，給用戶提供更好的體驗。而全鏈路壓測則至關於對服務進行一次體檢，瞭解當前系統的情況

定義：基於線上環境和實際業務場景，經過模擬海量的用戶請求，來對整個系統鏈路進行壓力測試。

目的：

• 驗證新功能的穩定性
• 驗證峯值流量下服務的穩定性和伸縮性
• 對線上服務進行更準確的容量評估
• 找到系統瓶頸而且進行優化

壓測極限標準

• load不超過 (機器核數* 0.6)
• 網卡流量不超過網卡容量的0.6，超過的話可能延遲比較大
• 請求超時不超過請求總量的十萬分之一
• QPS不低於預估的85%，不然須要優化，或者給出合理的解釋

壓測方案

爲模擬更真實的環境，壓測機器與線上機器同等配置，仿照線上機器的部署狀況部署。壓測數據儘量採用線上真實數據。

方案一

複用線上環境壓測，在低峯期，好比凌晨3點鐘，回放讀請求，寫請求沒法壓測，由於寫請求會致使數據污染。

壓測能夠採用本地平常環境，或者採用線上環境：

• 平常環境：要求低，若是想要效果然實，能夠構建與線上服務如出一轍的配套設施，缺點是成本高

• 線上環境：徹底採用線上環境，測量機器的抗壓能力，流量逐漸的分配到愈來愈少的服務器上，觀察10分鐘以上，直到服務器處理的極限。

  • 須要強大的壓測平臺
  • 立體監控系統
  • 服務治理平臺
  • 可參加各大公司的全鏈路壓測系統，在文末參考中。

流量複用工具：TCPcopy

方案二

方案一很難對整個集羣的進行壓測，容易以偏概全，沒法評估系統的真實性能。若是想作全鏈路壓測：

• 儘量構造真實數據

• 壓測線上真實環境

• 核心技術

  • 壓測標識透傳

    • 跨線程：採用InheritableThreadLocal父線程ThreadLocal中的變量傳遞給子線程，保證了壓測標識的傳遞
    • 跨進程：存儲在請求的Header中，作一些標識。

  • 壓測服務隔離，不能由於壓測影響正常服務

    • 根據業務需求在線上對整條鏈路建立一個壓測分組，隔離出一批機器用於壓測，在請求入口處，能夠將請求進行分割

  • 壓測數據隔離，不影響真實數據

  • 使用影子表進行數據隔離，線上使用同一個數據庫，只是在寫入數據的時候將數據寫入到另一張「影子表」中。

最後

附錄中給了不少互聯網大廠的真實案例，能夠一塊兒學習

參考

• 全鏈路壓測平臺（Quake）在美團中的實踐
• 滴滴全鏈路壓測實踐
• 有贊全鏈路壓測實戰
• 阿里中間件-全鏈路壓測武器
• 京東全鏈路壓測
• 邏輯思惟全鏈路壓測
• 餓了麼全鏈路壓測