天天看點

如何做好性能壓測:壓測環境的設計和搭建

作者:霍格沃茲測試

性能壓測,是保障服務可用性和穩定性過程中,不可或缺的一環。我們将從性能壓測的設計、實作、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解,以幫助大家建構完整的性能壓測的理論體系,并提供有例可依的實戰。

01 性能環境要考慮的要素

系統邏輯架構,即組成系統的元件、應用之間的結構、互動關系的抽象。最簡單最基本的就是這三層架構。 三層邏輯結構圖

  • 客戶層:使用者請求端。
  • Web層:處理用戶端所有的業務請求邏輯和服務端資料。
  • 資料庫層:維護業務系統的資料。

更複雜的邏輯結構

  • 邏輯架構中的任意一層,有可能是在獨立的實體叢集機器上,也有可能跨多個實體機器或者跟其他邏輯層共享同一個實體叢集。
  • 邏輯架構間的箭頭是資料流,不是實體網絡連接配接。

實體架構圖

  • 軟體:環境中涉及到哪些基礎軟體、中間件。
  • 硬體:實體機/虛拟機,單機配置(CPU、記憶體、硬碟大小),叢集規模。
  • 網絡:内網還是外網,網絡帶寬,是否有跨網段問題,是否隔離。

軟體中對系統使用到的中間件有一個了解,不僅可以幫助設計更仿真的壓測環境,也有助于在壓測過程中,加快瓶頸、問題的定位和解決。

02 不同性能壓測環境的優缺點對比

我們通過表格的形式以下 4 個壓測環境方案在使用場景、優缺點、成本、阿裡雲及其客戶的應用情況做了對比。

從表格中,我們可以看待,不管是哪種壓測環境方案,在落地成本,滿足需求程度上都是有所差別的,接下來,我們結合在阿裡/阿裡雲客戶的應用情況,對這 4 種壓測環境進行介紹。

方案價值 既然是低配環境,壓出來的資料似乎完全不能用作生産環境運作的參考,但實際上,這種環境下的壓測,也是非常重要的一環。主要展現在項目研發階段的價值上。

  • 新應用上線前,應用代碼本身的瓶頸發現。代碼本身的性能問題,例如連接配接未釋放,線程數過多,通過低配的環境,一定時長的壓測完全可以提前發現很多。
  • 應用次元基線資料。跑出來的資料不能給線上做參考,但是如果每次疊代,釋出前,都在同一套低配環境運作性能壓測,跟低配基線資料進行對比,也能起到衡量系統疊代的時候,性能是否有提升或者下降的參考。
  • 幫助研發進行快速的性能調優。系統越複雜的時候,發生性能問題後定位的難度會指數增加。進行過性能調優的研發都有體會,有時候調優,就是改一個配置,然後重新部署,跑壓測,看結果是不是改善了,直到找到最佳的配置。這個過程如果不能輕量起來,對于研發調優就是噩夢。

存在的問題: 建構低配環境,可以是普通的測試環境,和線上完全隔離。但是要解決以下問題:

  • 壓測會影響測試環境的功能測試。這一點很容易了解。壓力大了,可能影響同一套測試環境的功能測試結果,是以性能壓測環境最好獨立。
  • 依賴的基礎應用在性能測試中沒有。例如要壓測的目标業務是發貼,肯定會依賴到使用者相關的業務,使用者中心就是一個基礎應用(當然很多小型公司可能沒獨立這塊業務)。
  • 研發階段無法快速部署要壓的分支。有一點規模的網際網路公司,一周的疊代,同一個應用可能會有多個分支,需要支援快速部署指定的分支到性能環境。

阿裡内部有一套完整的系統用于支撐集團每日成千上萬的研發階段的性能壓測需求。

方案價值

  • 容量規劃是一個持續的過程,如何減少人力投入,如何才能“無人值守”。
  • 成本和效果平衡:盡量貼近線上運作環境,同時容量規劃的資料對線上容量布置有很好的指導作用。
  • 完全獨立不影響線上。
  • 随時可運作,結果可跟蹤。

容量規劃不是直接在生産環境進行的,因為生産環境的最終容量配比,是參考自容量規劃産出的資料。在生産環境進行的壓測,是最後的驗收階段,在容量規劃完成之後。提供一套獨立的的生産環境子集-隔離環境,用于容量規劃要解決的問題:

  • 建構的環境集如何定義,規模和架構如何貼近線上。
  • 流量如何走到隔離環境。
  • 隔離環境寫的資料是否需要清理,如何清理?

想詳細了解阿裡容量規劃的技術演進,可參考:這裡。

隔離環境就是最新容量規劃生态中的重要基礎。隔離環境的支援,才能支撐常态化的容量規劃運作,持續不斷的改進。

  • 首先,提煉機器比例。基于線上核心應用的現有規模情況,提煉出一個縮小版的完全模型。即線上機器之間的比可能是5000:2000:1000,整體比例縮放100倍,在隔離環境的機器比是50:20:10。使用這種方式,有效的保證了同線上機器同比例,同時成本上做了很好的控制。
  • 其次,确定隔離目标流量。根據接下來線上的目标流量大小,同比例計算出隔離環境應該支撐的流量,作為隔離環境打壓測流量時的目标流量。
  • 然後,通過壓測流量從小到目标流量探索,邊壓邊彈。
  • 最後,收集隔離環境達到目标流量後,新的機器比例及資料。應用間的比例關系很可能已經有了改變,有的應用可能縮容,有的應用可能擴容,作為線上機器關系的參考。

當然這裡面的涉及的技術細節還有很多:

  • 全鍊路壓測新應用:整個壓測流量其實是沿用了線上壓測的全鍊路壓測機制,帶流量标,資料落影子庫的方式,是以隔離環境寫的資料不需要特殊的處理。
  • 環境标隔離環境:流量同時會帶上一個“環境标”,通過環境标的識别,接入層會把流量導到隔離環境,進而做到流量的環境隔離。
  • "RPS"模式施壓:在系統整體的流量資料擷取上,我們摒棄了一直以來備受追捧的"并發量"的方式。衆所周知,業務提出來的目标一般會是,"希望峰值支援xxxx個使用者登陸"這種,進行容量規劃的時候需要将并發的使用者數跟系統能承受的QPS,進行一個映射關系。我們容量規劃就直接使用阿裡雲壓測平台(PTS)的"RPS"模式,壓出來拿到的QPS資料,直接是系統次元的資料,不用轉換,這樣也更減少了轉換過程中的失真。
  • 邊壓邊彈技術:在隔離環境壓測中,何時彈新機器,彈多少機器,整個過程如何控制,這裡面包含了一整套完整精密的算法。整個過程示意圖如下。

生産環境複制版面臨的挑戰非常多。其中,如果要對生産環境進行完全的複制,将要面臨以下挑戰:

  • 複制生産環境伺服器的架構
  • 複制生産環境網絡基礎環境
  • 複制生産環境的所有應用分層
  • 網絡帶寬
  • 資料庫以及所有的基礎資料集
  • 負載均衡

對于傳統時代的壓測工程師來說,這樣一系列的操作,就是新搭建一套“影子系統”了,看起來有點像不可能完成的任務。要完成上述任務,壓測工程師面臨巨大的挑戰:

  • 溝通協調幾乎所有的技術部門(開發、運維、網絡、IT…);
  • 如果即用即銷毀,那麼勞民損财隻用個一兩次,成本太大;
  • 如果持續維護,那麼維護成本顯然同樣不可忽略;

是以我們很少看到有公司進行這樣的“生産環境複制”操作。小型公司可能沒那麼多人力實作,大中型公司,成本就更加難以接受了。但是現在雲化趨勢的潮流中,這種方案有其自身的先天優勢。

我們先看一下雲上的産品架構圖:

産品服務非常豐富,但是不太利于我們了解和複制線上環境用于壓測這個主題。具體到某一個場景的系統在阿裡雲的落地:

搭建一個雲上應用的最小集應該需要用到:

  • SLB - 用來負載均衡;
  • ECS - 用來部署業務應用;
  • RDS - 用來存儲業務資料;

如果要在雲上複制以上線上系統,隻需:

Step1:購買跟線上叢集同規模同配置的ECS,部署應用; Step2:複制線上RDS; Step3:SLB配置新入口,指向複制環境; Step4:開始線上壓測;

在雲上進行生産環境複制有以下優勢:

  • 操作便捷。可視化界面,系統所需要的組建配置安裝即可。
  • 即用即毀,節約成本。複制一套線上環境,如果是足夠複雜的系統,使用的元件多,流量大,成本問題肯定要考慮。傳統時代搭建的成本本身就高,繼續維護和再搭建的成本同樣也高。但是雲時代,就是點幾個按鈕搭建,點幾個按鈕銷毀的過程,按使用量付費,驗證完就釋放,對于資源成本的浪費可控性很好。
  • 機器配比根據情況可自由調控。在雲上顯然也可以快捷進行低配、同配生産環境子集複制,相對于非雲化的系統同樣有明顯的優勢。
  • 架構資訊清晰。如果雲端提供了“架構感覺”的功能,那麼可以直覺繪制除業務系統在雲上的整體架構,準确直覺,壓測工程師不用再花很長的時間梳理系統的架構,還面臨可能不準确的問題。

03 生産環境 - 老生常談

談分布式性能壓測,就離不開全鍊路壓測技術。目前,也有不少網際網路企業開始建構自己的全鍊路壓測體系,我們将阿裡的實踐濃縮成一張全鍊路壓測模型圖。

04 總結

  • 仿真的性能壓測環境,是執行有效性能壓測的前提。
  • 不同的壓測環境都有不同的應用場景,企業應根據自身情況進行選擇。
  • 規模中小的公司獨立搭建一套隔離的壓測環境成本高昂,可維護性差。
  • 雲上的性能壓測,在操作、成本和維護方面,有較高的優勢。