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

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

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 總結

仿真的性能壓測環境，是執行有效性能壓測的前提。

不同的壓測環境都有不同的應用場景，企業應根據自身情況進行選擇。

規模中小的公司獨立搭建一套隔離的壓測環境成本高昂，可維護性差。

云上的性能壓測，在操作、成本和維護方面，有較高的優勢。

自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。