效能壓測，是保障服務可用性和穩定性過程中，不可或缺的一環，但是有關效能壓測的體系化分享並不多。從本期開始，我們將推出《Performance Test Together》（簡稱PTT）的系列專題分享，從效能壓測的設計、實現、執行、監控、問題定位和分析、應用場景等多個緯度對效能壓測的全過程進行拆解，以幫助大家構建完整的效能壓測的理論體系，並提供有例可依的實戰經驗。

第一期：《壓測環境的設計和搭建》，專題出品人| 阿里巴巴 PTS 團隊

一般來說,保證執行效能壓測的環境和生產環境高度一致是執行一次有效效能壓測的首要原則。有時候,即算是壓測環境和生產環境有很細微的差別,都有可能導致整個壓測活動評測出來的結果不準確。

效能環境要考慮的要素

1. 系統邏輯架構

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


三層邏輯結構圖

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

更復雜的邏輯結構

以下是說明：

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

2. 物理架構

物理架構

3. 硬體、軟體和網路

• 軟體:環境中涉及到哪裡基礎軟體、中介軟體。
• 硬體:實體機/虛擬機器,單機配置(CPU、記憶體、硬碟大小),叢集規模。
• 網路:內網還是外網,網路頻寬,是否有跨網段問題,是否隔離。

軟體中對系統使用到的中介軟體有一個瞭解,不僅可以幫助設計更模擬的壓測環境,也有助於在壓測過程中,加快瓶頸,問題的定位和解決。

不同效能壓測環境優缺點對比

對比表格

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

1、低配生產環境子集-研發階段效能瓶頸發現

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

方案價值

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

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

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

如何解決
阿里內部有一套完整的系統用於支撐阿里內部每日成千上萬的研發階段的效能壓測需求。

2、同配生產環境子集-容量規劃

方案的挑戰

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

存在的問題

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

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

解決方案

想詳細瞭解,阿里容量規劃的技術演進可參考這裡。
現在隔離環境就是最新容量規劃生態中的重要基礎。隔離環境的支援，才能支撐常態化的容量規劃執行，持續不斷的改進。

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

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

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

3、生產環境複製版-雲時代的優勢

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

• 複製生產環境伺服器的架構
• 複製生產環境網路基礎環境
• 複製生產環境的所有應用分層
• 網路頻寬
• 資料庫以及所有的基礎資料集
• 負載均衡
• ......

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

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

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

解決方案
我們先看一下阿里雲的產品架構圖

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

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

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

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

在阿里雲進行生產環境複製有以下優勢：

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

生產環境-老生常談

談分散式效能壓測，就離不開全鏈路壓測技術。目前，也有不少網際網路企業開始構建自己的全鏈路壓測體系，我們將阿里的實踐濃縮成一張全鏈路壓測模型圖。

更多實踐，可以點選這裡

總結

• 模擬的效能壓測環境，是執行有效效能壓測的前提。
• 不同的壓測環境都有不同的應用場景,企業應根據自身情況進行選擇。
• 規模中小的公司獨立搭建一套隔離的壓測環境成本高昂,可維護性差。
• 雲時代的效能壓測，阿里雲上的PTS給高效壓測帶來更大的可能性。

原文連結
本文為雲棲社群原創內容，未經