自動化測之各流量回放技術工具對比

MrZ大奇發表於2021-11-11

前言

在日常的測試工作中我們或多或少總會遇到下列問題:

1)服務架構升級或重構,需要驗證原始介面邏輯,對原有的一堆介面做迴歸

2)對於業務邏輯複雜的場景,每個迭代版本都需要大量的時間用於迴歸測試

3)編寫自動化用例時複雜場景造數麻煩,日常自動化維護成本高

4)構造壓測模擬資料麻煩

......等等

那麼從服務的所有環境來看,僅線上環境擁有場景豐富、資料真實、覆蓋全面的條件,那麼我們將線上環境的請求資料獲取下來,在指定的環境中模擬使用者請求基本上可解決或者優化上面的這些問題。因此有必要需要對流量回放這項技術探究一下,首先從資料總結和自身搭建講演來講,總結流量回放的大概流程可為:流量錄製 - 資料持久化 - 回放計劃 - 環境維護 - 流量回放 - 結果比對。其次,所謂工欲善其事,必先利其器,下面我們看一些常用的流量回放分類以及工具的優缺點。

工具分類

根據流量錄製的位置大致可分為:基於web伺服器錄製基於應用層錄製基於網路協議棧錄製

web伺服器錄製

方案:在服務上定製化程式碼

優點:請求型別比較多樣

缺點:不通用,維護成本高,會佔用大量線上資源

應用層錄製

方案:在閘道器或基於AOP切面進行錄製

優點:對程式碼無侵入、實現相對比較快捷簡單

缺點:會佔用線上部分資源、可能會對業務有影響

常用工具:Nginx外掛-ngx_http_mirror_moudle、Java-sandbox

網路協議棧錄製

方案:直接監聽網路埠,複製資料包方式錄製

優點:基本對應用無影響

缺點:比較偏向底層實現成本較高

常用工具:goReplay、tcpCopy、tcpReplay

常用工具介紹

ngx_http_mirror_module

image

流量請求到nginx後,nginx正常轉發請求到目標應用,同時複製流量到mirror服務後不再管控。

優點:

  • 原生模組支援,在nginx 1.13.4版本後內建該模組

  • 支援配置多份映象放大流量

  • 配置比較簡單,nginx-server將流量複製到mirror後無交集,達到對真實流量無影響目的

缺點:

  • 修改配置後需要執行“nginx -s reload”命令使變更生效,線上環境不建議這麼做

  • 實際業務中經由nginx轉發的模組較多,無法篩選指定請求

  • 只支援錄製http流量

  • mirror為子請求,當mirror未結束時,主請求的記憶體無法釋放,可導致nginx效能下降甚至阻塞

TcpCopy

專案地址:https://github.com/session-replay-tools/tcpcopy

image

流轉示意圖:
image

TcpCopy主要有tcpcopy和intercept兩個模組組成,tcpcopy模組執行線上上機器,主要負責捕獲線上請求並修改請求頭中的目標地址和 源地址,然後使用raw socket輸出技術傳送資料包到目標伺服器。目標伺服器上根據配置的資訊將響應資料包路由到intercept輔助伺服器。intercept輔助將提取的響應頭資訊傳送給tcpcopy。tcpcopy利用收到的資訊修改捕獲的資料包屬性併傳送至目標伺服器。

優點:

  • 使用線上的真實資料
  • 適合高併發場景
  • 對目標伺服器基本無干擾
  • 支援複製基於TCP任意層協議的流量

缺點:

  • 由於只做資料包複製未做流量異常鑑別,可能導致異常資料進入目標伺服器
  • 無法對應用層的資料進行篩選和修改
  • 可能會丟失資料包導致請求丟失

GoReplay

專案地址:https://github.com/buger/goreplay

image

GoReplay是基於Go語言實現與Tcpdump一樣都是依賴pcap庫,主要監聽網路介面流量來錄製流量,支援線上和離線方式回放流量

優點:

  • 輕量程式基本無需配置,環境準備簡單
  • 程式資源消耗少,無侵入應用執行環境
  • 提供不限制語言的外掛機制,方便擴充

缺點:

  • 社群版僅支援錄製http協議,且與核心邏輯耦合,應用面不廣泛
  • 大公司使用少,整體成熟度不高

Jvm-sandbox-repeater

專案地址:https://github.com/alibaba/jvm-sandbox-repeater

image

使用jvm-sandbox沙箱技術,通過Java agent或者attach方式掛載到Java應用上。repeater模組根據配置的規則錄製或回放資料,console模組主要負責觸發和資料互動。

優點:

  • 通過位元組碼增強的方式可以直接錄製Java方法、子呼叫
  • 對業務程式碼0侵入
  • 模組功能豐富

缺點:

  • 對服務執行環境有一定侵入
  • 在掛載瞬間會佔用較多的機器資源,當業務量大時可能會導致服務夯住
  • 當前功能不完善,需要程式碼開發能力

總結

通過技術方案可以方便我們利用線上真實流量驗證壓測、自動化、迴歸等場景,根據自己實際的需求選擇合適的工具,但一切以不影響線上服務的穩定可用為前提。也期待後續會有更多的更完善的流量回放方案。

相關文章