共計 3673 個字符，預計需要花費 10 分鐘才能閱讀完成。

這篇文章主要介紹“服務器壓測環境設計和搭建的方法是什么”，在日常操作中，相信很多人在服務器壓測環境設計和搭建的方法是什么問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”服務器壓測環境設計和搭建的方法是什么”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

1. 性能環境要考慮的要素

1.1 系統邏輯架構

系統邏輯架構，即組成系統的組建，應用之間的結構，交互關系的抽象。最簡單最基本的就是三層架構。

三層邏輯結構圖

客戶層：用戶請求端。

web 層：處理客戶端所有的業務請求邏輯和服務端數據。

數據庫層：維護業務系統的數據。

更復雜的邏輯結構說明：

邏輯架構中的任意一層，有可能是在獨立的物理集群機器上，也有可能跨多個物理機器或者跟其他邏輯層共享同一個物理集群。

邏輯架構間的箭頭是數據流，不是物理網絡連接。

1.2 物理架構

下圖為物理架構圖。

1.3 硬件、軟件和網絡

軟件：環境中涉及到哪里基礎軟件、中間件。

硬件：實體機 / 虛擬機，單機配置(CPU、內存、硬盤大小)，集群規模。

網絡：內網還是外網，網絡帶寬，是否有跨網段問題，是否隔離。

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

2. 不同性能壓測環境優缺點對比

2.1 對比表格

不管哪種壓測環境方案，在落地成本，滿足需求程度上都有區別，接下來對幾種壓測環境結合在阿里的應用進行介紹。

3. 低配生產環境子集 - 研發階段性能瓶頸發現

既然是低配環境，壓出來的數據似乎完全不能用作生產環境運行的參考，但實際上，這種環境下的壓測，也是非常重要的一環。主要體現在項目研發階段的價值上。

3.1 價值

新應用上線前，應用代碼本身的瓶頸發現。代碼本身的性能問題，例如連接未釋放，線程數過多，通過低配的環境，一定時長的壓測完全可以提前發現很多。

應用維度基線數據。跑出來的數據不能給線上做參考，但是如果每次迭代，發布前，都在同一套低配環境運行性能壓測，跟低配基線數據進行對比，也能起到衡量系統迭代的時候，性能是否有提升或者下降的參考。

幫助研發進行快速的性能調優。系統越復雜的時候，發生性能問題后定位的難度會指數增加。進行過性能調優的研發都有體會，有時候調優，就是改一個配置，然后重新部署，跑壓測，看結果是不是改善了，直到找到最佳的配置。這個過程如果不能輕量起來，對于研發調優就是噩夢。

3.2 問題

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

壓測會影響測試環境的功能測試。這一點很容易理解。壓力大了，可能影響同一套測試環境的功能測試結果，所以性能壓測環境最好獨立。

依賴的基礎應用在性能測試中沒有。例如要壓測的目標業務是發貼，肯定會依賴到用戶相關的業務，用戶中心就是一個基礎應用(當然很多小型公司可能沒獨立這塊業務)。

研發階段無法快速部署要壓的分支。有一點規模的互聯網公司，一周的迭代，同一個應用可能會有多個分支，需要支持快速部署指定的分支到性能環境。

3.3 方案

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

4. 同配生產環境子集 - 容量規劃

4.1 挑戰

容量規劃是一個持續的過程，如何減少人力投入，如何才能“無人值守”。

成本和效果平衡：盡量貼近線上運行環境，同時容量規劃的數據對線上容量布置有很好的指導作用。

完全獨立不影響線上。

隨時可運行，結果可跟蹤。

4.2 問題

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

構建的環境集如何定義，規模和架構如何貼近線上。

流量如何走到隔離環境。

隔離環境寫的數據是否需要清理，如何清理?

4.3 方案

阿里容量規劃的技術演進，可參考文后資料了解詳情[1]
現在隔離環境就是最新容量規劃生態中的重要基礎。隔離環境的支持，才能支撐常態化的容量規劃運行，持續不斷的改進。

首先，提煉機器比例。基于線上核心應用的現有規模情況, 提煉出一個縮小版的完全模型。即線上機器之間的比可能是 5000:2000:1000，整體比例縮放 100 倍，在隔離環境的機器比是 50:20:10。使用這種方式，有效的保證了同線上機器同比例，同時成本上做了很好的控制。

其次，確定隔離目標流量。根據接下來線上的目標流量大小，同比例計算出隔離環境應該支撐的流量，作為隔離環境打壓測流量時的目標流量。

然后，通過壓測流量從小到目標流量探索，邊壓邊彈。

最后，收集隔離環境達到目標流量后，新的機器比例及數據。應用間的比例關系很可能已經有了改變，有的應用可能縮容，有的應用可能擴容，作為線上機器關系的參考。

當然這里面的涉及的技術細節還有很多：

全鏈路壓測新應用：整個壓測流量其實是沿用了線上壓測的全鏈路壓測機制，帶流量標，數據落影子庫的方式, 所以隔離環境寫的數據不需要特殊的處理。

環境標隔離環境：流量同時會帶上一個“環境標”，通過環境標的識別，接入層會把流量導到隔離環境，從而做到流量的環境隔離。

PTS 首創 RPS 模式施壓：在系統整體的流量數據獲取上，我們摒棄了一直依賴備受追捧的 并發量 的方式。眾所周知，業務提出來的目標一般會是，希望峰值支持 xxxx 個用戶登陸 這種，進行容量規劃的時候需要將并發的用戶數跟系統能承受的 QPS，進行一個映射關系。我們容量規劃就直接使用阿里云壓測平臺 (PTS) 的 RPS 模式，壓出來拿到的 QPS 數據，直接是系統維度的數據，不用轉換，這樣也更減少了轉換過程中的失真。

邊壓邊彈技術：在隔離環境壓測中，何時彈新機器，彈多少機器，整個過程如何控制，這里面包含了一整套完整精密的算法。整個過程示意圖如下。

5. 生產環境復制版 - 云時代的優勢

5.1 挑戰

生產環境復制版面臨的挑戰非常多：
其中，如果要對生產環境進行完全的復制，將要面臨以下挑戰：

復制生產環境服務器的架構

復制生產環境網絡基礎環境

復制生產環境的所有應用分層

網絡帶寬

數據庫以及所有的基礎數據集

負載均衡

……

5.2 問題

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

溝通協調幾乎所有的技術部門(開發、運維、網絡、IT…);

如果即用即銷毀, 那么勞民損財只用個一兩次, 成本太大;

如果持續維護，那么維護成本顯然同樣不可忽略;

所以我們很少看到有公司進行這樣的“生產環境復制”操作。小型公司可能沒那么多人力實現，大中型公司，成本就更加難以接受了。但是現在云化趨勢的潮流中，這種方案開始體現出優其越性了。

5.3 方案

我們先看一下阿里云的產品架構圖。

產品服務非常豐富，但是不太利于我們理解和復制線上環境用于壓測這個主題。具體到某一個場景的系統在阿里云的落地：

網友的云產品架構總結，可參考文后資料了解詳情

搭建一個云上應用的最小集應該需要用到：

SLB- 用來負載均衡；

ECS- 用來部署業務應用；

RDS- 用來存儲業務數據；

如果要在阿里云上復制以上線上系統。
step1 購買跟線上集群同規模同配置的 ECS，部署應用;
step2 復制線上 RDS；
step3 SLB 配置新入口，指向復制環境;
step4 開始線上壓測;

在阿里云進行生產環境復制有以下優勢：

操作便捷。可視化界面，系統所需要的組建配置安裝即可。插播一下，阿里云上的壓測服務 PTS 將來有機會提供一鍵搭建和銷毀性能環境的功能，徹底解放壓測工程師。

架構信息清晰。阿里云上有“架構感知”的功能，可以直觀繪制除業務系統在阿里云上的整體架構，準確直觀，壓測工程師不用再花很長的時間梳理系統的架構，還面臨可能不準確的問題;

即用即毀, 大大節約成本。復制一套線上環境，如果是足夠復雜的系統，使用的組建多，流量大，成本問題肯定要考慮。傳統時代搭建的成本本身就高，繼續維護和再搭建的成本同樣也高。但是云時代，就是點幾個按鈕搭建，點幾個按鈕銷毀的過程，按使用量付費，驗證完就釋放，對于資源成本的浪費可控性很好。

機器配比根據情況可自由調控：在阿里云上顯然也可以快捷進行低配、同配生產環境子集復制, 相對于非云化的系統同樣有明顯的優勢。

6. 生產環境 - 老生常談

阿里的全鏈路壓測技術已經是很成熟，并且得到很廣泛的推廣的線上壓測技術。互聯網大大小小的公司均有落地，在此只概括為一個模型圖，想知道更多細節內容的，讀者可以網上收集以下，有大量的文章詳細闡述了各自落地實施的過程。
以下是阿里經典的全鏈路壓測模型圖。

經過多年的發展，由全鏈路壓測系統演進出可對阿里以外的企業提供跨行業的通用的性能壓測服務的系統 PTS。目前 PTS 也提供流量隔離解決方案給外部企業使用。

到此，關于“服務器壓測環境設計和搭建的方法是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！