背景

去年雙十一，為了應對零點的峰值流量衝擊，我們在八月下旬啟動了全鏈路壓測第一次實踐。由於從零開始，因此單獨搭建了一套和生產1:1的環境，2個月的時間，光環境成本就高達幾百萬。

經過雙十一，壓測團隊從中汲取了不少的經驗和教訓。雙十一之後，在CTO的指導下和支援下，由基架和效能測試團隊快速的投入了全鏈路壓測平臺的研發當中。

並且趁著核心系統重構，快速的接入落地，對後續的系統穩定性保障工作，邁出了堅定地一步。

流程導圖

梳理階段

1、系統服務梳理

全鏈路壓測是一個很複雜的工程，其中涉及到多個服務。對整個業務系統進行梳理，確認流量傳遞的上下游和範圍，是首先要做的事情。

2、核心鏈路梳理

什麼是核心鏈路？現在來看，依然是一個艱難的選擇。壓測團隊在梳理核心鏈路時，主要從如下幾方面來評估：

1）是否是高頻訪問業務；

2）是否是強依賴的核心環節；

3）是否直接影響生產的交易業務；

4）參考生產實際的QPS指標為維度；

3、外部依賴梳理

確定核心鏈路後，要對其外部依賴進行進行梳理（比如第三方支付）。由於全鏈路壓測在生產環境進行，因此需要對外部依賴進行mock處理，避免對生產服務造成影響。

4、中介軟體梳理

為了避免壓測流量對生產造成影響，產生髒資料，需要對整個流量傳遞過程中涉及的中介軟體進行梳理，讓壓測流量透傳落影子庫。

壓測流量模擬在請求閘道器介面時候在header中帶上:x-infr-flowtype=PT，各個中介軟體路由邏輯如下：

mysql：影子庫；

redis：影子key，字首ptshadow_；

mongodb：影子collection,字首ptshadow_；

kafka：不分topic，下游路由會進行相應路由；

rocketmq：不分topic，下游路由會進行相應路由；

hbase：影子namespace,字首ptshadow_；

elasticsearch：影子索引，字首ptshadow_；

分散式鎖fusion-distributed-locks：影子key，字首ptshadow；

準備階段

1、接入fusion框架

全鏈路壓測基於fusion，所有中介軟體和規範必須按fusion統一規範使用。

2、流量模型梳理

流量模型，也可以稱之為流量漏斗。即外部流量從閘道器入口開始，在每個呼叫鏈路上的變化比例。

3、mock模組配置

對於外部依賴呼叫的鏈路，通過mock手段，進行對應的處理。

4、影子中介軟體建立

在梳理階段對所有的中介軟體梳理完成後，即可根據規範進行對應的中介軟體建立。

5、測試環境驗證

完成上述步驟，需要在測試環境驗證mock配置、流量標資料落影子庫的正確性。

6、模擬環境驗證

測試環境驗證通過後，接入模擬環境，進行聯調驗證，確保沒問題，才能開始進入壓測階段。

預熱階段

1、測試使用者生成

由於全鏈路壓測的特殊性，因此需要造一批專門用來壓測的user資料。

2、測試資料準備

測試資料包含基礎資料和引數化資料（壓測請求傳參所用），我們的解決方案是通過定時的job來遷移生產資料並進行脫敏。

3、外部服務關閉

由於全鏈路壓測的特殊性，因此在壓測開始前，都會對外部服務進行服務註冊下線，保證壓測的流量不會影響生產業務。

4、分支程式碼釋出

全鏈路壓測是需要進行多輪的，這個過程中每次優化都可能涉及到程式碼變更，因此在壓測開始前，需要確認最新的優化程式碼分支釋出到了模擬環境。

5、網路隔離檢查

同樣，由於環境的特殊性，壓測前需要對各服務的隔離情況進行確認，避免影響生產業務。

實施階段

1、單機單介面基準

單機單介面的基準壓測是必不可少的環節。通過單機單介面壓測，可以快速排查出被測鏈路本身的效能問題，這樣有助於後續全鏈路壓測的開展和效能瓶頸定位排查。

2、單機混合鏈路

混合鏈路壓測的目的，在於驗證被測服務本身的最大容量和安全水位，為全鏈路壓測以及上線容量評估，提供參考依據。

3、全鏈路壓測演練

全鏈路壓測，是網際網路企業系統穩定性的重要保障手段。

4、脈衝摸高測試

摸高壓測，目的是為了驗證當前系統的最高效能表現，便於評估線上擴容，留有冗餘空間。

5、限流功能演練

限流熔斷，是服務可用性的重要保障手段。我們採用的技術框架是sentinel叢集限流功能，並對單機、叢集限流功能進行了演練，確保功能的可用性。

總結回顧

關鍵詞：對技術&業務保持敬畏！

&n