什么是全鏈路壓測？
相對於傳統的單接口壓測，全鏈路壓測旨在能完全模擬真實的用戶的施壓場景在生產環境或類生產環境執行的壓測。在服務器、中間件、數據庫等所有軟硬件配置上，和線上保持一致；在壓測場景上，通過線上流量錄制回放模擬真實用戶的使用場景；調用鏈路上，盡可能全鏈路調通，不做和少做mock。
原理
全鏈路壓測的原理，基本上可以用4個四字短語進行概括：流量分區、存儲隔離、參數偏移、場景模擬。
為了方便大家了解整體邏輯，盜了一個網上的圖：
流量分區
通過在壓測流量入口請求中增加壓測標志並在整個壓測鏈路上保持壓測標志來和線上真實流量區分開。具體實施方式上，采用在HTTP請求的 header部分和RPC(dubbo、thrift等）請求的protocol header部分增加一個isTest=true字段來標識壓測流量。
存儲隔離
項目中使用的數據庫、緩存和各種中間件，通過上游請求是否有壓測標志來判斷是否為壓測流量。
數據庫層面，壓測前需要將所有的生產數據庫表在導出一份影子表（數據庫資源占用量會放大一倍），壓測時根據上游請求中是否有壓測參數，判斷是走真實數據表還是影子表進行數據讀寫。
Redis等緩存方面，和數據庫類似，通過判斷請求中有無壓測標志，判斷是否走影子緩存進行數據讀寫
MQ:MQ producer傳遞壓測標志，MQ consumer獲取壓測標志后，判斷是否走數據庫的影子表進行消息讀取和寫入處理。
參數偏移
參數偏移是一種兜底策略，防止前面2步“流量分區”和“存儲隔離”出問題導致壓測流量進入了真實的生產數據庫污染線上數據（心驚肉跳的線上事故）。一般說來，就是在請求時將能唯一標識業務的某些ID，比如商品ID、訂單ID等，加上一個偏移值（一般取一個遠超業務ID長度的值，注意不要超過設置的數據庫字段長度），一旦由於壓測標志未傳或者丟失，或者存儲隔離失效導致壓測數據請求到了真實的線上庫，由於關鍵ID做了偏移，生產庫對應的ID不存在（未偏移），數據庫的更新類操作往往是無法成功的，同時也可以在代碼中通過偏移的參數作為特征值對於壓測數據寫入真實生成庫的情況進行異常捕獲或者在壓測結束后通過特征值對寫入的部分新數據進行清理。
需要注意的是，參數偏移策略，需要在導入影子表時，在執行的SQL中增加偏移值。
場景模擬
全鏈路壓測的核心思想，在於盡可能模擬用戶的真實使用情況對盡可能真實的生產環境施加壓力。基於線上流量錄制回放的施壓方式，是一種比較好的選擇，在阿里、美團等互聯網公司中被陸續使用。
通過將生產環境機器上的請求日志進行結構化存儲，http請求可以提取nginx日志（nginx需要根據流量錄制需要的參數進行配置），rpc請求可以將通過filter的日志入庫。壓測時可以根據需要，從數據庫提取出指定時間的某些符合需求的請求，通過對流量數據進行一定的預處理——比如，通過腳本將請求中的token替換成永久有效的token，對請求的參數進行偏移處理，等等——然后作為壓測流量進行回放施壓。
實施
業務梳理
基於壓測場景入口，從頭到尾梳理調用鏈路，保證流量染色有始有終，流量出口都在掌握中，確保涉及的各類存儲、中間件無遺漏，梳理結果輸出文檔，方便后續業務改造和壓測配置時使用。
業務改造
異步線程改造
針對異步線程可能會丟失壓測標志的情況，需要進行對應的業務改造，定制開發線程池，保證壓測標志透傳。
跨服務間透傳
大部分中間件支持在網絡協議傳輸中將壓測標志透傳，如果遇到不支持的中間件，需要進行定制化的業務改造。
參數反偏移
為了支持壓測請求的參數偏移，可能需要基於業務邏輯在代碼中對部分涉及影子表數據讀取的地方進行參數反偏移處理，將請求參數減掉偏移值。
壓測場景的選取
數據覆蓋分析
數據量
數據分布
鏈路覆蓋分析
核心鏈路
技術指標分析
線上訪問量
鏈路瓶頸
壓測的實施
壓測報告與調優
-------------------------------------------
壓測數據染色→日志隔離→風險熔斷→數據隔離（影子庫、影子表）
提測（確定壓測目標，指定壓測場景）→冒煙（驗證業務能力）→預熱（低流量試壓）→壓測→監控→熔斷