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

時間 2019-11-06

原文原文鏈接

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

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

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

前言

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

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

壓測環境準備：須要複用真實的線上環境，壓測結果和問題暴露才都是最真實狀況。可經過壓測流量全局識別、透傳（數據進影子區域）。
基礎數據準備：以電商場景爲例，構造知足大促場景的核心基礎相關數據（如買家、賣家、商品信息），以線上數據爲數據源，進行採樣、過濾和脫敏，並保持同等量級。

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

關於流程及管理

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

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

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

數據準備

大促活動肯定以後，會對業務模型進行一次評審，即肯定該業務模式對應的技術架構應用有哪些，須要作壓測的業務範圍有哪些、以及數據量級、數據形式是什麼樣的。因此數據準備包括準備業務模型數據和壓測流量數據兩部分。數據的準備，主要分爲兩部分：業務模型的創建和流量基礎數據的構造。

業務模型數據

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

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

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

最終會將兩種業務場景類型進行組合，造成最終的終態業務模型。如下圖做爲示例：

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

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

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

業務模型在壓測時對應的就是壓測量級，淘寶大促用的所有都是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還會提供架構監控，幫助性能測試執行同窗，更好地從系統架構角度斷定壓測過程當中系統是否正常，大體瓶頸點。