本文是《Performance Test Together》（簡稱PTT）系列專題分享的第7期，該專題將從效能壓測的設計、實現、執行、監控、問題定位和分析、應用場景等多個緯度對效能壓測的全過程進行拆解，以幫助大家構建完整的效能壓測的理論體系，並提供有例可依的實戰。

該系列專題分享由阿里巴巴 PTS 團隊出品，歡迎在文末處加入效能壓測交流群，參與該系列的線上分享,點選“閱讀原文”瞭解更多效能壓測 PTS 相關。

本文將從經典電商活動（雙11大促）及新業務（釘釘春節紅包）兩個業務模式，來揭秘阿里是如何系統性地應對洪峰流量重要活動的；期間將著重介紹技術相關內容，並結合主題文章前幾期中的環境選取、模式設計、場景設計與實踐等內容，做一次串聯與深度剖析與分享，呈現一場效能測試的技術盛宴。

前言

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

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

壓測環境準備：需要複用真實的線上環境，壓測結果和問題暴露才都是最真實情況。可透過壓測流量全域性識別、透傳（資料進影子區域）。
基礎資料準備：以電商場景為例，構造滿足大促場景的核心基礎相關資料（如買家、賣家、商品資訊），以線上資料為資料來源，進行取樣、過濾和脫敏，並保持同等量級。

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

關於流程及管理

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

阿里巴巴在多年雙十一大促保障--全鏈路壓測專案中，有著嚴格的流程把控及分工管理模式與經驗，總結如下：
說明：該圖中時間點為模擬時間點，僅做先後順序的參考。

好的流程規劃與管理，可以大大提升團隊協作效率。疊加上工具平臺的智慧化功能，可以將參與的200人力通宵壓測縮減至10人以內白天壓測，有效的方案 + 充足的準備 + 靠譜的平臺技術產品 = 成功的壓測。
下面將結合主題系列前幾次的文章，介紹下在資料準備、架構改造、流量安全策略（環境及流量隔離）、壓測實施、問題定位分析這幾方面，阿里巴巴在雙十一壓測這個專案上具體是怎麼做的。

資料準備

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

業務模型資料

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

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

已有業務場景：採集以往資料並做處理，作為預測資料，形成一個模型雛形，結合新的業務玩法，行程已有業務的模型；
新業務場景：直接按照新的業務，模型配比，形成一個新業務模型。

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

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

1對N ：上游業務一個請求對應下游業務介面是否會存在呼叫多次的情況；
業務屬性的比例：根據歷史資料計算不同型別業務的比例關係；

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

獨家揭秘 | 阿里怎麼做雙11全鏈路壓測？

業務模型在壓測時對應的就是壓測量級，淘寶大促用的全部都是RPS模式壓測，即從服務端角度出發每個API之間是漏斗比例關係、能夠很好地應用於容量規劃上。關於RPS模式與併發模式對比，可以參考前序文章《併發模式與 RPS 模式之爭，效能壓測領域的星球大戰》。商業化產品PTS（效能測試服務，Performance Testing Service）中也很好的支援了RPS模式。

壓測基礎流量資料

如果說業務模型對應的是確定要壓測的介面/API的話，那壓測流量資料，就是確定這些壓測API到底壓測的是什麼內容，比如：登入哪些使用者、檢視哪些商品和店鋪、購買哪些商品，甚至是付款價格是什麼。
流量資料中，有一部分為上述業務模型對應具體RPS值，模型體現的是比例關係，而流量資料即有每次壓測具體的RPS值。
流量資料中最重要的部分，即為真實的壓測資料，我們可以稱之為基礎資料，比如交易的買家、賣家、商品資料等。全鏈路壓測的目的是為了模擬雙11，所以模擬的真實性非常重要，基礎資料的真實性就是至關重要的一環。全鏈路壓測會以線上資料作為資料來源，經過取樣、過濾、脫敏等操作，形成可作為壓測使用的資料。
線上資料拿出來使用的時候，特別涉及到寫資料的時候，避免造成髒資料，我們落地或者讀取的時候，採用影子表的形式。當識別到為壓測流量，則讀寫影子表，否則就讀寫線上正式表。影子表的產生為的是壓測流量安全，關於影子表的闡釋和使用方法，在《流量安全策略》中介紹。刪除資料遷移內容
淘寶內部系統使用的壓測體系，資料平臺和壓測平臺是兩套平臺。資料平臺管理/提供壓測資料（包括模型資料和流量資料），壓測平臺提供施壓能力，即保證壓測請求能夠以指定的“協議”、指定的量級速率、從全國各地傳送出來。商業化產品PTS（效能測試服務，Performance Testing Service）中提供的資料工廠能力，很好的將內部的資料平臺和壓測平臺結合起來，產出為統一的一個壓測系統，只需使用者構造好壓測資料以檔案/自定義的形式定義好引數，在使用處配置即可。

全鏈路壓測環境改造

資料準備的同時，需要考慮壓測環境（即壓測物件的部署環境）是哪裡，不同環境就需要做不同的準備。關於壓測環境的選擇，可以參考前序文章《壓測環境的設計和搭建》。
整個阿里經濟體的壓測環境，包括雙十一壓測，全部選擇的是線上環境，此時需要評估如果要進行全鏈路壓測，是否直接可以使用現有環境、同一個API多次壓測是否會被攔截、是否會有髒資料影響、如果有影響應該如何改造避免等。以上這些問題總結下來即為兩類問題：業務問題和資料傳遞問題。問題比較明確，我們就根據這兩類問題來做逐一的改造。
改造分為2方面：業務改造和中介軟體改造，這些在內部全鏈路壓測1.0 時代就已經完成了，對於外部客戶來說，可以作為一個技術改造上的參考點。同時我們已經有成熟的產品化方案提供一站式的能力，免去複雜的改造和維護成本。

業務改造

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

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

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

中介軟體改造

中介軟體作為銜接業務應用之間的元件，在壓測中有個至關重要的功能就是將流量標識傳遞下去，一直到最終的資料庫層面。雖然我們在13年開始，從核心應用使用到的中介軟體已經升級改造完成，中間我們踩過不少坑，諸如改造全面性、改造帶來的業務程式碼修改成本、版本相容問題等。
改造完成之後，壓測流量的模型圖可以參考如下：

現雲上高可用解決方案，提供了全鏈路壓測解決方案的服務，如需要做全鏈路壓測改造的，歡迎垂詢。同時，我們後續也會發布全鏈路壓測2.0，可以幫助使用者低成本的進行改造。

流量安全策略

流量安全策略主要是為了保證能夠正常的施壓流量且資料不錯亂，安全地、符合預期地進行。這裡面就包括了兩層考慮：
測試資料和正常資料的嚴格隔離，即非法流量的監控和保護機制；
手段：影子表資料。影子表為和線上結構一致，但是處於隔離位置的可寫壓測資料表。修改影子表的闡述詳情，更簡化
效果：資料隔離，避免了資料錯亂。
壓測流量的安全過濾，即不被識別為攻擊流量；
手段：將安全相關策略接入流控降級功能；針對壓測適當放鬆安全策略，或根據特殊標記識別；
效果：壓測流量不被判定為攻擊流量，成功壓測的同時保障線上業務的安全性。
此處，涉及到第三方的系統，諸如支付寶、簡訊等服務，因業務特殊性需要做壓測系統的打通。13年淘寶實現了第一次全鏈路壓測，但是未能打通下游業務鏈路。在14年雙十一壓測前，和支付寶、物流環節等打通了全面的壓測系統。對於外部客戶來說，支付寶、簡訊等都有對應的擋板服務可提供，用來供使用者做全鏈路壓測時使用。

壓測實施

根據最開始介紹到的流程管控，一切準備就緒之後，即可開始進行全鏈路壓測。除常規理解的正式壓測之外，我們還有額外的兩個預操作：系統預熱、登入準備。
說明：此處未介紹首次改造之後的單鏈路壓測除錯，這部分基本由開發同學自行操作驗證，故不在此特殊闡述。

關於系統預熱
這裡說的預熱，未包含我們內部提到的預跑。刪除預跑相關資訊預熱是為了該快取的資料提前快取好，達到大促快取態的狀態，也更好地實現我們快取的目的。大促快取的使用應該利用到極致，故需要透過預熱來進行。簡化預熱的功能描述

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

登入準備
登入準備主要是用於需要長連線保持、秒殺等場景，即使用者都是逐步登入上來，然後再進行業務操作的場景。故如果量級特別大的時候，可以提前做登入的準備，一則來模擬真實使用者登入場景，二則是對登入系統的保護。
正式壓測
一般正式壓測會按照壓測計劃，執行多種壓測策略。淘寶的雙11大促壓測，一般包含這樣幾步：
峰值脈衝
即完全模擬0點大促目標峰值流量，進行大促態壓測，觀察系統表現。
系統摸高
取消限流降級保護功能，抬高當前壓測值（前提是當前的目標壓測值已經達到，則可以進行摸高測試），觀察系統的極限值是多少。可進行多輪提升壓力值壓測，直到系統出現異常為止。簡化摸高測試的提升資訊
限流降級驗證
顧名思義，即驗證限流降級保護功能是否正常。修改限流降級的作用與驗證方法，更簡化。（AHAS引入）商業化產品AHAS(應用高可用服務，Application High Availability Service）提供了全面的限流降級能力，可進行全鏈路的降級保護。
破壞性測試
這個主要是為了驗證預案的有效性，類似於容災演練時的預案執行演練。即為持續保持大促態壓測，並驗證預案的有效性，觀察執行預案之後對系統的影響。修改破壞性測試的內容

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

問題定位分析

壓測結束之後，會將壓測過程中的系統表現、監控資料等整理，進行壓測覆盤，分析當前系統瓶頸、後續改進修復計劃及下一輪壓測時間等。在分析定位問題時，因涉及的系統較多、子業務系統的形態不一，需要具體問題具體分析，其中不免需要一線研發的介入。
商業化產品PTS（效能測試服務，Performance Testing Service）的壓測報告，有詳細統計資料及趨勢圖資料，取樣日誌以及新增了的監控資料。後續PTS還會提供架構監控，幫助效能測試執行同學，更好地從系統架構角度判定壓測過程中系統是否正常，大致瓶頸點。

智慧化壓測

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

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

未來

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

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。