閒魚如何保障交易鏈路質量_閒魚技術

作者：閒魚技術——荻竹

背景

閒魚作為一款垂直交易社群APP，擁有複雜多樣的業務場景：涉及c2c、回收寄賣、租房租賃、見面交易、驗貨擔保等，複雜多變的交易模式。比如驗貨流程：

•涉及39個狀態機節點•橫跨10+應用系統•涉及6個業務部門的合作•涉及介面幾十個

需要保證每個介面、每個場景切實可行，稍微有一點點問題，就會涉及到人民幣的味道，實際工作中，我們遇到各種各樣的問題，比較棘手的問題如下：

問題

業務先贏的快速迭代模式下，全靠人工主力進行測試驗證，測完新功能，還得迴歸老功能，一個小需求也須要好幾個人日，版本PTM也要回歸好幾遍，ROI並不樂觀，以下2個問題比較突出：

1.交易業務強依賴中臺，溝通成本高，跨團隊協作難，迭代效率低，測試環境下如何自洽？2.複雜多樣交易模式下，如何支撐需求穩步迭代上線以及日常回歸驗證？

測試策略-自動化

閒魚質量基建正在快馬加鞭進行中，針對閒魚多樣的交易模式，全靠人力是不可行的，累不說，改動、風險漏評估也時有發生。對此，我們根據介面->鏈路的策略，探索對比了幾個不同的方案，在保證每個介面OK的基礎上，保障全鏈路。
交易自動化策略.png

介面層

對於每一個大型應用程式來說，介面數量會不斷增加，程式碼變更頻率越來越大、系統不定期重構，這個介面的質量怎麼來保障？傳統編寫指令碼來進行的方式，投入的人力、時間成本過大，在實際的測試過程中我們探索了一些介面測試的新想法。目前業界公認的有效方式是基於引流回放的自動化測試，實現方案業內眾說紛紜各有其詞，但萬變不離其中，引用下面這段總結，簡單明瞭

一種是黑盒測試思路，它在線上介面請求時採集線上流量（主要是請求引數和結果），然後使用和線上環境相同的環境（資料庫共用等）下用採集到的流量重新觸發請求，然後斷言被請求的返回值是不是和錄製時的一致。這種方法比較適合對Get型別的介面進行測試，而對於寫操作的請求容易造成資料汙染，再加上所採集流量的資料狀態（資料時效性）、環境依賴性（各種中介軟體、介面內部請求的RPC呼叫）等因素，所以這種測試方式具有一些侷限性，不能滿足實際測試場景中複雜的需求。
另一種思路相對白盒，主要是通過智慧化的Mock手段，流量採集時採集程式碼執行過程中所依賴的外部中介軟體或者RPC呼叫的返回結果，當流量回放時，能夠Mock本機程式對外的依賴中有可能產生變化的內容，使測試更關注本地介面的程式碼邏輯。

阿里集團內部，基於流量回放的思想，主要實現了2種不同的流量錄製回放方案，一種是基於doom的天啟/暴雪，一種是基於JVM-Sandbox的鳳凰，兩種實現都借力於JVM AOP。

•

天啟/暴雪

 天啟/暴雪，其底層採用的是doom進行流量錄製，其原理如下<br />![doom框架圖.png](https://gw.alicdn.com/imgextra/i4/O1CN01WOLEs31JGV9Tv4bwj_!!6000000001001-2-tps-563-489.png)<br />doom原理圖<br />主要流程是：

1.通過Java agent掛在JVM中的client以ASM的AOP方式採集主呼叫（採集或回放時的入口方法）的入參、返回值、子呼叫（應用執行過程中的一次方法呼叫，採集機器會採集該方法的入參和返回值用於回放時執行到該方法進行mock）的入參和返回值，然後將採集到的資料上傳至server （離線模式）；2.回放時，client收到介面回放請求後，會執行該介面的本地邏輯，對於子呼叫則用採集的入參和結果進行mock；3.將採集的流量和回放的結果資料進行對比。

doom方式，業務應用系統需要引入Jar包，修改啟動類，修改JVM掛載agent，有部分的業務侵入性。

  - 鳳凰

    鳳凰，也是採用JVM AOP實現的流量錄製方案，理念和doom差不多，鳳凰整體架構底層基於JVM-Sandbox（阿里開源的一款 JVM 平臺非侵入式執行期 AOP 解決方案，通過位元組碼增強實現方法級別的AOP功能）輸出模組原子能力。錄製時，記錄了發生呼叫的方法，入參、返回值和呼叫發生的順序，以鏈式資料結構儲存，回放時進行介面邏輯執行和子呼叫mock。<br />![鳳凰錄製回放.png](https://gw.alicdn.com/imgextra/i2/O1CN01m49rqS1rsh7EMIakW_!!6000000005687-2-tps-442-331.png)<br />鳳凰錄製回放<br />鳳凰無需程式碼侵入修改，不需要修改應用啟動引數，相對來說，對業務程式碼影響小，但是有應用結構要求。考慮成本和風險，以及我們的應用結構，閒魚採用基於Sandbox的鳳凰流量錄製回放進行保障，變更上線流程卡點。<br />研發過程中，也會遇到各種各樣的流量回放問題，比如用例過期，需要人工清楚重新錄製。我們現在是採用定時任務自動清除重新錄製的方式解決。<br />下面是我們的一個場景例子：<br />![image.png](https://gw.alicdn.com/imgextra/i3/O1CN01bR7Yqe1qfaA29uZCx_!!6000000005523-2-tps-1318-418.png)<br /><br />

鏈路層

在基於流量錄製、回放比對的介面測試過程中，我們發現這種機制對於單應用的質量保障比較實用，但是對於跨應用的鏈路驗證、核心寫操作、外呼叫，以及系統重構類、方案改造等大需求就有些不足，鏈路級的解決解決方案接踵而至。

•Thub + 微服務

測試環境下，對於全鏈路上下游的強依賴，措施之一是開發測試服務化能力，建立自洽能力，測試環境下解藕對於外界諸如交易中臺、菜鳥裹裹的依賴，測試環境能進行全鏈路閉環。
落地首要任務是梳理業務全鏈路節點：

  - 主幹鏈路上的每一個MTOP介面，以及介面的上下游依賴
  - 內部應用、中臺應用、外部商家的依賴
  - 資料流以及TDDL梳理

業務梳理完整，進行測試服務化介面開發。下面是我們擷取的一部分鏈路case：

同時，諸如測試環境由於依賴方測試環境不穩定block測試的情況，我們提供測試服務化介面進行封裝，暴露成下單、驗貨等服務化能力內置於閒魚質量平臺，用於開發、測試在研發過程中使用。

•天算平臺

天算平臺，利用影子庫，全鏈路壓測的模式，線上業務資料和測試資料隔離，測試庫copy線上庫一部分資料。主要實現的方式是將線上的場景進行固化模擬，全鏈路執行，並且在執行的過程中進行所有資料變更的比對，使用者可以選擇任何程式碼版本的基線和變更版本進行對比。
大致流程

天算能力基本能滿足閒魚的交易鏈路，閒魚建立了主鏈路相關影子庫，影子鏈路正在除錯中，用於交易服務端的全鏈路巡檢。同時，影子鏈路有諸如業務變更導致影子資料過期的問題，這個方案則主要是用於業務比較穩定的業務，新業務或者不斷迭代更新的業務並未all in這個方案。

總結

綜上，目前閒魚交易，介面層用基於jvm-sandbox的流量錄製方案, 日常巡檢利用影子鏈路，研發過程自測、鏈路自動化用業務編排服務化能力。

doom

jvm-sandbox

Thub+微服務

影子鏈路

Release

否

是（github已開源）

否

程式碼侵入

是

否

應用要求

否

是

否

穩定性

一般

全鏈路測試

否

是

展望

在基建完善的基礎上，我們將繼續探索flutter以及服務端的全端智慧化方向的測試解決方案，希望讓更多技術小二從重複勞動中釋放出來，從治、防、控，三層質量網，保障閒魚交易，讓使用者在閒魚放心的賣賣賣、買買買。期待和大家一起交流業內的不同測試方案！同時感謝doom、sandbox、鳳凰、天啟、暴雪、全鏈路壓測、Thub等團隊提供的能力支援！