“敏捷版” 全鏈路壓測

作者：子矜

審覈 & 校__對：風雲、雨芙

編輯 & 排版：雯燕

客戶的故事

全鏈路壓測被譽爲大促備戰的 “核武器” ，如果之前有關注過阿里雙 11 相關的技術總結，對 “全鏈路壓測” 一定不會陌生，這個詞的出場率幾乎 100%。從對雙 11 穩定性的價值來看，用 “核武器” 來形容全鏈路壓測毫不爲過。

在某知名電商大促中，該電商平臺也想用全鏈路壓測來爲自己的大促提前排除風險。但是他遇到幾個困難:

  1. 全鏈路壓測是一個需要多角色參與的活動：業務方，測試，運維，研發，數據庫，都需要參與進來。然而能夠像阿里具備成熟的組織體系，可以強有力的推動各種不同的角色，都是需要較長時間來積累的。

  2. 全鏈路壓測，常常涉及到框架的改造：而該電商平臺的業務複雜，做結構梳理與業務改造並不現實。

那這個知名電商平臺，有什麼辦法可以在 1 個星期之內，不進行業務改造，不改變業務部署，就能夠用上全鏈路壓測呢？

接下來的內容，我們會從全鏈路壓測的原理開始，並引入基於同樣原理的 “敏捷版” 全鏈路壓測，讓該知名電商平臺能夠在 2 周之內就能用上全鏈路壓測的方案。

全鏈路壓測

首先，我們來看看阿里的全鏈路壓測，到底解決了什麼問題：

全鏈路壓測實際上解決的問題是：在線上的壓測。線上壓測，能夠最快、最直接的發現線上的問題。然而，線上壓測會帶來數據污染的問題：如何把壓測數據和真實數據區分開來，是壓測裏至關重要的一點。那麼，阿里是怎麼做的呢？我們一起來看下圖：

阿里的全鏈路壓測具有一套成熟又複雜的系統：壓測的梳理、構建、準備、發送。然而，這套體系對於一個雲上的用戶是需要長期建設得到的。那我們如何能夠讓用戶快速，敏捷的享受這套技術呢？

在這裏，PTS 把整個流程進行沉澱，都以標準化的輸出來提供給雲上的用戶。用戶可以直接享用一整套的全鏈路壓測體系，也可以在壓測的關鍵環節：例如場景梳理、請求構建、壓測環境、壓測等步驟中，根據自己的需求來定製自己想要的壓測效果。

場景梳理

業務場景，即對應的是壓測的輸入請求。這是壓測第一步，也是最重要的一步。最常見的是把涉及到業務的 URL 進行梳理，彙總。例如下圖就是一個常見的場景彙總：

然而，這是不夠的。當若干個 URL 彙總成一個場景之後，URL 之間的比例、時間間隔，也是影響業務場景的關鍵。用常見的場景打一個比方：一個用戶的下單，可能背後蘊含着 10 個用戶登錄，每個用戶平均瀏覽了 4 個商品，每個商品中平均被瀏覽了 5 個評價，最後一個用戶在 10 點大促開始的時候，購買了一個商品。

這些 URL 之間的關係、時間點，需要人員有豐富的業務知識才能梳理清楚。爲此，PTS 提供服務端流量錄製的功能，方便用戶來錄製流量，並且輕鬆的得到其中不同維度的比例關係:

如上圖所示，用戶可以清晰的得到 URL 之間的比例關係、用戶 URL 之間的時間行爲等等。基於這個梳理好的數據模型，用戶可以在這個基礎上進行裁剪。

測試數據構造

接下來，就是構造用戶數據了。這一步涉及的角色最多，也最爲繁瑣。整個數據構造由三個步驟構成，如下圖所示：

首先是數據發現。通常，我們可以通過人工業務梳理，得到該業務所涉及到的所有表，並進行分析。PTS 爲免除這個煩惱，和 DMS 打通，提供表結構預覽，讓測試人員方便的看清楚和場景相關聯的結構，大大的提升效率。

如果還是覺得太複雜，PTS 將提供數據錄製工具，安裝了這個 agent 之後，該業務所涉及的表，都會被完整的記錄下來：

有了這些工具，測試人員就可以無須 DBA 的協助，輕鬆的得到場景關聯的表信息了。

 數據閉包

有了這些數據表，並且在這基礎之上分析出來數據閉包後，我們可以開始製作壓測數據了。通常，我們製作影子表的方式有三種:

  1. 影子庫 – 全量的進行影子庫映射。該方法的優勢是簡單，劣勢是消耗資源多；

  2. 影子表 – 將表閉包裏的表，通過一定規則，進行名字關聯。該方法的優勢是節省資源，劣勢是需要對錶進行充分梳理，並且一一對應；

  3. 不新建表，在同一張表內，將影子數據進行大位移偏移。這個將在後面的敏捷版內進行介紹。

這三種方式可以根據需求組合使用。

 數據導入 / 混擾

有了這些前提之後，我們可以利用 DMS 來數據導入，進行數據製作了。

到這裏，我們完成了全鏈路壓測中最複雜的兩個步驟：壓測場景梳理、壓測數據製作。

接下來我們通過數據加工，把這兩個元素最終加工爲壓測數據。

 數據加工

此時，我們對壓測數據做最後一個步驟，進行數據加工。即我們把業務場景、壓測數據，按照我們的業務模型進行最後的調整與加工:

到這裏，我們可以看到，全鏈路壓測的壓測請求，都已經成型了。接下來，我們可以開始設計壓測流量在壓測對象中的行爲了。

測試環境

壓測可以在仿真環境、線上環境中進行。不同的環境，選取數據，製造數據都有不同的考量。如下圖所示：

簡單的說，測試環境關注的是單個組件：例如微服務、接口、但協議（SQL，Redis）等壓測；預發環境（通常是 VPC 環境）則關注鏈路整合；生產環境則最逼近真實場景。在這裏，我們只討論線上生產環境。

 傳統全鏈路壓測

下圖簡單的詮釋了傳統全鏈路壓測的運作方式；

我們看到，傳統的全鏈路壓測，主要通過流量打標，來區分壓測流量和真實流量，做到這一點，需要保證這個壓測標能夠被層層的透傳下去。而當流量到了 “寫” 的這層，部署好的 agent 根據壓測標，來決定 “寫” 的行爲，是寫到真實的數據庫呢？還是寫到影子區域？道理很簡單，但是實施的時候還是會碰到不少的難點。其中，主要涉及的問題是：

  1. 如果應用使用到的框架不標準，則需要進行適配；

  2. 推動開發安裝 agent 的流程複雜；

  3. 驗證 agent 的覆蓋面複雜。

 敏捷版的全鏈路壓測

如果我們不想要改造業務，也不想要掛載 agent，我們能如何去做到這一點呢？

我們來看一下抽樣測試的原理。在測試的時候，通常有一種手段，即通過選取幾個特定的真實用戶數據來進行測試，來驗證程序的正確性；如果我們把這些真實用戶數據，變成假用戶，那麼需要滿足下面這個關鍵條件：假用戶以及假用戶在這個業務場景下涉及到的業務數據，以及業務場景下相關的數據，都能夠被識別出來。

例如，我們模擬一個假用戶，購買某個假商品，這裏的用戶，商品，都能夠有一個特定的特徵，這個假用戶生成的瀏覽記錄、購買記錄，在數據庫的表現中都有該用戶的 ID；在這個前提下，我們是能夠把髒數據從真實數據中識別出來的；

這種壓測，需要盤點出以下兩點:

  1. 完整的找出業務涉及到的數據表 – 參考上一章節裏面的 PTS SQL 錄製功能；

  2. 製作影子數據 – 和傳統全鏈路壓測不一樣，這裏我們選取的是第三種方式，即在一張表裏做大位移，而不是製作影子表或者影子庫。壓測結束後，根據影子數據的特徵，巡檢數據庫並且進行清理；

這種方式，是基於使用者對業務有清晰的瞭解，製作出來的壓測數據有明顯的壓測標識（比正常數據大的多的偏移量），所有涉及的寫壓測，都帶有這些偏移量；這樣，所有壓測產生的數據，都能夠被識別出來。壓測結束之後，根據這個數據特徵，來清理壓測數據；

流量引擎的選擇

爲了更好的模擬用戶的行爲，我們常常會使用壓測地域的定製。但是把壓測引擎部署到全國各地是不現實的；而 PTS 可以方便的讓用戶選擇地域的發起，如下圖所示:

總結

PTS 結合 10 多年來阿里的全鏈路壓測的經驗，讓阿里雲的用戶可以如同享用滿漢全席般的享用全套標準的全鏈路壓測，也可以根據自己的需求，選擇最適合自己的方式。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/jleWtt0u_N0G_r7c3RWA5Q

猜你喜歡