眾所周知，應用的服務狀態除了會受到自身穩定性的影響，還會受到流量等環境因素的影響，并且影響面會繼續傳遞到上下游，哪怕一個環節出現一點誤差，誤差在上下游經過幾層累積后會造成什么影響誰都無法確定。

保障服務的可用性和穩定性是技術團隊面臨的首要任務，也是技術難題之一。在實際生產環境中，用戶的訪問行為一旦發生，從CDN到接入層、前端應用、后端服務、緩存、存儲、中間件整個鏈路都面臨著不確定的流量，無論是公有云、專有云、混合云還是自建IDC，全局的瓶頸識別、業務整體容量摸底和規劃都需要高仿真的全鏈路壓測來檢驗。這里的不確定的流量指的是某個大促活動、常規高并發時間段以及其他規劃外的場景引起的不規則、大小未知的流量。

因此，在生產環境里建立起一套驗證機制，來驗證各個生產環節都是能經受住各類流量的訪問，成為保障服務的可用性和穩定性的重中之重。最佳的驗證方法就是讓事件提前發生，即讓真實的流量來訪問生產環境，實現全方位的真實業務場景模擬，確保各個環節的性能、容量和穩定性均做到萬無一失，這就是全鏈路壓測的誕生背景，也是將性能測試進行全方位的升級，使其具備“預見能力”。

可見，全鏈路壓測做得好，遇到真實環境的流量，系統僅僅只是再經歷一次已經被反復驗證過的場景，再考一遍做“做過的考題”，不出問題在意料之中將成為可能。

壓測的核心要素

實施完整的業務壓測，路徑很重要。要達成精準衡量業務承接能力的目標，業務壓測就需要做到一樣的線上環境、一樣的用戶規模、一樣的業務場景、一樣的業務量級和一樣的流量來源，讓系統提前進行“模擬考”，從而達到精準衡量業務模型實際處理能力的目標，其核心要素是：壓測環境、壓測基礎數據、壓測流量（模型、數據）、流量發起、掌控和問題定位。

壓測環境和壓測基礎數據

生產環境上基礎數據基本分為兩種方式：

一種是數據庫層面不需要做改造，直接基于基礎表里的測試賬戶（相關的數據完整性也要具備）進行，壓測之后將相關的測試產生的流水數據清除（清除的方式可以固化SQL腳本或者落在系統上）；

另一種就是壓測流量單獨打標（如單獨定義的Header），然后業務處理過程中識別這個標并傳遞下去，包括異步消息和中間件，最終落到數據庫的影子表或者影子庫中。這種方式詳見阿里的全鏈路壓測實踐，我們也是選用了這種方式。此外，生產環境的壓測盡量在業務低峰期進行從而避免影響生產的業務。

相關閱讀：

實施全鏈路壓測的關鍵點有哪些？全鏈路壓測流程詳解

什么是全鏈路壓測?全鏈路壓測怎么做？