阿里巴巴高可用技術專家襄玲：壓測環境的設計和搭建

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

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

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

性能環境要考慮的要素

1. 系統邏輯架構

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


三層邏輯結構圖

• 客戶層:用戶請求端。
• web層:處理客戶端全部的業務請求邏輯和服務端數據。
• 數據庫層:維護業務系統的數據。

更復雜的邏輯結構

如下是說明：

• 邏輯架構中的任意一層，有多是在獨立的物理集羣機器上，也有可能跨多個物理機器或者跟其餘邏輯層共享同一個物理集羣
• 邏輯架構間的箭頭是數據流，不是物理網絡鏈接。

2. 物理架構

物理架構

3. 硬件、軟件和網絡

• 軟件:環境中涉及到哪裏基礎軟件、中間件。
• 硬件:實體機/虛擬機,單機配置(CPU、內存、硬盤大小),集羣規模。
• 網絡:內網仍是外網,網絡帶寬,是否有跨網段問題,是否隔離。

軟件中對系統使用到的中間件有一個瞭解,不只能夠幫助設計更仿真的壓測環境,也有助於在壓測過程當中,加快瓶頸,問題的定位和解決。

不一樣性能壓測環境優缺點對比

對比表格

壓測環境方案	適用場景	優勢	缺點	成本	阿里及阿里雲客戶應用狀況
生產環境子集,少許服務器,低配置	項目開發交付初期,對應用自己進行性能問題探測	1.基於已有的測試環境搭建,相對難度小 2.成本較低	1.不徹底仿真,沒法壓到全鏈路的問題,基礎設施的瓶頸問題	低	阿里內部有一套獨立完整的線下性能壓測環境,與應用發佈管理系統打通,被大量應用於項目開發前期的性能瓶頸探測場景
生產環境子集,少許服務器,同配置	服務器規模按照生產環境規模縮放,適用於容量探測	相比第一種壓測結果更可信	1.按比例縮放的環境,壓測結果也不能徹底可信 2.底層基礎設施的問題可能遺漏	較低	阿里內部智能容量規劃系統所依賴的環境就是這種,按比例縮放的同配置壓測環境
生產環境徹底複製版	最理想的壓測環境	1.壓測效果可以保證 2.不受時間限制,隨時可壓 3.徹底不影響生產環境的數據以及用戶訪問	1.成本相對高 2.單憑壓測人員搭建,複雜度高 3.存在後續維護成本	高	阿里雲上,PTS已有客戶使用該複製環境進行全仿真的性能壓測。阿里雲上快速複製系統同樣的環境用於壓測,操做簡單快捷
生產環境	評測生產環境性能的最直接真實的	1.壓測結果易於被承認。2.節約成本 3.壓測基礎設施易於部署	1.影響線上真實的用戶訪問,因此須要在業務低谷進行 2.數據寫入須要想辦法進行隔離	較低	電商系的全鏈路壓測,基於真實的線上生產環境進行

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

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

既然是低配環境,壓出來的數據彷佛徹底不能用做生產環境運行的參考,但實際上,這種環境下的壓測,也是很是重要的一環。主要體如今項目研發階段的價值上。

方案價值

• 新應用上線前,應用代碼自己的瓶頸發現。代碼自己的性能問題,例如鏈接未釋放,線程數過多,經過低配的環境,必定時長的壓測徹底能夠提早發現不少。
• 應用維度基線數據。跑出來的數據不能給線上作參考,可是若是每次迭代,發佈前,都在同一套低配環境運行性能壓測,跟低配基線數據進行對比,也能起到衡量系統迭代的時候,性能是否有提高或者降低的參考。
• 幫助研發進行快速的性能調優。系統越複雜的時候,發生性能問題後定位的難度會指數增長。進行過性能調優的研發都有體會,有時候調優,就是改一個配置,而後從新部署,跑壓測,看結果是否是改善了,直到找到最佳的配置。這個過程若是不能輕量起來,對於研發調優就是噩夢。

存在的問題
構建低配環境,能夠是普通的測試環境,跟線上徹底隔離。可是要解決如下問題

• 壓測會影響測試環境的功能測試。這一點很容易理解。壓力大了,可能影響同一套測試環境的功能測試結果,因此性能壓測環境最好獨立。
• 依賴的基礎應用在性能測試中沒有。例如要壓測的目標業務是發貼,確定會依賴到用戶相關的業務,用戶中心就是一個基礎應用(固然不少小型公司可能沒獨立這塊業務)。
• 研發階段沒法快速部署要壓的分支。有一點規模的互聯網公司,一週的迭代,同一個應用可能會有多個分支,須要支持快速部署指定的分支到性能環境。

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

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

方案的挑戰

• 容量規劃是一個持續的過程,如何減小人力投入,如何才能「無人值守」。
• 成本和效果平衡:儘可能貼近線上運行環境,同時容量規劃的數據對線上容量佈置有很好的指導做用。
• 徹底獨立不影響線上。
• 隨時可運行,結果可跟蹤。

存在的問題

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

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

解決方案

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

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

固然這裏面的涉及的技術細節還有不少:

• 全鏈路壓測新應用：整個壓測流量實際上是沿用了線上壓測的全鏈路壓測機制,帶流量標,數據落影子庫的方式, 因此隔離環境寫的數據不須要特殊的處理。
• 環境標隔離環境：流量同時會帶上一個「環境標」,經過環境標的識別,接入層會把流量導到隔離環境,從而作到流量的環境隔離。
• PTS獨創"RPS"模式施壓：在系統總體的流量數據獲取上,咱們摒棄了一直依賴備受追捧的"併發量"的方式。衆所周知,業務提出來的目標通常會是,"但願峯值支持xxxx個用戶登錄"這種,進行容量規劃的時候須要將併發的用戶數跟系統能承受的QPS,進行一個映射關係。咱們容量規劃就直接使用阿里雲壓測平臺(PTS)的"RPS"模式,壓出來拿到的QPS數據,直接是系統維度的數據,不用轉換,這樣也更減小了轉換過程當中的失真。
• 邊壓邊彈技術：在隔離環境壓測中,什麼時候彈新機器,彈多少機器,整個過程如何控制,這裏麪包含了一整套完整精密的算法。整個過程示意圖以下。

三、生產環境複製版-雲時代的優點

面臨的挑戰
生產環境複製版面臨的挑戰很是多：
其中,若是要對生產環境進行徹底的複製,將要面臨如下挑戰

• 複製生產環境服務器的架構
• 複製生產環境網絡基礎環境
• 複製生產環境的全部應用分層
• 網絡帶寬
• 數據庫以及全部的基礎數據集
• 負載均衡
• ......

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

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

因此咱們不多看到有公司進行這樣的「生產環境複製」操做。小型公司可能沒那麼多人力實現,大中型公司，成本就更加難以接受了。可是如今雲化趨勢的潮流中,這種方案開始體現出優其越性了。

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

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

圖片出處：https://rensanning.iteye.com/blog/2303440

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

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

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


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

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

   

生產環境-老生常談

談分佈式性能壓測，就離不開全鏈路壓測技術。目前，也有很多互聯網企業開始構建本身的全鏈路壓測體系，咱們將阿里的實踐濃縮成一張全鏈路壓測模型圖。

更多實踐，能夠點擊這裏

總結

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

本文做者：

襄玲(花名)：阿里巴巴技術專家，PTS 研發，近期主導整理和推進雲時代性能壓測的思想和標準,雲計算性能測試國標項目組成員，內部穩定性保障系統之預熱系統負責人。

 

本文做者：中間件小哥

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。