如果把雙11定義爲電商公司一年一度的大考，那麼全鏈路壓測就是大考之前的一次次模擬考試，幫助要上戰場的系統查缺補漏以及進行容量驗證和規劃。
背景
微服務拆分的背景下，一個簡單地請求可能涉及到十幾個下游服務，從CDN到接入層、前端應用、後端服務、緩存、存儲、中間件，哪怕一個環節出現一點誤差，誤差在上下游經過幾層累積後會造成什麼影響誰都無法確定，也許是調用延遲，也許是請求失敗，用戶的體驗自然就無法保證。
所以我們需要建立起一套驗證機制，來驗證我們各個環節的都是符合我們預期的。驗證的最佳方法就是讓事件提前發生，如果我們的系統能夠提前經歷幾次“雙11”，容量的不確定性問題也就解決了。全鏈路壓測的誕生解決了容量的確定性問題！
核心要素
- 採集線上的真實流量作爲壓測數據：
- 省去巨大的人工成本：傳統壓測模式下，壓測數據的準備一直是老大難的問題。雙11可能涉及幾十個系統，每個系統都有幾十上百的接口。如果所有接口都要壓測，準備數據需要巨大的人工成本。如果只壓測核心接口，其它接口的隱患可能就無法發現。
- 解決數據多樣性不足：準備的壓測數據往往跟線上真實的流量模型存在差異，很可能會過多的命中cache或者數據庫緩存。
- 數據轉換：敏感數據脫敏，不符合的數據改造
- 直接在線上的真實環境進行雙11模擬
- 新搭建可對比線上環境的壓測環境，成本太大；
- 測試環境或預發環境壓測結果沒有說服力，參考價值不大
- 識別壓測流量和真實流量，不產生髒數據，並且不需要業務方改造適配（涉及的系統多且風險較大）
- 壓測流量打上標識，通過trace（鏈路追蹤中間件）向下遊系統傳遞。
- 壓測流量觸發的數據庫操作都路由到影子庫，不對線上數據庫產生影響
- 第三方系統的mock
- 有些第三方系統按照調用次數收費
- 監控
- 系統qps,耗時
- 硬件監控（cpu,內存）等
系統架構
如下圖所示，全鏈路壓測分爲基礎設施和管理端兩大部分。
基礎設施
基礎設施採用了Java動態字節碼技術，運行在jvm層，已經覆蓋了公司90%以上的應用。
TraceAgent負責記錄鏈路調用，打印日誌到磁盤上。每臺機器上都部署了我們的鏈路日誌收集程序，然後把它們存儲到ES等後端存儲中。 全鏈路壓測的數據就是通過這些日誌轉換而成，同時，基於日誌的聚合分析，也形成了我們的監控大盤。
PTS-Agent主要負責影子庫，mock等邏輯實現。所有的壓測流量都打上了壓測標識，而且通過trace傳遞，即使跨系統調用壓測標識也不會丟失。PTS-Agent在發現是壓測流量，並且配置了影子庫，就會動態修改數據庫連接，把它們路由到影子庫，而正常流量不會受到任何影響，真正實現了業務無感知。mock等功能也是判斷是否是壓測流量，是否配置了mock，執行流程如下圖：
管理端
壓測執行流程主要分爲三步： 準備壓測數據 ===> 配置壓測計劃 ===> 執行壓測任務
管理端模塊也是按照上面三個步驟劃分的
- 數據集管理：我們提供了靈活的sql，可以讓用戶自由的選擇採集，哪些應用，哪些接口，多長時間段的線上數據。
- 壓測計劃管理：爲每個壓測場景 配置 影子庫，接口mock等
- 壓測執行：配置施壓機，線程數等，以及開始和停止壓測任務實踐案例
- 數據採集：指定時間範圍 以及通過sql語法指定採集的應用以及接口
2. 配置壓測計劃
接口mock配置：我們基於鏈路數據，把需要壓測的所有接口的下游調用鏈路都分析出來，用戶可以根據我們的鏈路圖，對任何下游接口實現mock。
影子庫、mq配置：
數據轉換功能：如果採集到的誰要做進一步的處理才能使用，則使用數據轉換功能，支持js語法；
3. 壓測執行
3.1 任務的啓動與停止，線程數配置
3.2 執行過程的監控，包括QPS、響應時間、相應狀態碼、cpu和內存資源情況，
系統瓶頸定位工具
壓測只是手段，我們的目的還是希望發現系統中的瓶頸點。爲此，我們也提供了 應用拓撲、鏈路追蹤協助大家排查問題，同時也推薦開源工具async-profiler分析方法耗時情況。
應用拓撲：全局視角，快速定位下游系統瓶頸點
該系統可以展示當前系統所有的下游系統，在哪個節點耗時最長一目瞭然
鏈路追蹤：記錄所有調用，方便分析所有慢請求
未來規劃
未來，我們會朝着高可用平臺發展，不僅會滿足大家壓測種種需求，同時也將爲 故障模擬，故障演練等場景賦能，幫助大家提供故障應對能力，敬請期待。