簡介： PTS 結合 10 多年來阿里的全鏈路壓測的經驗，讓阿里雲的使用者可以如同享用滿漢全席般的享用全套標準的全鏈路壓測，也可以根據自己的需求，選擇最適合自己的方式。
作者：子矜
客戶的故事
全鏈路壓測被譽為大促備戰的 “核武器” ，如果之前有關注過阿里雙 11 相關的技術總結，對 “全鏈路壓測” 一定不會陌生，這個詞的出場率幾乎 100%。從對雙 11 穩定性的價值來看，用 “核武器” 來形容全鏈路壓測毫不為過。
在某知名電商大促中，該電商平臺也想用全鏈路壓測來為自己的大促提前排除風險。但是他遇到幾個困難:
- 全鏈路壓測是一個需要多角色參與的活動：業務方，測試，運維，研發，資料庫，都需要參與進來。然而能夠像阿里具備成熟的組織體系，可以強有力的推動各種不同的角色，都是需要較長時間來積累的。
- 全鏈路壓測，常常涉及到框架的改造：而該電商平臺的業務複雜，做結構梳理與業務改造並不現實。
那這個知名電商平臺，有什麼辦法可以在 1 個星期之內，不進行業務改造，不改變業務部署，就能夠用上全鏈路壓測呢？
接下來的內容，我們會從全鏈路壓測的原理開始，並引入基於同樣原理的 “敏捷版” 全鏈路壓測，讓該知名電商平臺能夠在 2 周之內就能用上全鏈路壓測的方案。
全鏈路壓測
首先，我們來看看阿里的全鏈路壓測，到底解決了什麼問題：
全鏈路壓測實際上解決的問題是：在線上的壓測。線上壓測，能夠最快、最直接的發現線上的問題。然而，線上壓測會帶來資料汙染的問題：如何把壓測資料和真實資料區分開來，是壓測裡至關重要的一點。那麼，阿里是怎麼做的呢？我們一起來看下圖：
阿里的全鏈路壓測具有一套成熟又複雜的系統：壓測的梳理、構建、準備、傳送。然而，這套體系對於一個雲上的使用者是需要長期建設得到的。那我們如何能夠讓使用者快速，敏捷的享受這套技術呢？
在這裡，PTS 把整個流程進行沉澱，都以標準化的輸出來提供給雲上的使用者。使用者可以直接享用一整套的全鏈路壓測體系，也可以在壓測的關鍵環節：例如場景梳理、請求構建、壓測環境、壓測等步驟中，根據自己的需求來定製自己想要的壓測效果。
場景梳理
業務場景，即對應的是壓測的輸入請求。這是壓測第一步，也是最重要的一步。最常見的是把涉及到業務的 URL 進行梳理，彙總。例如下圖就是一個常見的場景彙總：
然而，這是不夠的。當若干個 URL 彙總成一個場景之後，URL 之間的比例、時間間隔，也是影響業務場景的關鍵。用常見的場景打一個比方：一個使用者的下單，可能背後蘊含著 10 個使用者登入，每個使用者平均瀏覽了 4 個商品，每個商品中平均被瀏覽了 5 個評價，最後一個使用者在 10 點大促開始的時候，購買了一個商品。
這些 URL 之間的關係、時間點，需要人員有豐富的業務知識才能梳理清楚。為此，PTS 提供服務端流量錄製的功能，方便使用者來錄製流量，並且輕鬆的得到其中不同維度的比例關係:
如上圖所示，使用者可以清晰的得到 URL 之間的比例關係、使用者 URL 之間的時間行為等等。基於這個梳理好的資料模型，使用者可以在這個基礎上進行裁剪。
測試資料構造
接下來，就是構造使用者資料了。這一步涉及的角色最多，也最為繁瑣。整個資料構造由三個步驟構成，如下圖所示：
首先是資料發現。通常，我們可以透過人工業務梳理，得到該業務所涉及到的所有表，並進行分析。PTS 為免除這個煩惱，和DMS打通，提供表結構預覽，讓測試人員方便的看清楚和場景相關聯的結構，大大的提升效率。
如果還是覺得太複雜，PTS將提供資料錄製工具，安裝了這個 agent 之後，該業務所涉及的表，都會被完整的記錄下來：
有了這些工具，測試人員就可以無須 DBA 的協助，輕鬆的得到場景關聯的表資訊了。
資料閉包
有了這些資料表，並且在這基礎之上分析出來資料閉包後，我們可以開始製作壓測資料了。通常，我們製作影子表的方式有三種:
- 影子庫 – 全量的進行影子庫對映。該方法的優勢是簡單，劣勢是消耗資源多；
- 影子表 – 將表閉包裡的表，透過一定規則，進行名字關聯。該方法的優勢是節省資源，劣勢是需要對錶進行充分梳理，並且一一對應；
- 不新建表，在同一張表內，將影子資料進行大位移偏移。這個將在後面的敏捷版內進行介紹。
這三種方式可以根據需求組合使用。
資料匯入/混擾
有了這些前提之後，我們可以利用 DMS 來資料匯入，進行資料製作了。
到這裡，我們完成了全鏈路壓測中最複雜的兩個步驟：壓測場景梳理、壓測資料製作。
接下來我們透過資料加工，把這兩個元素最終加工為壓測資料。
資料加工
此時，我們對壓測資料做最後一個步驟，進行資料加工。即我們把業務場景、壓測資料，按照我們的業務模型進行最後的調整與加工:
到這裡，我們可以看到，全鏈路壓測的壓測請求，都已經成型了。接下來，我們可以開始設計壓測流量在壓測物件中的行為了。
測試環境
壓測可以在模擬環境、線上環境中進行。不同的環境，選取資料，製造資料都有不同的考量。如下圖所示：
簡單的說，測試環境關注的是單個元件：例如微服務、介面、但協議（SQL，Redis）等壓測；預發環境（通常是VPC環境）則關注鏈路整合；生產環境則最逼近真實場景。在這裡，我們只討論線上生產環境。
傳統全鏈路壓測
下圖簡單的詮釋了傳統全鏈路壓測的運作方式；
我們看到，傳統的全鏈路壓測，主要透過流量打標，來區分壓測流量和真實流量，做到這一點，需要保證這個壓測標能夠被層層的透傳下去。而當流量到了 “寫” 的這層，部署好的 agent 根據壓測標，來決定 “寫” 的行為，是寫到真實的資料庫呢？還是寫到影子區域？道理很簡單，但是實施的時候還是會碰到不少的難點。其中，主要涉及的問題是：
- 如果應用使用到的框架不標準，則需要進行適配；
- 推動開發安裝 agent 的流程複雜；
- 驗證 agent 的覆蓋面複雜。
敏捷版的全鏈路壓測
如果我們不想要改造業務，也不想要掛載 agent，我們能如何去做到這一點呢？
我們來看一下抽樣測試的原理。在測試的時候，通常有一種手段，即透過選取幾個特定的真實使用者資料來進行測試，來驗證程式的正確性；如果我們把這些真實使用者資料，變成假使用者，那麼需要滿足下面這個關鍵條件：假使用者以及假使用者在這個業務場景下涉及到的業務資料，以及業務場景下相關的資料，都能夠被識別出來。
例如，我們模擬一個假使用者，購買某個假商品，這裡的使用者，商品，都能夠有一個特定的特徵，這個假使用者生成的瀏覽記錄、購買記錄，在資料庫的表現中都有該使用者的 ID；在這個前提下，我們是能夠把髒資料從真實資料中識別出來的；
這種壓測，需要盤點出以下兩點:
- 完整的找出業務涉及到的資料表 – 參考上一章節裡面的PTS SQL錄製功能；
- 製作影子資料 – 和傳統全鏈路壓測不一樣，這裡我們選取的是第三種方式，即在一張表裡做大位移，而不是製作影子表或者影子庫。壓測結束後，根據影子資料的特徵，巡檢資料庫並且進行清理；
這種方式，是基於使用者對業務有清晰的瞭解，製作出來的壓測資料有明顯的壓測標識（比正常資料大的多的偏移量），所有涉及的寫壓測，都帶有這些偏移量；這樣，所有壓測產生的資料，都能夠被識別出來。壓測結束之後，根據這個資料特徵，來清理壓測資料；
流量引擎的選擇
為了更好的模擬使用者的行為，我們常常會使用壓測地域的定製。但是把壓測引擎部署到全國各地是不現實的；而PTS 可以方便的讓使用者選擇地域的發起，如下圖所示:
總結
PTS 結合 10 多年來阿里的全鏈路壓測的經驗，讓阿里雲的使用者可以如同享用滿漢全席般的享用全套標準的全鏈路壓測，也可以根據自己的需求，選擇最適合自己的方式。
本文為阿里雲原創內容，未經允許不得轉載。
