如何開展線上全鍊路壓測思路分享

2021-04-23 12:16 

狂師 

閱讀(0) 

評論(0) 

編輯 

收藏

如何開展線上全鍊路壓測？

随着業務的快速發展我們日常遇到的系統性能壓力問題也逐漸出現，甚至在部分場合會遇到一些突發的營銷活動，會導緻系統性能突然暴漲，可能導緻我們系統的癱瘓。最近幾年随着電商的各種促銷活動，有一個詞也漸漸進入我們眼簾－－“全鍊路壓測”。

全鍊路壓測被衆多網際網路公司的程式員定義為核武器，傳統性能測試更多的是以事務為核心，更多的是由單個或者多個事務構成業務場景進行壓測。那全鍊路壓測到底是什麼？一般指完全引入相關聯的系統，真實模拟線上硬體環境，更多的是以請求為核心，完全模拟真實請求流量，通過引流等方式進行場景的模拟進行壓測，更多的适用于業務鍊路較長的交易。

筆者以前隻是一直聽說全鍊路壓測，但是并沒有真正經曆過，對全鍊路壓測的了解也不是很全面，前年在網際網路電商公司雙11的時候參加過一次全鍊路的壓測，當時全公司第一次做大範圍的全鍊路壓測，整個架構部也是第一次牽頭來完成了整個全鍊路壓測，經過大家1個月的努力，最後在活動期間完全扛住了壓力，并且還有性能過剩。當時做完後因為忙的太累，沒有進行過總結，最近新的公司正好在壓測，借此也總結下全鍊路壓測。

01 為什麼需要全鍊路壓測

我們在整個業務流程中，最大的困難在于評估從使用者登入到完成全部交易的整個鍊條中，核心頁面和交易關鍵交易的實際承載能力。如果得到了各個系統的實際承載能力，就可以在路由網關進行相關交易限流控制，來防止在大并發來了以後系統出現當機，我們都知道一旦系統當機就會導緻災難性的後果，而且就算運維短時間重新開機了起來恢複了運作，但是可能過了一會兒過程系統承載量又出現當機，早期阿裡在雙十一的時候就發生過這樣的問題，系統在0點，出現大面積癱瘓，重新開機後又癱瘓。

為什麼會出現這個問題，就是因為大家對整個全交易鍊條上的各個環節的系統承壓能力不清楚，是以在出現了全鍊路壓測，一方面能夠讓各個産品知道自己的承壓極限在哪？有的同學會問了通過單系統壓測不是也可以知道各個系統的承壓能力嗎？但是實際情況不可能那麼簡單，那麼順利，在活動開始的瞬間，從CDN、網關接入、前端、緩存、中間件、後端服務、資料庫整個交易鍊路都會面臨巨大的通路壓力，這個時候系統服務除了受自生的影響，還依賴于其他關聯系統的情況，并且影響會一直蔓延，隻要有一個節點出現故障，那麼故障在上下遊系統經過層層累加後會造成的影響誰都說不清楚，是以最好的辦法就是模拟完全的真實情況來做到提前心裡有數。驗證的最好辦法就是讓事件提前發生，通過全鍊路壓測就可以提早發現問題。

另一方面也可以讓各個系統能夠有個明确的優化目标并找出性能瓶頸，同時對于一些特殊環節可以通過臨時增加公有雲的方式來提高整體的性能，一旦通過全鍊路壓測，了解了瓶頸所在就可以坦然的去按照壓測名額去申請公有雲資源，活動結束後再歸還資源，這樣做到成本最低化。

02 全鍊路壓測常常遇到的問題 

如何開展全鍊路壓測？在說這個問題前，我們先考慮下，全鍊路壓測有哪些問題比較難解決。

1）涉及的系統太多，牽扯的開發人員太多；

在壓測過程中，做一個全鍊路的壓測一般會涉及到大量的系統，在整個壓測過程中，光各個産品的人員協調就是一個比較大的工程，牽扯到太多的産品經理和開發人員，如果公司對全鍊路壓測早期沒有足夠的重視，那麼這個壓測工作是非常難開展的。

2）模拟的測試資料和通路流量不真實；

在壓測過程中經常會遇到壓測後得到的資料不準确的問題，這就使得壓測出的資料參考性不強，為什麼會産生這樣的問題？主要就是因為壓測的環境可能和生成環境存在誤差、參數存在不一樣的地方、測試資料存在不一樣的地方這些因素綜合起來導緻測試結果的不可信。

3）壓測生産資料未隔離，影響生産環境；

在全鍊路壓測過程中，壓測資料可能會影響到生産環境的真實資料，舉個例子，電商系統在生産環境進行全鍊路壓測的時候可能會有很多壓測模拟使用者去下單，如果不做處理，直接下單的話會導緻系統一下子會産生很多廢訂單，進而影響到庫存和生産訂單資料，影響到日常的正常營運。

03 如何開展全鍊路壓測

其實進行全鍊路壓測對于整個公司技術要求還是很高的，如果沒有一定能力的公司最好不要貿然嘗試全鍊路壓測，因為如果沒做好可能會把生産環境搞宕，是以對于沒有一定科技能力的公司還是盡量不要貿然追潮流實施全鍊路壓測。對于科技能力不強的公司如果也想達到全鍊路壓測那該怎麼辦？其實辦法也很簡單，可以在壓測環境進行模拟，做一個比例模拟，模拟1%－2%的通路量在測試環境進行壓測，得到資料後乘以對應的倍數來得到總的壓測名額，這裡的比例當然不是簡單的倍數相乘，需要各個系統得到系統線性擴充和單機壓測名額的一個線性值，因為一般來說的線性擴充都不可能是100%的，一定會有一定擴充後的損失。

1）分析需壓測業務場景涉及系統

在壓測前我們一定要首先分析清楚需要壓測的業務場景，隻有分析清楚了業務場景才能梳理出來涉及的相關系統，分析清楚後也可以更快的找到性能瓶頸進行系統優化。這個工作一般是由架構師來梳理并确認涉及的相關系統，梳理清楚後就可以回報給總壓測負責人進行人員和資源的協調了。

2）協調各個壓測系統資源

在全鍊路壓測過程中，最難的工作其實不是系統優化、壓測環境搭建等技術工作，最難的是壓測資源的協調工作。這裡的資源不單單指壓測硬體、公有雲等資源，還包括了人力資源，在整個壓測過程中，需要各個相關産品的産品經理和技術開發人人員參與進去，這個工作可能不是架構師或者一個牽頭産品的負責人能夠協調的動的，必須要有一個自上而下的推力去推動，需要一個有一定級别的上司做背書，我們當時是分管科技的老總召集了所有的産品經理和各個産品技術開發負責人開了一個全鍊路壓測的方案讨論會，這個會一方面說明了這個事情的重要性，讓各個産品都當場立下軍令狀，并且安排出支援的人員，同時也授權給壓測負責人。這個搞定以後壓測負責人後續就可以光明正大的協調各個産品的配合人員了。

3）壓測環境

壓測環境也是個比較頭疼的問題，很多系統可能壓根就沒有壓測環境，是以全鍊路壓測有個和傳統壓測比較大的差別就是，全鍊路壓測是在生産環境，這種做法其實是存在一定風險的，一方面是系統風險，一方面是業務資料風險。對于全鍊路壓測系統風險一定是首要考慮的問題，不能因為壓測把系統搞當機影響到日常生産環境的正常營運，我們當時做的電商系統還好，不涉及相關的監管。但是在銀行業這樣做還是有很大的風險的，一旦生産系統出現關鍵交易系統的當機可能導緻一些金融事故，會對金融市場造成恐慌，而且會被銀監會通報，是以銀行的壓測還是不要進行全鍊路壓測，不過可以在測試環境盡量仿真的模拟全鍊路壓測。

前年在電商環境上做全鍊路壓測直接在生産上進行壓測，用生産環境最大的好處就是環境的真實性，通過生産環境能夠最高程度的還原生産環境不用額外準備壓測環境。但是使用生産環境進行壓測需要考慮将請求和通路、業務資料處理都進行隔離，防止影響到生産環境，具體如何實施，涉及到比較多的細節這裡就不較長的描述了。總的思路就是在發起請求的時候通過請求封包頭中的壓測标示來進行區分處理，将壓測的流量都分流到指定的應用伺服器和指定的存儲進行資料儲存和處理。

進行全鍊路壓測的時候，為了防止系統崩潰，可以選擇在淩晨使用者量最小的時候進行，這樣就算發生故障也可以将影響降到最低。

4）壓測資料

環境準備好了，可能就需要考慮造壓測資料了，壓測資料準備有兩方面資料需要準備，一方面是壓測請求資料的準備，需要模拟請求資料，請求資料最好的辦法就是采用生産的真實資料，我們當時的做法是直接錄制3-5天的生産通路請求流量，隻需要對錄制的請求進行資料清洗就可以了，将某個使用者的請求替換成一個壓測虛拟使用者的請求，請求的商品也替換成壓測虛拟商品，這個資料漂白替換的工作是比較複雜的，對于做資料漂白的的同學對系統的接口非常了解，否則很可能造成業務資料的混亂，造成大量的業務報表和系統資料的髒資料；另一方面是測試資料的準備，我們當時準備了壓測虛拟商品的資料、虛拟商品庫存資料、虛拟供貨商、虛拟使用者。

5）壓測資料隔離

因為是在生産環境做的壓測，壓測資料需要與正常的業務資料隔離開，我們當時的方案是對于壓測的這些髒資料都做了特定标示，對于虛拟使用者、虛拟商品、虛拟訂單、虛拟庫存都是有特殊标示的，這樣這類資料在統計的時候都不會進行統計，在壓測後也會對這些資料進行清理，防止污染正常業務資料。

6）壓測資料實時監控

在壓測過程中，為了能發現性能問題，我們需要對壓測過程中各個系統的cpu、記憶體、磁盤io都進行系統層面的監控，同時也需要對各個業務節點的耗時進行監控，一方面從業務層面去監控壓測事務性能，另一方面從系統層面監控，這樣我們可以先從業務層面找到性能瓶頸，再單獨分析各個系統的系統層面的瓶頸，最終找到優化方案。

我們當時公司内部有個實時監控平台，這個平台是基于大衆點評開源的cat實作的多平台監控系統，能夠實時監控各個系統的實時交易運作情況，這樣能夠在第一時間發現遇到大流量的情況後，性能瓶頸在哪？然後進行針對性的優化。

04 全鍊路壓測優化思路

性能優化的核心在我看來其實就是一個充分利用系統資源并平衡IO的過程。這句話怎麼了解，首先在保證代碼沒有問題的情況下，充分利用系統的cpu、記憶體、磁盤資源，一般來說在保證cpu、記憶體都消耗到80%以上基本上就達到了性能峰值了，但是我們在壓測過程中常常遇到的問題是cpu、記憶體消耗都不高，而是卡在了IO上，IO包括了磁盤IO、資料庫IO、網絡IO，我們需要根據監控的資料從這3方面去找到瓶頸，并去解決IO的問題。一般來說造成這種情況一般都是因為IO聚集導緻了阻塞，可以考慮采用緩存、異步的方式去解決，對于一些關鍵交易的事務的完整性可以考慮采用先緩存最後通過緩存同步資料庫的方式來保證最終一緻性。

全鍊路壓測一般可以從3個層面去進行優化：

1）優化單個系統性能

就算不進行全鍊路壓測，單個系統的性能優化也是要考慮的問題，對單個系統的優化，其實方法有很多，但是萬變不離其宗，就是在壓測過程中監控系統各項名額，從中挑出慢交易，針對慢交易進行優化，對于聯機系統大部分都是因為各種IO問題導緻性能上不去。可以根據各種媒體IO通路的性能來優化（記憶體緩存>檔案>資料庫>網絡），基本上通過緩存和異步處理這兩顆銀彈就可以解決80%的性能問題。

當鍊路上的單個系統性能提升了，整體的全鍊路性能自然就提升了。

2）優化關聯路徑

但是在優化的過程中，我們常常發現絕大部分系統性能都很高，但是總的TPS還是很低，這就需要去根據監控了解下目前整個鍊路上的性能瓶頸到底在哪？通過全鍊路監控可以發現整個業務流程在哪個節點耗時最長，那麼這個耗時最長的節點就是我們需要優化的地方，隻要這些關鍵路徑的性能提升上來以後整體的性能就上來了。關鍵節點的優化方式和單系統優化思路一緻。

3）優化業務流程

很多開發人員都會将優化思路集中在技術層面，但是很多時候從業務流程上進行優化效果可能更好，而且提升的效果會非常明顯。業務層面的優化主要是從分散IO的角度去考慮，将實際業務場景中的使用者請求進行分散，例如常見的大秒系統、驗證碼系統、遊戲工具等都是為了進行業務層面的IO分散來保證。這類業務流程的優化首先要梳理清楚整個業務流程，包括所有的細節。然後針對每個環節在保證使用者體驗的情況下分散使用者請求，這樣可以最大限度的保證體驗。

05 總結

整個壓測優化過程就是一個不斷優化不斷改進的過程，通過長期的循序漸進的改進不斷發現問題，優化系統，才能讓系統的穩定性和性能都得到質的提升。整個壓測優化的思路其實和高并發架構設計的思路是一緻的，接下來也會寫一些關于高并發架構的文章，本篇的全鍊路壓測隻是給大家做個入門介紹，其中涉及到的問題遠遠不止文中提到的這些，而且問題的解決辦法也遠遠不是說的那麼簡單，造虛拟使用者、虛拟商品并不是随便造的，資料隔離也不是簡單加個字首什麼的就可以的，也是有很多講究的，因為全鍊路壓測涉及到的内容太多而且還涉及到各家公司的組織架構，是以這裡就不展開了，隻是給大家一個思路，按照這個思路結合自己公司的情況去實施，慢慢摸索總結出一套适合自己産品的全鍊路壓測。

• 分類 性能測試