本文介紹了一種基於線上流量實現對重構系統進行功能和性能驗證的實踐方案。針對線上流量如何攔截、如何錄製、如何存儲、如何回放以及如何發壓均作了詳細說明，為具有類似需求的讀者提供了一種可供參考的思路。 ...
本文介紹了一種基於線上流量實現對重構系統進行功能和性能驗證的實踐方案。針對線上流量如何攔截、如何錄製、如何存儲、如何回放以及如何發壓均作了詳細說明，為具有類似需求的讀者提供了一種可供參考的思路。
1 業務背景
隨著百川項目的啟動，中台需要對訂單流量收口，將ECLP、各BP的接單入口全部切換至百川統一接單系統。且各個接單入口調用方式各異，有JOS請求（外部商家）、JSF請求（如TC），也有MQ非同步消息（如POP）。為了確保各系統平穩切量，最大程度降低切量風險，需要在切量前做充分的流量驗證（包括功能驗證和性能驗證）。為此，設計了一套全場景流量驗證系統，支持基於線上流量的AB驗證（功能驗證）、壓測（性能驗證），為各業務線接單切量工作提供了可靠的基礎支撐。
2 名詞解釋
- 引流：把各個接單入口所在系統的線上流量引入到流量驗證系統。
- 錄製：複製線上流量並做持久化存儲。
- 回放：把錄製的流量打到待驗證系統。
- 切量：把接單流量從ECLP等老的接單系統切換到新的百川統一接單系統中。
- AB驗證：線上流量同時打到正式環境和AB環境，對兩個環境的結果做對比分析，驗證AB環境的正確性。
3 設計思路
如何引流？
可以在業務系統中引入流量代理的方式實現引流。
如何錄製？
考慮需要支持大數據量以及複合查詢，選擇使用ES作為持久化存儲方案。
如何回放？
為避免對各業務系統Jar包依賴，選擇使用JSF泛化調用實現流量回放。
是否有類似的系統可用？
月光寶盒（jcase）：由京東零售開發的一款流量錄製回放系統。其支持流量錄製、回放功能，但是並不能滿足一些個性化的需求，比如按自定義業務規則錄製、切量控制等。
4 系統設計
4.1 總體設計
流量代理：通過攔截、過濾、上報將流量引流到驗證系統中。
錄製服務：接收流量代理引入的線上流量並做持久化存儲。
回放引擎：使用錄製的線上流量請求待驗證目標介面。
壓測引擎：使用錄製的線上流量向待驗證目標介面實現多線程發壓。
4.2 詳細設計
4.2.1 流量代理
1）通用流量代理
在業務系統中引入流量代理，通過流量代理攔截（JSF Filter或AOP）線上流量，並將流量通過非同步MQ方式上報給錄製服務做持久化存儲。
2）JOS流量代理
外部商家通過HTTP方式調用JOS平臺，JOS平臺內部轉JSF調用接單服務。為使外部商家無感，發佈一個和業務系統介面完全相同的JSF服務（虛服務），不同的是提供一個新的別名，通過JOS平臺配置切換到新的別名，這樣就把JOS流量引入到了錄製代理，然後再由錄製代理通過非同步MQ方式將流量上報給錄製服務做持久化存儲。
4.2.2 流量存儲
錄製的流量持久化存儲到ES，按照[介面:方法]維度創建錄製任務，同一個錄製任務下的記錄主鍵均以錄製任務編號為首碼，尾碼為數字遞增，最大尾碼（緩存到Redis中）即該錄製任務下錄製的記錄總數。
| 屬性名 | 示例值 | 示例值 |
|---|---|---|
| id | RT7625109167934456_1 | 主鍵標識 |
| recordData | {"args":[{"fakeNo":"fakeNo001"}],"argsType":["cn.jdl.baichuan.router.replay.contract.domain.fake.FlowFakeRequest"],"attachments":{"traceId":"8112206384546625","type":"1"},"clazzName":"cn.jdl.baichuan.router.replay.contract.service.RouterFlowFakeService","methodName":"match","resultObj":true} | 錄製的body體 |
| recordTaskNo | RT7625109167934456 | 所屬錄製任務編號 |
| timestamp | 1636719778929 | 時間戳 |
4.2.3 流量回放
支持單條、批量、按錄製任務維度批量回放。回放調用採用JSF泛化調用方式，避免了對業務系統Jar包的依賴。
流量回放的同時，支持配置對比服務，對比服務接收入參以及新老介面的出參結果，可以對新老介面處理結果進行對比分析，以驗證新介面功能的正確性。
4.2.4 流量壓測
為了實現發壓的效果，需要採用多機、多線程併發的方式請求目標介面。但是多機、多線程共用了同一份錄製數據作為壓力數據源。因此，在真正發壓之前，需要為每個執行線程分配好數據，各個線程只取自己的數據，互不幹擾。
發壓策略（主從架構，Master分配，Slave執行）
壓測引擎採用主從架構，壓力機分主從節點，主節點負責接收壓測請求並分配壓測任務；從節點負責執行壓測任務。
數據分配策略（按量平均，餘數輪詢，滑動視窗）
1）計算視窗
按錄製任務中錄製總量，平均分配到各個線程，餘數再按輪詢方式分配給每個線程，分完為止，這樣可以確定出每個線程分配的記錄條數（視窗大小）；
2）按視窗滑動
將所有錄製任務從左到右水平平鋪，每個線程按照自己視窗大小從左到右依次占用錄製記錄。
5 業務實踐
5.1 切量驗證
以倉配POP接單介面切換為例，我們需要用新的訂單中心替換原來的ECLP-SO系統。在正式切換之前，仍然由ECLP-SO系統提供線上接單服務，但同時會通過流量驗證系統錄製線上流量並回放到新的訂單中心。通過對比新老系統對相同接單請求的處理結果，驗證新的訂單中心的接單功能。經過充分功能驗證後才會將接單流量切換到新的訂單中心，從而極大降低了切量的風險。
5.2 需求迭代
產品校驗服務是產品中心對外提供的一個核心介面，介面邏輯複雜，每一次需求迭代上線都面臨極大挑戰。即便是經過了測試環境、預發環境驗證，依然不能百分百保證上線後對線上業務沒有影響。畢竟測試環境、預發環境的驗證請求參數單一且有限，無法反映線上請求的多樣性和複雜性。因此，產品中心接入了流量驗證系統，每次有新的需求迭代上線前，首先錄製線上流量，使用線上真實流量在預發環境進行充分驗證後再做上線操作。這樣極大降低了由於驗證不充分，導致線上業務受損的幾率，為線上業務提供了一層安全保障，提高了線上系統穩定性。
作者：京東物流 朱永昌
來源：京東雲開發者社區 自猿其說Tech 轉載請註明來源
