部門：業務中台/測試開發
一、流量回放介紹1.1 流量回放是什麼流量回放是系統重構、拆分、中台化時重要的自動化回歸手段。通過採集可錄製流量，在指定環境回放，再逐一對比每個調用和子調用差異來發現接口代碼是否存在問題。因為線上流量大、場景全面，可以有效彌補人工評估測試範圍的局限性，進而降低業務快速迭代帶來的風險。流量回放的整體流程圖如下圖所示。
1.2 有贊流量回放平台介紹有贊流量回放平台是基於jvm-sandbox-repeater做的二次開發。通過AOP在運行期無侵入式（業務系統無感知）錄製接口入參/返回值。同時可以錄製子調用的入參和返回值，子調用類型包括dubbo、mybatis、redis等。因此在支持讀流量回放的基礎上，可以支持寫流量的mock回放。整體架構如下圖所示。
下面詳細介紹下有贊流量回放平台的兩個模式，讀模式（pre環境讀接口非mock回放）和寫模式（qa環境接口mock回放）。1）讀模式:
錄製階段：
獲取dubbo入口請求、返回值；
mybatis/hbase增強點判斷是否有寫入操作，給寫操作標誌位賦值。
回放階段：
獲取所有的黑名單接口、白名單接口，以及當前時間生效的replay任務，黑名單接口不會在預發非mock回放，避免髒數據；
根據流量中寫操作標誌位自動補充黑名單，避免人工配置黑名單造成的遺漏；
泛化調用預發環境，判斷泛化調用返回值是否和錄製一致（支持根據配置自動忽略某些字段）；
不一致，請求兩次生產環境，判斷出噪音路徑；
再次比對預發泛化調用返回值和最新生產環境返回值；
回放失敗落用例，任務結果記錄；
回放成功，根據任務配置中是否有蓄流配置，如有且符合落用例規則，那麼把流量落成用例；這部分用例後面可以根據實際需要隨時在預發回放。
2）寫模式
錄製階段:
在請求dubbo入口生成唯一id（traceid），通過唯一id關聯這次請求所有的子調用；
每個增強點方法執行之前，記錄請求，方法執行之後，記錄返回值；
dubbo執行結束，通過唯一id獲取此次調用詳情，異步序列化後發送nsq。
回放階段:
dubbo泛化調用，把錄製階段的traceid放入dubbo的attachment；
在dubbo執行入口，根據dubbo的attachment中traceid獲取此次調用涉及到的所有子調用；
在每個子調用執行之前，根據子調用的類型、類&方法、入參信息，來匹配第一步拿到的所有子調用信息，如果一致，構造返回值進行mock；如果不一致，構造異常拋出；
dubbo泛化結束，異步發送子調用mock詳情到後台；
比較泛化調用返回值和錄製階段dubbo返回值。
二、流量回放在中台營銷業務的應用2.1 中台營銷業務的特點中台營銷是有贊營銷業務的基石，涉及豐富的玩法和眾多組合場景。眾多活動的優惠價格計算，再加上複雜的疊加互斥規則，很容易造成場景遺漏，甚至造成資損。且伴隨公司業務的快速發展，為了更好的支撐業務的迭代，提供更穩定、更高效的中台能力，業務架構重構迫在眉睫。如何在項目中快速回歸現有業務邏輯，儘可能廣的覆蓋測試範圍，在計改項目中減少重複性的測試成本投入同時保證高質量的項目上線質量，流量回放成了主要的自動化回歸測試手段。2.2 我們是如何使用流量回放的首先分析業務分布以及核心場景。營銷業務主要在商家端（B端）和消費者端（C端）。B端主要涉及營銷活動的增刪改查。C端主要涉及各營銷活動在微頁面、商品詳情、購物車、下單鏈路的營銷氛圍透出和價格計算，及各活動參與抵扣記錄。其次，核心鏈路的價格計算肯定是第一優先級的。因為營銷C端鏈路有一大部分是活動氛圍透出和價格計算，涉及的是讀接口。因此第一步完成了讀接口的流量回放覆蓋，共接入應用19個，接口170+。營銷業務大覽及流量回放覆蓋情況如下圖所示。
2.3 遇到的問題及解決
從上面的分析可以看到，營銷大部分的讀接口都已經覆蓋到。但是在實際的使用過程中發現，雖然錄製回放了很多流量，但是這些流量到底覆蓋了哪些場景是無感知的。因為看不到覆蓋情況，無法完全信任流量回放，流量回放似乎是在盲測。另外一個點是受限於流量回放的採樣率問題，很多小流量的場景很難被採集到，那麼流量未覆蓋的場景就會演變成不可預知的風險。
要解決上面的問題，首先需要明確在中台營銷的各個接口中什麼是場景，哪些特性可以定義為一個場景。從大的角度來說，一個接口就可以是一個場景，比如某個營銷玩法的活動列表接口就是一個場景。從更加細緻一點的角度，每個接口核心入參或者返回值就可以是一個場景，比如商品詳情頁接口入參中的店鋪類型，返回值中的活動類型。基於此，我們將中台營銷的核心接口的主要場景定義分為如下圖幾個部分：
當然業務中接口眾多，不可能詳盡地列舉每個接口的場景定義。每個接口可以根據實際的接口定義和功能，自己定義場景。
1）場景覆蓋結果可視化
場景定義好之後，將定義好的場景錄入到流量回放平台。在平台上，每個場景用一個標籤來表示。標籤類型是接口或者參數，具體值是接口全限定名或者參數的jsonPath路徑。當本次流量回放完成後，會統計出來當前接口的場景覆蓋情況，同時標明該場景覆蓋的次數。通過場景覆蓋的次數這個指標可以在一定程度上透明化流量回放的覆蓋情況，增加對流量回放覆蓋率的信心指數。如下圖是某個應用某次流量回放的覆蓋情況。
上圖詳細展示了該應用當次回放覆蓋、未覆蓋的接口，整體覆蓋和未覆蓋的場景。更加詳細的，可以選擇某個接口，展開該接口的場景具體覆蓋詳情，如下圖所示。
2）小流量場景怎麼解決
這裡主要考慮了兩種方式解決。第一種是通過人工構造指定場景來補充，可以在預發環境構造某些特定場景的請求，將這部分流量保存下來，然後在需要的時候回放。這種方式存在的問題主要是流量的錄製和維護都需要花費時間，對測試資源的會有一定的耗費，尤其當需要補充的場景比較多時，管理成本也會比較高。因此考慮到了另外一種解決方式，通過在業務代碼中嵌入一部分邏輯，將小流量場景主動上報到流量回放平台。這種方式的缺點是對業務代碼有一定入侵，優點是不需要人工錄製和維護流量，減少人力成本，且小流量場景也能採集到較為豐富的流量。基於此，在中台營銷，主要選擇的是第二種方式來解決小流量問題。其流程圖如下圖所示。
2.4 流量回放在項目中的實際使用目前流量回放已經在多條業務線有了很好的實踐，尤其適用於技術改造項目。這裡重點介紹商品詳情頁營銷重構項目中流量回放的使用。商品詳情頁承接大量營銷活動，幾乎所有的營銷活動都會在商品詳情頁透出。同時，當商品參與多個活動的時候，需要根據疊加互斥規則計算出最優的一個或者多個活動疊加後的價格。計算邏輯複雜，導致重構測試回歸場景多，且很容易造成場景遺漏。常見的質量保障方式是接口測試+功能測試。測試數據構建、維護，測試腳本編寫、維護，功能用例編寫、執行都會非常耗時。如果按照這種方式，測試量基本以月計。因此主要使用流量回放來保障項目質量。具體測試方案如下圖所示。通過流量回放，該項目在未投入測試人力的情況下，項目上線後未產生任何故障。
三、未來展望在接入場景方面，目前因為時間、資源等原因，寫接口接入有限，但是寫接口涉及很多資損邏輯，因此後續需要梳理核心寫接口並完成接入。另外，目前只有小量核心接口使用了小流量主動上報功能，且是在接口中硬編碼實現的，其他接口想要使用這個功能的成本會比較高。後續計劃通過抽象功能，並通過標籤標記的方式實現快速接入，減少開發成本。同時，目前的小流量場景都是通過接口入參和出參來定義，比較粗糙，無法覆蓋到代碼分支、行維度的場景。後續可以結合jacoco來分析覆蓋情況，從而補充顆粒度更細的場景。在使用場景方面，因為流量回放是將線上流量採樣導入到被測環境，如果採樣率足夠大，就可以對被測環境進行性能測試。自然地利用生產環境海量真實場景，減少了性能測試數據的準備成本。在數據安全方面，流量回放需要對接口返回的敏感數據進行加密，避免敏感數據泄漏。
招募優秀的你加入👇
留言列表