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