流量錄製回放,不是銀彈!

前幾天在技術交流羣,大家又討論起了流量錄製回放的話題。我觀察了一下,討論的人不少,大體有這兩種觀點:

第一種觀點認爲,流量錄製回放的應用前景很廣闊,能大幅度提高測試效率和技術逼格,都想在自己團隊落地,但需要一些最佳實踐參考;第二種觀點則認爲只有大廠才能做這個實踐,小公司就別想了。

我無法完全贊成或者反對這兩種觀點,只能結合自己的一些實踐經驗和看到過的案例,談談我對流量錄製回放的看法。

 

什麼是流量錄製回放?

流量錄製回放,就是通過錄制線上的真實流量,然後在測試或者生產環境模擬請求進行驗證的一種技術方法。

簡單理解其實和我們利用其他工具(比如JMeter/postman)構造請求,然後根據返回的響應數據判斷測試是否通過的本質相同。

兩者的區別在於:流量錄製回放的機器執行佔比較多,而傳統的利用測試工具來發送請求手段,人工介入的佔比較多。

關於流量錄製回放這個概念和技術實踐,最早是在2010年,由英國公司Riverbed Technology開發,用於網絡性能監控和診斷,以便在出現問題時進行快速診斷和解決。

而國內,最出名的應該是阿里在2019年開源的流量錄製回放工具:JVM-Sandbox-Repeater。

JVM-Sandbox-Repeater最初要解決的是線上全鏈路壓測時遇到的一些問題,主要如下:

  • 模擬請求和真實用戶請求存在偏差;
  • 線上全鏈路壓測對系統存在一定的侵入;
  • 模擬請求無法完全覆蓋特定的業務流程和場景;

後來隨着經驗的累積和技術的不斷迭代優化,也用來解決其他方面的測試問題,比如:

  • 線上bug在測試環境的復現;
  • 服務重構和複雜系統調用關係下的迴歸測試問題;
  • 業務越複雜,系統越龐大,接口自動化測試用例維護成本越高;

目前關於流量錄製回放的工具有不少,下面是主要的幾種工具:

  • ngx_http_mirror_module:Nginx內置的模塊,提供流量複製功能;
  • TcpCopy:一個開源的流量回放工具,支持多種類型流量的實時及離線回放;
  • Sharingan:基於Golang的流量錄製回放工具,通過修改Golang源碼,加鉤子攔截並鏡像流量;
  • GoReplay:Golang編寫的開源工具,利用gopacket庫,基於libpacp抓包並利用go的協程特性實現回放速率控制;
  • JVM-SANDBOX-Repeater:JVM-Sandbox生態體系下的重要模塊,插件式設計可以快速適配各種中間件,封裝請求錄製/回放基礎協議,提供了很多通用可擴展的API;

 

流量錄製回放的優劣點

如上所述,流量錄製回放技術的應用場景很豐富,在性能測試、迴歸測試、自動化測試以及線上問題快速修復方面有廣泛的應用前景,可以幫助技術團隊解決複雜業務場景和系統架構下的穩定性保障以及研發過程效率問題。

但問題來了,看似完美的技術方案在團隊中落地時,要面臨很多的挑戰,主要有如下幾點:

  • 絕大多數業務都有各種登錄狀態校驗和風控安全考量,錄製的數據面臨各種校驗不通過的問題;
  • 很多業務場景非冪等,比如某商品只允許同一ID下單一次,比如三方支付回調和三單匹配問題;
  • 很多系統存在各種內外部依賴調用,而錄製的數據如果不經過處理直接回放,很多場景會報錯;

上述三點主要是技術層面的挑戰,但在實際的工作場景中,很多技術無法落地的原因往往不是技術本身的問題,而是投入產出比的問題。

首先,流量錄製回放本身對一個團隊的基礎技術設施建設要求較高,這背後就是高昂的前期投入成本和時間成本。

其次錄製的數據要保存、脫敏、加工處理,還要和業務鏈路以及場景匹配,這個過程只能由工程師人工來進行,且不是短時間就能梳理清楚的,這又是成本的一部分。

再次,一個技術方案從調研到完全落地,這個過程需要一定的試錯成本,也需要時間和人力資源去配合,在降本增效大環境下,企業很難在短期內看不到明顯直接效益的方向投入鉅額成本。

最後也是最關鍵的一點,技術團隊從上到下都揹負着KPI,越是優秀複雜的技術,落地所需的時間和人力成本越高,KPI會倒逼領導做出短視的決定,這無關對技術的信仰和認可,只關乎個人的職場生存問題。

也難怪大家說,優秀的技術實踐是一種只會發生在大公司的富貴病。

 

技術落地要考慮的因素

最後分享一些我個人實踐流量錄製回放時的經驗總結,大家避免踩坑。

  1. 流量錄製回放技術,更適合複雜業務+複雜系統架構+高併發高性能的系統。因爲複雜和高併發,背後纔有更高的商業利潤和問題的修復成本,落地的可行性才越強。
  2. 技術建設和實踐是逐步迭代的,如果團隊的基礎技術設施建設一般,比如CICD、灰度發佈、自動化測試和線上全鏈路壓測等沒有較爲豐富的實踐經驗,不建議去實踐流量錄製回放。
  3. 就技術實踐來說,流量錄製回放要解決這幾點核心問題:環境隔離、應急預案、仿真用戶數據、數據加工處理以及完善的mock手段。
  4. 流量錄製回放並不能直接發現多少線上問題,相比於投入鉅額成本和時間去落地流量錄製回放,還不如在這幾個領域多投入:捋清需求、編碼規範、項目管理、分支和環境管理。

最後我要說的是,流量錄製回放是看似美味實則難以下嚥的技術盛宴,多瞭解借鑑它的思路沒錯,但在決定落地前一定要全方位考慮清楚。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章