揭開神祕面紗,如何組織一次分散式壓測
越來越多的企業開始意識到分散式壓測的重要性。
隨著網際網路行業不斷髮展,系統架構越發複雜,業務場景越發多樣化,對效能測試的要求也越來越高。傳統壓測方式已經無法滿足業務和技術的發展需要,分散式壓測,就是在這樣的背景下應運而生的。
早在2006年前後,IT系統穩定性就成為了當時集中式架構的挑戰。隨著網際網路的快速興起,當時的“Unix+小型機”架構遭遇了資料爆增的衝擊。特別是線上交易、商業分析和資料庫等關鍵業務系統,在2010年前後進入了TB甚至PB級,導致傳統IT架構不堪重負,對IT系統的穩定性和可擴充套件性等提出了新要求。也就是從那時起,阿里巴巴開始了去“IOE”改造,採用X86伺服器和標準儲存與網路裝置等,重新架設高穩定和可擴充套件的分散式IT系統。
2010年後的10年,中國的網際網路公司先後進入了分散式系統的改造和建設; 2020年伴隨著新基建的崛起,更推動了電信、金融、電力、零售、醫療、教育、政府機構等各行各業IT系統基於雲端計算的分散式進化。從集中式架構到分散式架構,IT系統的穩定性不僅僅涉及到機房佈線、網路通訊、硬體部署、應用架構、資料容災等,還需要對平臺自身的精細化管控和保障,包括容量壓測與評估、全鏈路壓測等。
進入2021年,隨著企業網際網路與產業網際網路的大繁榮,為基於分散式系統的IT系統穩定性開啟了一個新賽道,分散式壓測也被提上了日程。
如何用更少的預算完成指定當前業務規模的流量高峰,是技術的永恆主題。
今天我們就在上一期效能測試的基礎上,講講分散式壓測的目的、要解決的問題以及如何組織分散式壓測等幾個方面展開討論。
分散式壓測是什麼?
要回答這個問題,我們首先要清楚分散式壓測究竟是什麼?
根據百度百科的定義,壓力測試指的是主動產生流量,從而對服務造成計算壓力,測試服務的效能與健壯性等。
根據關注角度的區分,可以分為分散式壓測(客戶端)與全鏈路壓測(服務端)。
分散式壓測指的是利用多臺機器向目標機器產生壓力,模擬幾萬使用者併發訪問,在壓測的基礎上做延伸,側重於發壓端的分散式與分散性。
從壓測本身出發,壓測的目的可分為以下四種:
1、優化:找到系統以及分散式系統中的短板,進行優化;
2、標準資源需求:現有邏輯在指定的資源下,能提供正常服務的臨界值是多少,同步給與後續資源擴充套件時以資料支援;
3、流量回放:針對真實的流量,現有服務以及資源的表型形式;
4、業務演練:對特定業務做演練,提前發現並規避問題。
全鏈路壓測一般指完全引入相關聯的系統,真實模擬線上硬體環境,更多的是以請求為核心,完全模擬真實請求流量,通過引流等方式進行場景的模擬進行壓測,更多的適用於業務鏈路較長的業務。通過全鏈路壓測發現系統服務的資料流漏斗模型比例、瓶頸業務、高頻業務、高可用節點等問題,給線上服務部署提供真實資料予以參考。
目的是考察從使用者開始訪問系統到完成全部業務的整個鏈條中,核心頁面和交易關鍵業務的實際承載能力;模擬完全的真實情況來做到提前心裡有數。驗證的最好辦法是讓事件提前發生,通過全鏈路壓測就可以提早發現問題。
分散式壓測解決什麼問題?
瞭解了基本的概念後,我們來看下分散式壓測可以解決哪些問題。
簡單來說,分散式壓測可解決以下四方面的問題:
1、單機發壓能力有限;
2、流量壓力有地域分佈等需求;
3、壓測過程中的資料指標豐富;
4、壓測結果資料彙總展示。
但是,分散式壓測在探索和應用的過程中也會面臨一些挑戰。
比如發壓機的排程問題,一方面發壓機有可能在過程中出現當機,另一方面由於發壓機的資源配置不同,分配壓力也不同,需對發壓機的真實執行情況進行監控。
再比如基礎資料的排程問題,需要處理好基礎資料的分配與排程、多資料來源之間的排程、衝突性基礎資料之間的排程以及其他相關性資料的準備與入庫,任何一個環節出錯,都有可能影響整個壓測過程。
如何組織分散式壓測?
那麼,一次完整的分散式壓測過程應該是怎樣的呢?
一般而言,分散式壓測分為6個步驟:
1、籌備:準備被壓測環境,可以是單獨的測試環境,也可以是正式環境以及確定壓測時間;
2、確定發壓曲線:可以是階梯型、線性上升型;
3、確定發壓機分佈:明確流量來源訴求;
4、明確目的:根據目的確定事務與介面;
5、準備基礎資料:相關資料的準備以及資料排程的規劃;
6、過程監控結果彙總:過程中做監控報警,壓測完成之後做資料分析,結合全鏈路的監控,比如博睿資料 Bonree Net、Bonree Server等基礎監控產品,精確定位到效能瓶頸。
需要注意的是,在組織分散式壓測的過程中,需檢測發壓端設定的流量是否都打到了目標伺服器上;如果服務架構比較複雜,有可能有其他因素導致流量缺失等;也可能對發壓資源使用預估不足,需對發壓端的資源進行監控;同時需要結合全鏈路的監控,精確定位到效能瓶頸。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70003066/viewspace-2849112/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 『MySQL』揭開索引神祕面紗MySql索引
- 揭開“QUIC”的神祕面紗UI
- 揭開計算機的神祕面紗計算機
- 揭開redux,react-redux的神祕面紗ReduxReact
- 揭開Future的神祕面紗——任務取消
- 揭開java記憶體模型的神祕面紗Java記憶體模型
- 揭開Future的神祕面紗——任務執行
- 揭開單體應用程式的神祕面紗
- 揭開DRF序列化技術的神祕面紗
- 揭開JS無埋點技術的神祕面紗JS
- 從一個Demo開始,揭開Netty的神祕面紗Netty
- 揭開NoahV智慧運維前端框架的神祕面紗運維前端框架
- 揭開Redux神祕面紗:手寫一個min-ReduxRedux
- 揭開C++移動與複製的神祕面紗C++
- 揭開SQL隱碼攻擊的神祕面紗PPT分享SQL
- 揭開React中server-side rending的神祕面紗ReactServerIDE
- 是時候揭開混合雲架構的神祕面紗了!架構
- 揭開雲原生資料管理的神祕面紗:操作層級
- 千呼萬喚始出來——iPhone 5揭開神祕面紗iPhone
- 介面自動化測試是個啥?如何開始?什麼是框架?帶你揭開神祕面紗框架
- 揭開極端程式設計的神祕面紗:結對致勝程式設計
- 圖文並茂|為你揭開微服務架構的“神祕面紗”!微服務架構
- 揭開job,scheduler,program,chain,job_class,window,window_group神祕面紗AI
- 悄悄掀起 WebAssembly 的神祕面紗Web
- 一文帶你深扒ClassLoader核心,揭開它的神祕面紗!
- 七牛雲儲存創始人:揭開GO語言的神祕面紗Go
- 揭開 Growth Hacking 的神祕面紗大結局:那些 Facebook 曾經踩過的坑
- 《吃透MQ系列》之扒開Kafka的神祕面紗MQKafka
- 揭開ThreadLocal的面紗thread
- 【C#——揭開你的面紗】C#
- 揭開華為雲CodeArts TestPlan啟發式測試設計神秘面紗!
- 萬丈高樓平地起,撥開技術神祕的面紗
- 揭開正規表示式語法的神秘面紗 (轉)
- 揭開OKR (Objectives and Key Results) 的面紗OKRObject
- 揭開 Hyperledger Cacti 專案的面紗
- 揭開周獲 18k star 開源專案的神祕面紗「GitHub 熱點速覽 v.22.28」Github
- 揭開Java記憶體管理的面紗Java記憶體
- 揭開神秘面紗——深入淺出ThreadLocalthread