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 最近價格上也做了 “靈活” 優化，更多的選擇，點選此處即可檢視～