大廠鍾愛的全鏈路壓測有什麼意義?四種壓測方案詳細對比分析
全鏈路壓測?
基於實際的生產業務場景和系統環境,模擬海量的用户請求和數據,對整個業務鏈路進行各種場景的測試驗證,持續發現並進行瓶頸調優,保障系統穩定性的一個技術工程。
針對業務場景越發複雜化、海量數據衝擊,發現並解決整個業務系統的可用性、擴展性以及容錯性的過程。
核心流程
全鏈路壓測實施的核心流程如下:

1 全鏈路壓測的意義
上圖是 2012 年淘寶核心業務應用關係的拓撲圖,還不包含了其他的非核心業務應用,所謂的核心業務就是和交易相關的,和錢相關的業務。這張圖大家可能看不清楚,看不清楚才是正常的,因為當時的阿里應用數量之多、應用間關係之混亂靠人工確實已經無法理清楚了。
在真實的業務場景種,每個系統的壓力都比較大,而系統之間是有相互依賴關係的,單機壓測沒有考慮到依賴環節壓力都比較大的情況,會引入一個不確定的誤差。這就好比,我們要生產一個儀表,每一個零件都經過了嚴密的測試,最終把零件組裝成一個儀表,儀表的工作狀態會是什麼樣的並不清楚。
技術角度:降低成本、提高服務可用性、技術練兵&團隊協作&快速響應;
業務角度:提升用户體驗、技術更好的服務業務、創造更多業務價值。
2 鏈路壓測方案刨析
2.1 線下壓測
顧名思義就是在測試環境進行壓測,且是針對一些重點項目這種測試手段,因為 測試環境硬件資源以及壓測數據與線上差別太大 並且 服務間依賴關係錯綜複雜 ,測試環境很難模擬且不夠穩定,壓測出來的數據指標參考價值不大,難以用測試環境得出的結果推導生產真實容量。
2.2 預生產環境壓測
這個一般是將生成環境的硬件以及軟件同步複製到與生產環境一份,然後對服務內部的外部調用接口進行攔截,然後進行壓測這樣可以評估出來生產環境的真實容量以及達到壓測的目的,但是成本非常高,需要將生產環境的硬件完全的複製一份,並未維護成本非常高,部署的時候需要同步的在預生產環境進行部署,以及壓測代碼的更改。
2.3 引流壓測
隨着業務量的不斷增長,考慮到線下測試結果的準確性,開始嘗試生產壓測,這種壓測手段,我們稱之為引流壓測。事實上沒有真正的模擬放大壓力進行測試,而是一種通過縮小在線服務集羣數的方式來放大單機處理量。比如一個業務系統的集羣有100個節點,將其中90個節點模擬下線或轉發流量到剩餘的10個節點上實施壓測。
引流壓測的弊端在於,DB承受壓力不變,上下游系統的壓力不變。壓測結果僅能代表單個應用的性能,但往往無法識別鏈路和架構級的隱患,而且在引流過程中倘若出現異常或突如其來的業務高峯,很容易造成生產故障。
2.4 全鏈路壓測
隨着微服務架構的流行, 服務按照不同的維度進行拆分 ,一次請求往往需要涉及到多個服務。 互聯網應用構建在不同的軟件模塊集上 ,這些軟件模塊, 有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千台服務器,橫跨多個不同的數據中心 。因此,就需要一些可以幫助理解系統行為、用於分析性能問題的工具,以便發生故障的時候,能夠快速定位和解決問題,但是他的缺點也很明顯就是需要的技術難度很高,需要克服 流量染色 , 數據隔離 , 日誌隔離 , 風險熔斷 等技術難題,因位在生產環境壓測,所以控制不好風險也是非常高的。
所以, 在複雜的微服務架構系統中,幾乎每一個前端請求都會形成一個複雜的分佈式服務調用鏈路 。一個請求完整調用鏈可能如下圖所示:
2.5 四種壓測方案對比
壓測效果 | 技術難度 | 機器成本 | 維護成本 | 風險 | |
---|---|---|---|---|---|
線下壓測 | 差 | 低 | 低 | 低 | 無 |
預生產壓測 | 好 | 低 | 高 | 高 | 中 |
引流壓測 | 差 | 中 | 無 | 低 | 高 |
全鏈路壓測 | 好 | 高 | 無 | 低 | 高 |
3. 全鏈路壓測概述
3.1 什麼是全鏈路壓測
基於實際的生產業務場景、生產環境,模擬海量的用户請求和數據對整個業務鏈(通常是核心業務鏈)進行壓力測試,並持續調優的過程。
3.2 解決什麼問題
解決在業務場景越發複雜化、海量數據衝擊下系統整個業務鏈的可用性、服務能力的瓶頸,以及容量規劃等問題。
3.2.3 精確的容量規劃
3.2.3.1 為什麼需要容量規劃
什麼時候增減機器、保障系統穩定性、節約成本
容量規劃的目的在於讓每一個業務系統能夠清晰地知道:什麼時候該加機器、什麼時候應該減機器?雙11等大促場景需要準備多少機器,既能保障系統穩定性、又能節約成本
3.2.3.2 容量規劃四步走
- 業務流量預估階段:通過歷史數據分析未來某一個時間點業務的訪問量會有多大
- 系統容量評估階段:初步計算每一個系統需要分配多少機器
- 容量的精調階段:通過全鏈路壓測來模擬大促時刻的用户行為,在驗證站點能力的同時對整個站點的容量水位進行精細調整
- 流量控制階段:對系統配置限流閾值等系統保護措施,防止實際的業務流量超過預估業務流量的情況下,系統無法提供正常服務流量控制階段:對系統配置限流閾值等系統保護措施,防止實際的業務流量超過預估業務流量的情況下,系統無法提供正常服務
3.3 進行全鏈路的性能監控
全鏈路性能監控 從整體維度到局部維度展示各項指標 ,將跨應用的所有調用鏈性能信息集中展現,可方便度量整體和局部性能,並且方便找到故障產生的源頭,生產上可極大縮短故障排除時間。
- 保證系統穩定性 :可能提前預估系統存在的各種問題,提前模擬高併發場景,有備無患。
- 請求鏈路追蹤,故障快速定位 :可以通過調用鏈結合業務日誌快速定位錯誤信息。
- 精準的容量評估 :能夠定位到最需要擴容的服務,幫助公司用最低的成本滿足業務的性能要求
- 真實的性能驗證 :能夠在生成環境以最真實的環境來驗證系統的真實性能。
- 數據分析,優化鏈路 :可以得到用户的行為路徑,彙總分析應用在很多業務場景。
3.4 如何展開全鏈路壓測
3.4.1 業務模型梳理
- 首先應該將核心業務和非核心業務進行拆分,確認流量高峯針對的是哪些業務場景和模塊,針對性的進行擴容準備。
- 梳理出對外的接口:使用MOCK(模擬)方式做擋板。
- 千萬不要污染正常數據:認真梳理數據處理的每一個環節,確保 mock 數據的處理結果不會寫入到正常庫裏面
3.4.2 數據模型構建
- 數據的真實性和可用性 :可以從生產環境完全移植一份當量的數據包,作為壓測的基礎數據,然後基於基礎數據,通過分析歷史數據增長趨勢,預估當前可能的數據量
- 數據隔離 :千萬千萬不要污染正常數據:認真梳理數據處理的每一個環節,可以考慮通過壓測數據隔離處理,落入影子庫,mock 對象等手段,來防止數據污染
3.4.3 壓測工具選型
使用分佈式壓測的手段來進行用户請求模擬,目前有很多的開源工具可以提供分佈式壓測的方式,比如JMeter、nGrinder、Locust等。
務模塊介紹
現在我們對整體的業務進行介紹以及演示

如果本文對您有幫助,歡迎 關注
和 點贊
`,您的支持是我堅持創作的動力。
轉載請註明出處!
- 天翼雲全場景業務無縫替換至國產原生操作系統CTyunOS!
- 以羊了個羊為例,淺談小程序抓包與響應報文修改
- 這幾種常見的 JVM 調優場景,你知道嗎?
- 如此狂妄,自稱高性能隊列的Disruptor有啥來頭?
- 為什麼要學習GoF設計模式?
- 827. 最大人工島 : 簡單「並查集 枚舉」運用題
- 手把手教你如何使用 Timestream 實現物聯網時序數據存儲和分析
- 850. 矩形面積 II : 掃描線模板題
- Java 併發編程解析 | 基於JDK源碼解析Java領域中的併發鎖,我們可以從中學習到什麼內容?
- 【手把手】光説不練假把式,這篇全鏈路壓測實踐探索
- 大廠鍾愛的全鏈路壓測有什麼意義?四種壓測方案詳細對比分析
- 寫個續集,填坑來了!關於“Thread.sleep(0)這一行‘看似無用’的代碼”裏面留下的坑。
- 857. 僱傭 K 名工人的最低成本 : 枚舉 優先隊列(堆)運用題
- Vue3 實現一個自定義toast(小彈窗)
- 669. 修剪二叉搜索樹 : 常規樹的遍歷與二叉樹性質
- 讀完 RocketMQ 源碼,我學會了如何優雅的創建線程
- 性能調優——小小的log大大的坑
- 1582. 二進制矩陣中的特殊位置 : 簡單模擬題
- elementui源碼學習之仿寫一個el-switch
- 646. 最長數對鏈 : 常規貪心 DP 運用題