無論在全鏈路壓測還是在系統功能測試方面，流量錄制回放功能是系統必備功能，也是業界各大公司持續建設的研發效能系統。

接下來以sandbox-repeater提供的簡易流量錄制回放系統為例，介紹一個錄制回放系統具備的基本功能，依葫蘆畫瓢，在真實應用中可以結合具體的系統架構、業務場景、質量保證方案需要做改進。

sandbox-repeater提供了standalone模式及遠程模式，standalone模式針對單機，把錄制的流量存儲在本地文件中；將配置文件中的repeat.standalone.mode置為false即可開啟遠程模式，遠程模式及接近真實應用場景的模式，實現對遠程服務節點的流量錄制回放功能。

對于一個待實現錄制回放功能的服務，需要經過服務注冊、錄制回放配置管理、錄制回放代理模塊安裝、錄制回放流量管理功能、回訪結果的diff功能（分析功能）

服務注冊

管理待附加流量錄制回放功能的服務節點，核心信息包括服務的地址信息（如ip端口，如果是集中管理的微服務，可以有服務id標識等）、服務名稱、產品線、所屬環境等信息。

節點上報的方式可以有主動上報或被動注冊兩種。

主動上報，就是服務定期會有心跳檢測機制實時上報到服務注冊接口地址。如果是rpc服務，可以在根據微服務發現管理機制基礎上進行服務的服務的統一維護即可。

被動注冊，就是通過手動的方式或其它間接方式來進行注冊，通常是一次性注冊，不具有活檢功能。

repeater提供了內部心跳上報機制，上報sandbox-module模塊的加載情況。

代理管理

此處的代理指sandbox及基于sandbox-module實現的repeater模塊，錄制回放的功能借助sandbox-repeater完成。關于sandbox-repeater的實現介紹參照上篇文章。

sandbox啟動方式分為兩種，一種是靜態agent方式，即在服務啟動時指定agent，另一種是動態agent方式，將sandbox attach到已經在運行中的java進程中。二者實現的效果是一樣的。

對于一個高度靈活的管理模塊，希望采用第二種方式，首先將部署腳本預先安裝到宿主機或者動態拷貝到宿主機相應目錄，執行腳本從cdn或其它存儲資源上下載安裝包，將代理代碼安裝到宿主系統所在機器，然后啟動代理，可以通過sandbox提供的api實現對sandbox-module的動態控制，比如啟動、卸載、重新加載，其它功能可以進行二次編碼實現。

配置管理

需要對那些接口、組件、方法進行錄制和回放，sandbox-repeater通過配置管理控制，并且有相應的配置規則，可以參照sandbox-repeater使用文檔。

完成配置編寫之后，需要將配置綁定并推送到響應節點，這樣才能在錄制回放中讀取內存中最新的配置運行。

流量管理

? ? ?流量錄制，目前一些資料實現的都是入口方法的請求｜響應的錄制回放，對過程中方法的錄制回放功能沒有過多的應用或相關分享。隨著我們對質量的追求日益精進，越發希望提供方法粒度的錄制回放功能。

流量錄制

? ? ? sandbox-repeater可以提供全鏈路方法級的流量錄制功能，在錄制過程中，會將需要錄制的方法結果存儲一個map對象中，key為traceId，當投遞結果時，從map中獲取該traceId的所有過程數據，裝配成record推送到queue隊列中，由一個異步線程進行消費發送給record api后存入數據庫。

流量mock

? ? ? sandbox-repeater中提到的流量回放應該準確來說是流量mock，通常說的流量回放指將請求流量通過直接或間接的方法打到指定服務的方式。?

? ? 通過調用sandbox機制實現的回放接口發送回放請求，將回放請求記錄事件總線，回放觸發器（發器訂閱了總線事件）獲取回放事件信息，通過回放事件入口函數的類型（只對入口函數事件進行回放，此處采用橋接模式，函數類型為回放器定義的類型）獲取回放器（比如http、redis、java、dubbo等），執行回放動作。比如http回放，解析請求的uri、參數，裝配好請求參數后，發送一個本地http請求。

錄制回放系統兩個關鍵問題是：錄制的流量去哪了？回放時的流量從哪獲取的？

sandbox-repeater配置中指定了流量上報和獲取的接口，可以實現流量的存儲。目前這種設計對于高并發流量的錄制功能是存在明顯瓶頸的，所以不能直接用在高并發系統的錄制功能中，需要對repeater進行進一步改造，比如將流量打入kafka，在進一步處理。

流量diff功能，這個是目前微服務系統質量保證的重要手段，設計的核心問題有：

對結果進行哪些維度的diff，如果完全匹配diff往往diff結果非常多；

針對回放過程中的依賴結果不同，如果進行diff。

未完待續.....

難點：

高并發下的性能瓶頸：高并發下的錄制回放問題，尤其支持方法粒度的mock能力；

多任務并發管理：多任務并非回放能力；

特殊場景錄制策略：統一trace內對方法、參數均相同的多次請求如何錄制、回放；