背景
去年雙十一，為了應對零點的峰值流量沖擊，我們在八月下旬啟動了全鏈路壓測第一次實踐。由於從零開始，因此單獨搭建了一套和生產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集群限流功能，並對單機、集群限流功能進行了演練，確保功能的可用性。
總結回顧
關鍵詞：對技術&業務保持敬畏！