導語
AREX 是一款由攜程開源的流量回放平台，孵化于機票BU内部。聚焦錄制回放核心鍊路的建設，從基礎方案建設到核心事業線的深入落地驗證，在集團複雜業務場景下不斷疊代和優化下，積累了大量經驗，取得了可見的成果。在攜程落地至今已有 4000+ 應用接入，傳遞率和缺陷數均有所改善。
本篇文章主要介紹AREX在攜程内部落地實踐過程中遇到的一系列挑戰和解決方案，以及如何通過AREX快速部署一站式流量錄制回放解決方案來降低接入成本，快速落地。
一、背景
流量錄制回放技術在性能測試、回歸測試、自動化測試以及線上問題快速修複方面有廣泛的應用前景，可以幫助技術團隊解決複雜業務場景和系統架構下的穩定性保障及研發過程中的效率問題。
然而在技術方案落地時，會面臨很多的挑戰，比如基礎設施建設難度大、前期投入成本和收益不成正比、落地場景模糊不清等。
二、方案
目前市場上已知的開源解決方案大部分都是在Jvm-Sandbox-Repeater基礎上進行二次開發和改造，核心原理也都是通過錄制線上真實流量然後在測試環境進行回放，驗證代碼邏輯正确性。那麼可能有人會問：既然已有成熟的解決方案，為什麼還要“重複造輪子”?
首先，JVM SandBox支援的元件有限，遠不能滿足攜程内部廣泛使用的中間件和架構。且JDK底層的支援也不夠徹底，比如異步線程上下文傳遞，需要依賴其他第三方元件。
其次，Jvm-Sandbox-Repeater雖然提供了基本的錄制和回放功能，但若要建構一個完整的業務回歸測試解決方案，我們還需要一個完善的背景支援系統，負責資料的采集、存儲和比對工作。
最後，官方文檔的缺乏以及社群活躍度的不足，使得我們在後續的二次開發過程中可能面臨無法及時獲得官方支援的風險。
基于這些考慮，我們決定自主研發流量錄制回放平台AREX：
1）支援更廣泛的中間件群組件錄制與回放，而且能夠模拟各種複雜的業務場景，如本地緩存、目前時間等。
2）作為一個全面的解決方案，還要配備有完善的配套設施，如前端界面、回放服務和報告分析等，實作從流量采集、流量回放，到比對驗證、生成報告的一站式工作流程（如下圖所示）。
下面，我們将深入探讨實施過程中遭遇的挑戰、針對性的解決政策，以及攜程内部的應用執行個體，希望可以為大家的實踐提供實質性的幫助和指導。
三、技術挑戰
3.1 跨線程、異步場景下的流量采集
流量錄制需要把一次業務請求裡涉及到的所有鍊路節點采集下來，不僅是主入口的，還有内部調用各種架構的請求和響應，如Mybatis、Redis、Dubbo等。然而公司很多項目會使用到線程池，異步程式設計的場景，比如在一次請求中主流程會Fork出很多子任務/線程并行工作，有些任務查詢Redis，有些會調用RPC接口、有些去操作資料庫等完成不同的業務場景，底層也會牽涉到大量線程的切換。
這樣就需要保證在一次請求中把這些在不同線程裡執行的操作都采集下來，我們是通過Trace傳遞的思路解決這個問題的，即通過修飾各種線程池和異步架構，使用一個recordId線上程間傳遞的方式串聯起來，完成一次完整的用例錄制。比如Java裡的CompletableFuture、ThreadPoolExecutor、ForkJoinPool、第三方的Tomcat、Jetty、Netty使用的線程池，以及異步架構Reactor、RXJava等，實作不同線程間的傳遞。
3.2 非幂等接口回放不産生髒資料
例如，在訂單落庫和調用第三方支付接口等關鍵場景中，流量回放時需確定利用Mock來避免實際資料互動。這樣做可以防止在測試過程中産生不必要的資料，進而避免對正常業務流程造成幹擾。流量回放的核心機制在于攔截并Mock架構調用，使用錄制的資料來替代真實的資料請求，確定測試過程中不會發生任何真實的外部互動，如資料庫寫入操作或第三方服務調用，進而有效防止回放測試中髒資料的寫入。
目前我們的Java Agent已支援Spring、Dubbo、Redis、Mybatis等開源架構，完整清單請參考下方。
3.3 因登入鑒權、token過期問題引起的回放失敗
在實際的流量回放過程中，我們經常遇到這樣的問題：許多Web應用在接口通路前實施了登入鑒權校驗。如果鑒權失敗或登入的token已經過期，接口通路将被拒絕，這可能導緻大量用例在回放時失敗。雖然可以通過配置白名單來解決部分問題，但我們尋求的是一種更為通用的解決方案。
理想的方案是在回放過程中，能夠Mock如Spring Security、Apache Shiro、JWT等鑒權架構，進而繞過鑒權和token校驗步驟，確定接口能夠在回放環境中正常執行。
3.4 時間敏感業務，如支付逾時場景回放
如果錄制時的目前時間和回放時的目前時間不一緻，可能會導緻一些逾時判斷邏輯出現預期外的差異。例如，在判斷訂單是否逾時未支付的場景中，我們通常會使用 currentTime - orderCreateTime > 30 分鐘 作為判斷依據。如果在錄制時訂單尚未逾時，但在半小時後進行回放時，由于系統目前時間的變化，可能會錯誤地觸發支付逾時的處理邏輯。
為了解決這一問題，我們提出了一種解決方案：在錄制過程中，同時記錄下當時的目前時間，并僅錄制一次。在回放過程中，通過Mock與目前時間相關的類，如 Date、Calendar、LocalTime、joda.time 等，使得回放時使用的目前時間實際上是錄制時記錄的時間。這樣可以保證在回放過程中，與時間相關的邏輯判斷能夠與錄制時保持一緻，進而確定測試結果的準确性和可靠性。
3.5 本地緩存問題
在應用中，為了提高性能，通常會将一些常用資料存儲在本地緩存中以供快速通路。然而，在流量錄制回放的場景中，緩存的行為可能會對回放結果産生影響。
在錄制過程中，如果請求的資料已經被緩存，那麼系統會直接從緩存中提供資料，而不會觸發對資料庫或外部接口的查詢。但在回放環境中，由于缺乏預先加載的緩存資料，相同的請求可能會導緻應用程式去查詢資料庫或調用外部接口，産生新的調用（new call），導緻回放失敗。
為了解決這一問題，我們實作了對流行緩存架構的支援，如 Guava Cache 和 Caffeine Cache，確定在回放時能夠模拟緩存的行為并保持一緻性。這樣一來，在回放過程中，即使是對緩存的請求也能按照錄制時的狀态傳回預期的結果，避免了不必要的新調用。
對于那些使用自定義緩存架構的情況，AREX 平台提供了靈活的配置選項，允許通過動态類的方式進行适配。這意味着即使是非标準的緩存實作，也能夠被 AREX 平台相容并正确地進行流量回放。
以上解決方案都是預設支援，基本不需要額外處理，另外如果是公司内部研發的架構也需要錄制回放的話，可以以插件的方式擴充。
四、落地挑戰
4.1 安裝部署要做到簡單便捷，快速上手，減少接入成本
AREX是一套完整的解決方案，除基本的錄制回放功能外，還有前端、排程、報告分析、存儲等配套服務。本着開箱即用、快速接入的原則，AREX提供了多種部署方式：一鍵部署、非容器部署、私有雲部署的方式，安裝完成後隻需配置一些基礎參數即可自動采集流量和進行回放對比差異：
此外AREX還支援單機模式，可以在本地不需要安裝的情況下快速上手體驗。
4.2 符合公司風控、資料安全要求
錄制生産上真實流量時，在涉及安全或者一些商業性敏感資料的情況下，還需要針對某些敏感資訊通過脫敏規則進行資料的變形，實作敏感隐私資料的可靠保護。
AREX選擇在進行資料落庫時對資料進行脫敏，以保護敏感資訊的安全性。具體實作方式是通過 SPI 機制，加載外挂 JAR 包，動态加載加密方式。
4.3 提高使用者體驗，快速定位問題
在實際使用過程中，錄制和回放的用例數量巨大，為了減輕使用者分析差異時的工作量，AREX對存在相同差異的場景用例進行了聚合，加快排查問題的速度。
通過調用鍊可以快速定位問題所在範圍，并且對時間戳、uuid、ip等噪音節點進行降噪，減少幹擾。
如果是一些業務比較複雜的應用線上問題本地難以複現時，AREX也支援在本地進行調試快速排查問題。
4.4 技術方案是否成熟、安全、可靠
AREX基于Java Agent技術，采用業界成熟的位元組碼修飾架構ByteBuddy，安全穩定，代碼隔離，帶有自我保護機制，在系統繁忙時會智能降低或關閉資料采集頻率。且在攜程集團内部已穩定運作2年有餘，線上得到充分驗證。
五、最佳實踐
目前流量錄制回放服務作為獨立的選項內建到公司的CI/CD系統中：
1）首次接入流程：在首次接入流量錄制回放時，隻需在 CI Pipeline 選擇 Flight AREX Agent 服務，這樣在應用打包成鏡像的過程中，會把 AREX 啟動腳本 arex-agent.sh 包含在釋出包内。
2）釋出與 Agent 加載：在應用釋出過程中，先前的腳本啟動後會拉取最新的 arex-agent.jar，并通過修改 JVM Options 挂載 AREX Agent（-javaagent:/arex-agent.jar）。
3）版本控制與灰階釋出：啟動腳本後會根據應用的 AppId 拉取與之比對的 arex-agent.jar 版本，實作灰階釋出和按需加載，比如隻有某些特定的應用會加載 Agent 新功能。
同樣，如果是首次回放，操作也很簡單：
1）建立Pipeline：在 Gitlab 或 Jenkins 中，建立一個 Pipeline，在 ArexTest Job 腳本中調用 AREX 提供的回放位址，定時執行流水線。
2）自動觸發流量回放：研發人員在送出代碼後會自動觸發流量回放。
3）回放結果推送與釋出控制：回放完成後 AREX 會把回放用例數、通過率、失敗率等名額推送給相關人員做統計和分析，隻有當通過率達到預定标準時，代碼才被允許釋出到生産環境。
下圖是 AREX 流量錄制回放平台在公司研發測試釋出各個環節如何發揮作用的，供大家參考：
針對每次疊代，代碼送出後測試自動執行，并回報測試報告，開發和測試人員隻需要關注在新業務的研發、驗證上即可，脫離那些繁瑣的資料和腳本，通過流量回放在軟體研發全生命周期内進行多環節針對性優化、合力賦能，形成一個自動化測試和持續內建的閉環。
六、落地成果
在攜程集團複雜業務場景不斷疊代和優化下，目前已有 4000+ 應用接入，傳遞率和缺陷數均有所改善：
七、擁抱開源
在攜程内部經過長期穩定運作并驗證其可靠性後，我們在2023年将AREX平台開源（https://github.com/arextest），希望能夠幫助更多企業高效、低成本地把流量錄制回放技術解決方案落地。
過去一年，我們緻力于開源社群的建設，目前已有上千個外部使用者接入使用AREX。
AREX的願景是是在需求快速疊代的同時保障品質，降低成本，提升效能。這一願景已在攜程及衆多開源使用者的實踐中得到驗證，帶來了顯著的業務價值。
展望未來，我們将持續依托活躍的社群力量，響應并解決使用者的疑問，不斷優化AREX。在此誠邀每一位開發者加入社群并試用，共同見證AREX的成長與進步。
作者簡介
攜程AREX團隊，機票品質工程組，主要負責開發自動化測試工具和技術，以提升品質和能效。
來源-微信公衆号:攜程技術
出處:https://mp.weixin.qq.com/s/q-j_pFObn4yw8WzxKE8-jg