全鏈路壓測經驗談

前言

隨著業務的快速發展我們日常遇到的系統性能壓力問題也逐漸出現，甚至在部分場合會遇到一些突發的營銷活動，會導致系統性能突然暴漲，可能導致我們系統的癱瘓。最近幾年隨著電商的各種促銷活動，有一個詞也漸漸進入我們眼簾－－“全鏈路壓測”。全鏈路壓測被眾多網際網路公司的程式設計師定義為核武器，傳統效能測試更多的是以事務為核心，更多的是由單個或者多個事務構成業務場景進行壓測。那全鏈路壓測到底是什麼？一般指完全引入相關聯的系統 真實模擬線上硬體環境，更多的是以請求為核心，完全模擬真實請求流量，透過引流等方式進行場景的模擬進行壓測，更多的適用於業務鏈路較長的交易。

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

1。 為什麼需要全鏈路壓測

我們在整個業務流程中，最大的困難在於評估從使用者登入到完成全部交易的整個鏈條中，核心頁面和交易關鍵交易的實際承載能力。如果得到了各個系統的實際承載能力，就可以在路由閘道器進行相關交易限流控制，來防止在大併發來了以後系統出現宕機，我們都知道一旦系統宕機就會導致災難性的後果，而且就算運維短時間重啟了起來恢復了執行，但是可能過了一會兒過程系統承載量又出現宕機，早期阿里在雙十一的時候就發生過這樣的問題，系統在0點，出現大面積癱瘓，重啟後又癱瘓，為什麼會出現這個問題，就是因為大家對整個全交易鏈條上的各個環節的系統承壓能力不清楚，所以在出現了全鏈路壓測，一方面能夠讓各個產品知道自己的承壓極限在哪？有的同學會問了透過單系統壓測不是也可以知道各個系統的承壓能力嗎？但是實際情況不可能那麼簡單，那麼順利，在活動開始的瞬間，從CDN、閘道器接入、前端、快取、中介軟體、後端服務、資料庫整個交易鏈路都會面臨巨大的訪問壓力，這個時候系統服務除了受自生的影響，還依賴於其他關聯絡統的情況，並且影響會一直蔓延，只要有一個節點出現故障，那麼故障在上下游系統經過層層累加後會造成的影響誰都說不清楚，所以最好的辦法就是模擬完全的真實情況來做到提前心裡有數。驗證的最好辦法就是讓事件提前發生，透過全鏈路壓測就可以提早發現問題。

另一方面也可以讓各個系統能夠有個明確的最佳化目標並找出效能瓶頸，同時對於一些特殊環節可以透過臨時增加公有云的方式來提高整體的效能，一旦透過全鏈路壓測，瞭解了瓶頸所在就可以坦然的去按照壓測指標去申請公有云資源，活動結束後再歸還資源，這樣做到成本最低化。

2。 全鏈路壓測常常遇到的問題

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

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

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

2）模擬的測試資料和訪問流量不真實；

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

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

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

3。 如何開展全鏈路壓測

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

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

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

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

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

3）壓測環境

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

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

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

4）壓測資料

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

5）壓測資料隔離

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

6）壓測資料實時監控

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

我們當時公司內部有個實時監控平臺，這個平臺是基於大眾點評開源的cat實現的多平臺監控系統，能夠實時監控各個系統的實時交易執行情況，這樣能夠在第一時間發現遇到大流量的情況後，效能瓶頸在哪？然後進行針對性的最佳化。

4。 全鏈路壓測最佳化思路

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

全鏈路壓測一般可以從3個層面去進行最佳化：

1）最佳化單個系統性能

就算不進行全鏈路壓測，單個系統的效能最佳化也是要考慮的問題，對單個系統的最佳化，其實方法有很多，但是萬變不離其宗，就是在壓測過程中監控系統各項指標，從中挑出慢交易，針對慢交易進行最佳化，對於聯機系統大部分都是因為各種IO問題導致效能上不去。可以根據各種介質IO訪問的效能來最佳化（記憶體快取>檔案>資料庫>網路），基本上透過快取和非同步處理這兩顆銀彈就可以解決80%的效能問題。

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

2）最佳化關聯路徑

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

3）最佳化業務流程

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

總結

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