阿里妹導讀：全鏈路壓測是阿里的首創，我們將從工作內容、操作過程、運行總結等多個方向來介紹下阿里內部典型電商活動（如雙11準備），以給大家展示一個完整的壓測流程，幫助更多的企業和用戶更好的完成性能測試。

前言

關于性能測試的重要性及必要性已經是個老生常談的問題了，現分別從技術角度和業務戰略角度總結如下：

而性能測試的目的也就是為了解決大型營銷活動中洪峰流量引起的系統表現不確定性，一個理想的營銷活動周期應該是有如下閉環流程：

• PS：1和2之間再加一個步驟。環境改造和基礎數據準備。強調必須在生產環境。
• 壓測環境準備：需要復用真實的線上環境，壓測結果和問題暴露才都是最真實情況。可通過壓測流量全局識別、透傳（數據進影子區域）。
• 基礎數據準備：以電商場景為例，構造滿足大促場景的核心基礎相關數據（如買家、賣家、商品信息），以線上數據為數據源，進行采樣、過濾和脫敏，并保持同等量級。

可以看出，性能測試通過真實、高效的壓測方式進行容量評估/瓶頸定位&解決，最終來保障活動穩定進行；每一個環節的內容都非常重要，以阿里雙11活動為例，我們除了技術上的準備、執行、保障之外，還會有一些流程及分工細節。以下將逐一介紹。

關于流程及管理

阿里巴巴全鏈路壓測從2013年到現在也已經是第7個年頭了，在這7年中間我們不斷的積累、總結、優化進步，從開始的200多人參與、通宵壓測的大規模全員項目活動到后來僅僅幾個人白天壓測、更智能化的壓測方式，這樣一種大規模的項目活動，離不開有效的流程把控及分工管理。

阿里巴巴在多年雙十一大促保障——全鏈路壓測項目中，有著嚴格的流程把控及分工管理模式與經驗，總結如下：

說明：該圖中時間點為模擬時間點，僅做先后順序的參考。

好的流程規劃與管理，可以大大提升團隊協作效率。疊加上工具平臺的智能化功能，可以將參與的200人力通宵壓測縮減至10人以內白天壓測，有效的方案 + 充足的準備 + 靠譜的平臺技術產品 = 成功的壓測。

下面將結合主題系列前幾次的文章，介紹下在數據準備、架構改造、流量安全策略（環境及流量隔離）、壓測實施、問題定位分析這幾方面，阿里巴巴在雙十一壓測這個項目上具體是怎么做的。

壓測環境改造

數據準備的同時，需要考慮壓測環境（即壓測對象的部署環境）是哪里，不同環境就需要做不同的準備。

整個阿里經濟體的壓測環境，包括雙十一壓測，全部選擇的是線上環境，此時需要評估如果要進行全鏈路壓測，是否直接可以使用現有環境、同一個API多次壓測是否會被攔截、是否會有臟數據影響、如果有影響應該如何改造避免等。以上這些問題總結下來即為兩類問題：業務問題和數據傳遞問題。問題比較明確，我們就根據這兩類問題來做逐一的改造。

改造分為2方面：業務改造和中間件改造，這些在內部全鏈路壓測1.0 時代就已經完成了，對于外部客戶來說，可以作為一個技術改造上的參考點。同時我們已經有成熟的產品化方案提供一站式的能力，免去復雜的改造和維護成本。

業務改造

業務改造即為了解決壓測過程中的業務異常問題，或者壓測請求無法正常被執行的問題。舉例如下：

• 流量區分與識別：壓測流量和業務流量的區分，并可在全鏈路系統中識別出來；
• 流量單一性問題：比如下單，同一個人執行一次下單后再重復執行就會失敗；
• 流量的限流攔截：如果日常有限制，需要改造為接入流量降級能實時生效調整配置；
• 剔除壓測數據對報表的影響
• 動態校驗
• ......

業務改造涉及的內容無法一一窮舉，需要根據不同的業務模型、業務架構及配置，一一梳理。一般梳理改造之后，后續所有新應用都按照規范去開發，每年的壓測前進行基礎的查漏補缺即可。

中間件改造

中間件作為銜接業務應用之間的組件，在壓測中有個至關重要的功能就是將流量標識傳遞下去，一直到最終的數據庫層面。雖然我們在13年開始，從核心應用使用到的中間件已經升級改造完成，中間我們踩過不少坑，諸如改造全面性、改造帶來的業務代碼修改成本、版本兼容問題等。

改造完成之后，壓測流量的模型圖可以參考如下：

環境的改造，需要結合業務場景具體分析、設計。云上高可用解決方案，提供了全鏈路壓測解決方案的服務。

數據準備

大促活動確定之后，會對業務模型進行一次評審，即確定該業務模式對應的技術架構應用有哪些，需要做壓測的業務范圍有哪些、以及數據量級、數據形式是什么樣的。所以數據準備包括準備業務模型數據和壓測流量數據兩部分。
數據的準備，主要分為兩部分：業務模型的建立和基礎數據的構造。

業務模型數據

業務模型數據，即壓測的業務模型相關的數據，包括涉及到哪些API，這些API之間的壓測量級是什么樣的或者有什么樣的比例關系等。業務模型的構造準確度，直接影響了壓測結果的可參考性。

模型設計的目的主要是將業務進行采集并抽象成可執行的壓測模型，并對各個子模型中的元素進行預測和設計，最終產生可以執行的壓測模型。在雙十一大促前，我們會確定好相關的業務，進行場景分類。

• 已有業務場景：采集以往數據并做處理，作為預測數據，形成一個模型雛形，結合新的業務玩法，形成已有業務的模型；
• 新業務場景：直接按照新的業務，模型配比，形成一個新業務模型。

最終會將兩種業務場景類型進行組合，形成最終的終態業務模型。以下圖作為示例：

在組裝業務模型數據的時候，需要注意一些關鍵因素，比如修改具體的電商業務模型關鍵因素：

• 1對N ：上游業務一個請求對應下游業務接口是否會存在調用多次的情況；
• 業務屬性的比例：根據歷史數據計算不同類型業務的比例關系；

業務模型組裝之后，單一事務中的業務模型，應該是一個漏斗狀的。而每層之間的漏斗比例，是根據不同的層級、不同的玩法、不同的規則會有不一樣的比例關系。在一次大促活動中，這個比例關系理論上是不會變化的。漏斗模型參考如下：

業務模型在壓測時對應的就是壓測量級，淘寶大促用的全部都是RPS模式壓測，即從服務端角度出發每個API之間是漏斗比例關系、能夠很好地應用于容量規劃上。商業化產品PTS（性能測試服務，Performance Testing Service）中也很好的支持了RPS模式。

壓測基礎數據

如果說業務模型對應的是確定要壓測的接口/API的話，那壓測流量數據，就是確定這些壓測API到底壓測的是什么內容，比如：登錄哪些用戶、查看哪些商品和店鋪、購買哪些商品，甚至是付款價格是什么。

流量數據中，有一部分為上述業務模型對應具體RPS值，模型體現的是比例關系，而流量數據即有每次壓測具體的RPS值。

流量數據中最重要的部分，即為真實的壓測數據，我們可以稱之為基礎數據，比如交易的買家、賣家、商品數據等。全鏈路壓測的目的是為了模擬雙11，所以模擬的真實性非常重要，基礎數據的真實性就是至關重要的一環。全鏈路壓測會以線上數據作為數據源，經過采樣、過濾、脫敏等操作，形成可作為壓測使用的數據。

線上數據拿出來使用的時候，特別涉及到寫數據的時候，避免造成臟數據，我們落地或者讀取的時候，采用影子表的形式。當識別到壓測流量，則讀寫影子表，否則就讀寫線上正式表。影子表的產生為的是壓測流量安全。

淘寶內部系統使用的壓測體系，數據平臺和壓測平臺是兩套平臺。數據平臺管理/提供壓測數據（包括模型數據和流量數據），壓測平臺提供施壓能力，即保證壓測請求能夠以指定的“協議”、指定的量級速率、從全國各地發送出來。商業化產品PTS（性能測試服務，Performance Testing Service）中提供的數據工廠能力，很好的將內部的數據平臺和壓測平臺結合起來，產出為統一的一個壓測系統，只需用戶構造好壓測數據以文件/自定義的形式定義好參數，在使用處配置即可。

流量安全策略

流量安全策略主要是為了保證能夠正常的施壓流量且數據不錯亂，安全地、符合預期地進行。這里面就包括了兩層考慮：

測試數據和正常數據的嚴格隔離，即非法流量的監控和保護機制；

• 手段：影子表數據。影子表為和線上結構一致，但是處于隔離位置的可寫壓測數據表。
• 效果：數據隔離，避免了數據錯亂。

壓測流量的安全過濾，即不被識別為攻擊流量；

• 手段：將安全相關策略接入流控降級功能；針對壓測適當放松安全策略，或根據特殊標記識別；
• 效果：壓測流量不被判定為攻擊流量，成功壓測的同時保障線上業務的安全性。

此處，涉及到第三方的系統，諸如支付寶、短信等服務，因業務特殊性需要做壓測系統的打通。13年淘寶實現了第一次全鏈路壓測，但是未能打通下游業務鏈路。在14年雙十一壓測前，和支付寶、物流環節等打通了全面的壓測系統。對于外部客戶來說，支付寶、短信等都有對應的擋板服務可提供，用來供用戶做全鏈路壓測時使用。

壓測實施

根據最開始介紹到的流程管控，一切準備就緒之后，即可開始進行全鏈路壓測。除常規理解的正式壓測之外，我們還有額外的兩個預操作：系統預熱、登錄準備。

說明：此處未介紹首次改造之后的單鏈路壓測調試，這部分基本由開發同學自行操作驗證，故不在此特殊闡述。

關于系統預熱 這里說的預熱，未包含我們內部提到的預跑。預熱是為了該緩存的數據提前緩存好，達到大促緩存態的狀態，也更好地實現我們緩存的目的。大促緩存的使用應該利用到極致，故需要通過預熱來進行。

對外部客戶來說，可以通過先一輪、低量級的全鏈路壓測，來提前預熱系統，包括在真正大促活動之前也可這樣操作，即提前緩存住需要緩存的數據。

登錄準備：登錄準備主要是用于需要長連接保持、秒殺等場景，即用戶都是逐步登錄上來，然后再進行業務操作的場景。故如果量級特別大的時候，可以提前做登錄的準備，一則來模擬真實用戶登錄場景，二則是對登錄系統的保護。

正式壓測：一般正式壓測會按照壓測計劃，執行多種壓測策略。淘寶的雙11大促壓測，一般包含這樣幾步：

1）峰值脈沖：即完全模擬0點大促目標峰值流量，進行大促態壓測，觀察系統表現。

2）系統摸高：取消限流降級保護功能，抬高當前壓測值（前提是當前的目標壓測值已經達到，則可以進行摸高測試），觀察系統的極限值是多少?？蛇M行多輪提升壓力值壓測，直到系統出現異常為止。

3）限流降級驗證：即驗證限流降級保護功能是否正常。 （AHAS引入）商業化產品AHAS(應用高可用服務，Application High Availability Service）提供了全面的限流降級能力，可進行全鏈路的降級保護。

4）破壞性測試：這個主要是為了驗證預案的有效性，類似于容災演練時的預案執行演練。即為持續保持大促態壓測，并驗證預案的有效性，觀察執行預案之后對系統的影響。

對外部客戶來說，可以配置不同的壓測量級數據，來進行多輪壓測，并觀察其系統表現。壓測不應該是一次性的操作，而應該是反復的、多輪驗證的操作。

問題定位分析

壓測結束之后，會將壓測過程中的系統表現、監控數據等整理，進行壓測復盤，分析當前系統瓶頸、后續改進修復計劃及下一輪壓測時間等。在分析定位問題時，因涉及的系統較多、子業務系統的形態不一，需要具體問題具體分析，其中不免需要一線研發的介入。

商業化產品PTS（性能測試服務，Performance Testing Service）的壓測報告，有詳細統計數據及趨勢圖數據，采樣日志以及添加了的監控數據。后續PTS還會提供架構監控，幫助性能測試執行同學，更好地從系統架構角度判定壓測過程中系統是否正常，大致瓶頸點。

智能化壓測

阿里巴巴全鏈路壓測已經進入第7個年頭，從開始的摸著石頭過河，發展到現在更智能化形態。其中部分功能也會體現在商業化產品中，大家敬請期待。

• 更多協議的支持
• 容量評估
• 問題自動發現
• 全鏈路功能測試&壓測預演
• 壓測常態化
• 彈性大促，邊壓邊彈
• ......

未來

阿里巴巴將全鏈路壓測進行到第7個年頭，中間經歷了太多的磨練與積累，隨著新技術的出現，我們也將不斷的完善自己，做到更好。同時，更希望能將這么多年的經驗，能賦能到外部客戶，比我們少踩坑、完美的度過每一輪大促活動，并將全鏈路壓測應用到更多的日常場景中。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的独家揭秘 | 阿里怎么做双11全链路压测？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。