全場景流量驗證系統

導讀

本文介紹了一種基於線上流量實現對重構系統進行功能和性能驗證的實踐方案。針對線上流量如何攔截、如何錄製、如何存儲、如何回放以及如何發壓均作了詳細說明，爲具有類似需求的讀者提供了一種可供參考的思路。

01 業務背景

在今年的敏捷團隊建設中，我通過 Suite 執行器實現了一鍵自動化單元測試。Juint 除了 Suite 執行器還有哪些執行器呢？由此我的 Runner 探索之旅開始了！

隨着百川項目的啓動，中臺需要對訂單流量收口，將 ECLP、各 BP 的接單入口全部切換至百川統一接單系統。且各個接單入口調用方式各異，有 JOS 請求（外部商家）、JSF 請求（如 TC），也有 MQ 異步消息（如 POP）。爲了確保各系統平穩切量，最大程度降低切量風險，需要在切量前做充分的流量驗證（包括功能驗證和性能驗證）。爲此，設計了一套全場景流量驗證系統，支持基於線上流量的 AB 驗證（功能驗證）、壓測（性能驗證），爲各業務線接單切量工作提供了可靠的基礎支撐。

02 名詞解釋

理解，首先 MCube 會依據模板緩存狀態判斷是否需要網絡獲取最新模板，當獲取到模板後進行模板加載，加載階段會將產物轉換爲視圖樹的結構，轉換完成後將通過表達式引擎解析表達式並取得正確的值，通過事件解析引擎解析用戶自定義事件並完成事件的綁定，完成解析賦值以及事件綁定後進行視圖的渲染，最終將目標頁面展示到屏幕。

引流：把各個接單入口所在系統的線上流量引入到流量驗證系統。 

錄製：複製線上流量並做持久化存儲。 

回放：把錄製的流量打到待驗證系統。 

切量：把接單流量從 ECLP 等老的接單系統切換到新的百川統一接單系統中。

AB 驗證：線上流量同時打到正式環境和 AB 環境，對兩個環境的結果做對比分析，驗證 AB 環境的正確性。

03 設計思路

理解，首先 MCube 會依據模板緩存狀態判斷是否需要網絡獲取最新模板，當獲取到模板後進行模板加載，加載階段會將產物轉換爲視圖樹的結構，轉換完成後將通過表達式引擎解析表達式並取得正確的值，通過事件解析引擎解析用戶自定義事件並完成事件的綁定，完成解析賦值以及事件綁定後進行視圖的渲染，最終將目標頁面展示到屏幕。

• 如何引流？可以在業務系統中引入流量代理的方式實現引流。

• 如何錄製？考慮需要支持大數據量以及複合查詢，選擇使用 ES 作爲持久化存儲方案。

• 如何回放？爲避免對各業務系統 Jar 包依賴，選擇使用 JSF 泛化調用實現流量回放。

• 是否有類似的系統可用？月光寶盒（jcase）：由京東零售開發的一款流量錄製回放系統。其支持流量錄製、回放功能，但是並不能滿足一些個性化的需求，比如按自定義業務規則錄製、切量控制等。

04 系統設計

4.1 總體設計

流量代理：通過攔截、過濾、上報將流量引流到驗證系統中。

錄製服務：接收流量代理引入的線上流量並做持久化存儲。

回放引擎：使用錄製的線上流量請求待驗證目標接口。

壓測引擎：使用錄製的線上流量向待驗證目標接口實現多線程發壓。

圖 1 流量驗證系統架構圖

流量驗證系統整體由流量代理、錄製服務、回放引擎以及壓測引擎四個模塊組成。

4.2 詳細設計

4.2.1 流量代理

通用流量代理

圖 2 通用流量代理

在業務系統中引入流量代理，通過流量代理攔截（JSF Filter 或 AOP）線上流量，並將流量通過異步 MQ 方式上報給錄製服務做持久化存儲。

JOS 流量代理

圖 3 JOS 流量代理

外部商家通過 HTTP 方式調用 JOS 平臺，JOS 平臺內部轉 JSF 調用接單服務。爲使外部商家無感，發佈一個和業務系統接口完全相同的 JSF 服務（虛服務），不同的是提供一個新的別名，通過 JOS 平臺配置切換到新的別名，這樣就把 JOS 流量引入到了錄製代理，然後再由錄製代理通過異步 MQ 方式將流量上報給錄製服務做持久化存儲。

4.2.2 流量存儲

錄製的流量持久化存儲到 ES，按照 [接口: 方法] 維度創建錄製任務，同一個錄製任務下的記錄主鍵均以錄製任務編號爲前綴，後綴爲數字遞增，最大後綴（緩存到 Redis 中）即該錄製任務下錄製的記錄總數。

ph8q8s

4.2.3 流量回放

支持單條、批量、按錄製任務維度批量回放。回放調用採用 JSF 泛化調用方式，避免了對業務系統 Jar 包的依賴。

流量回放的同時，支持配置對比服務，對比服務接收入參以及新老接口的出參結果，可以對新老接口處理結果進行對比分析，以驗證新接口功能的正確性。

4.2.4 流量壓測

爲了實現發壓的效果，需要採用多機、多線程併發的方式請求目標接口。但是多機、多線程共用了同一份錄製數據作爲壓力數據源。因此，在真正發壓之前，需要爲每個執行線程分配好數據，各個線程只取自己的數據，互不干擾。

發壓策略（主從架構，Master 分配，Slave 執行）

圖 4 壓測引擎發壓原理圖

壓測引擎採用主從架構，壓力機分主從節點，主節點負責接收壓測請求並分配壓測任務；從節點負責執行壓測任務。

數據分配策略（按量平均，餘數輪詢，滑動窗口）

圖 5 數據分配示例

計算窗口

按錄製任務中錄製總量，平均分配到各個線程，餘數再按輪詢方式分配給每個線程，分完爲止，這樣可以確定出每個線程分配的記錄條數（窗口大小）；

按窗口滑動

將所有錄製任務從左到右水平平鋪，每個線程按照自己窗口大小從左到右依次佔用錄製記錄。

05 業務實踐

5.1 切量驗證

以倉配 POP 接單接口切換爲例，我們需要用新的訂單中心替換原來的 ECLP-SO 系統。在正式切換之前，仍然由 ECLP-SO 系統提供線上接單服務，但同時會通過流量驗證系統錄製線上流量並回放到新的訂單中心。通過對比新老系統對相同接單請求的處理結果，驗證新的訂單中心的接單功能。經過充分功能驗證後纔會將接單流量切換到新的訂單中心，從而極大降低了切量的風險。

圖 6 流量驗證系統在 POP 切量中的應用

5.2 需求迭代

產品校驗服務是產品中心對外提供的一個核心接口，接口邏輯複雜，每一次需求迭代上線都面臨極大挑戰。即便是經過了測試環境、預發環境驗證，依然不能百分百保證上線後對線上業務沒有影響。畢竟測試環境、預發環境的驗證請求參數單一且有限，無法反映線上請求的多樣性和複雜性。因此，產品中心接入了流量驗證系統，每次有新的需求迭代上線前，首先錄製線上流量，使用線上真實流量在預發環境進行充分驗證後再做上線操作。這樣極大降低了由於驗證不充分，導致線上業務受損的幾率，爲線上業務提供了一層安全保障，提高了線上系統穩定性。

京東技術 京東官方技術公衆號，你想知道的京東技術前沿黑科技，全在這裏。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/nCJgMUHJb281a9kkO7IItw