背景
去年雙十一，爲了應對零點的峯值流量衝擊，咱們在八月下旬啓動了全鏈路壓測第一次實踐。因爲從零開始，所以單獨搭建了一套和生產1:1的環境，2個月的時間，光環境成本就高達幾百萬。html
通過雙十一，壓測團隊從中汲取了很多的經驗和教訓。雙十一以後，在CTO的指導下和支持下，由基架和性能測試團隊快速的投入了全鏈路壓測平臺的研發當中。mysql
而且趁着核心系統重構，快速的接入落地，對後續的系統穩定性保障工做，邁出了堅決地一步。redis
流程導圖
梳理階段
一、系統服務梳理sql
全鏈路壓測是一個很複雜的工程，其中涉及到多個服務。對整個業務系統進行梳理，確認流量傳遞的上下游和範圍，是首先要作的事情。mongodb
二、核心鏈路梳理安全
什麼是核心鏈路？如今來看，依然是一個艱難的選擇。壓測團隊在梳理核心鏈路時，主要從以下幾方面來評估：網絡
1）是不是高頻訪問業務；框架
2）是不是強依賴的核心環節；elasticsearch
3）是否直接影響生產的交易業務；分佈式
4）參考生產實際的QPS指標爲維度；
三、外部依賴梳理
肯定核心鏈路後，要對其外部依賴進行進行梳理（好比第三方支付）。因爲全鏈路壓測在生產環境進行，所以須要對外部依賴進行mock處理，避免對生產服務形成影響。
四、中間件梳理
爲了不壓測流量對生產形成影響，產生髒數據，須要對整個流量傳遞過程當中涉及的中間件進行梳理，讓壓測流量透傳落影子庫。
壓測流量模擬在請求網關接口時候在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；
準備階段
一、接入fusion框架
全鏈路壓測基於fusion，全部中間件和規範必須按fusion統一規範使用。
二、流量模型梳理
流量模型，也能夠稱之爲流量漏斗。即外部流量從網關入口開始，在每一個調用鏈路上的變化比例。
三、mock模塊配置
對於外部依賴調用的鏈路，經過mock手段，進行對應的處理。
四、影子中間件創建
在梳理階段對全部的中間件梳理完成後，便可根據規範進行對應的中間件創建。
五、測試環境驗證
完成上述步驟，須要在測試環境驗證mock配置、流量標數據落影子庫的正確性。
六、仿真環境驗證
測試環境驗證經過後，接入仿真環境，進行聯調驗證，確保沒問題，才能開始進入壓測階段。
預熱階段
一、測試用戶生成
因爲全鏈路壓測的特殊性，所以須要造一批專門用來壓測的user數據。
二、測試數據準備
測試數據包含基礎數據和參數化數據（壓測請求傳參所用），咱們的解決方案是經過定時的job來遷移生產數據並進行脫敏。
三、外部服務關閉
因爲全鏈路壓測的特殊性，所以在壓測開始前，都會對外部服務進行服務註冊下線，保證壓測的流量不會影響生產業務。
四、分支代碼發佈
全鏈路壓測是須要進行多輪的，這個過程當中每次優化均可能涉及到代碼變動，所以在壓測開始前，須要確認最新的優化代碼分支發佈到了仿真環境。
五、網絡隔離檢查
一樣，因爲環境的特殊性，壓測前須要對各服務的隔離狀況進行確認，避免影響生產業務。
實施階段
一、單機單接口基準
單機單接口的基準壓測是必不可少的環節。經過單機單接口壓測，能夠快速排查出被測鏈路自己的性能問題，這樣有助於後續全鏈路壓測的開展和性能瓶頸定位排查。
二、單機混合鏈路
混合鏈路壓測的目的，在於驗證被測服務自己的最大容量和安全水位，爲全鏈路壓測以及上線容量評估，提供參考依據。
三、全鏈路壓測演練
全鏈路壓測，是互聯網企業系統穩定性的重要保障手段。
四、脈衝摸高測試
摸高壓測，目的是爲了驗證當前系統的最高性能表現，便於評估線上擴容，留有冗餘空間。
五、限流功能演練
限流熔斷，是服務可用性的重要保障手段。咱們採用的技術框架是sentinel集羣限流功能，並對單機、集羣限流功能進行了演練，確保功能的可用性。
總結回顧
關鍵詞：對技術&業務保持敬畏！
原文出處：https://www.cnblogs.com/imyalost/p/12524078.html