揭開神祕面紗,如何組織一次分散式壓測

博睿資料發表於2021-12-23

越來越多的企業開始意識到分散式壓測的重要性。

隨著網際網路行業不斷髮展,系統架構越發複雜,業務場景越發多樣化,對效能測試的要求也越來越高。傳統壓測方式已經無法滿足業務和技術的發展需要,分散式壓測,就是在這樣的背景下應運而生的。

早在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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章