哈啰業務數據場景痛點

軟硬件一體化應用場景

?

用戶從APP端、支付寶小程序、微信小程序、H5和WEB，經過一些核心服務。核心服務通過HTTP或內部的RPC接口，包含用戶增長、配置平臺、綜合平臺、用戶增長等，對應的基礎平臺包括存儲平臺、用戶平臺、算法平臺、開放平臺、大數據、地圖平臺等。物聯網目前主要對接單車、電動車、電池、電柜等。

研發測試階段遇到的痛點

?

單車這里，紅包車數據測試鏈路過長，手工構造一次數據需要0.5天以上；不同入參返回不同結果，難以構造模擬返回數據。助力車這里，超區斷電依賴地圖算法模型，測試線下路上跑來跑去模擬臨區超區耗時過長。

順風車這里，對接眾多第三方平臺，迭代回歸第三方接口，各種場景返回難以構造。支付這里，異常場景眾多，實名認證信息難以構造。

換電這里，不同項目并行開發，對方接口未開發的情況下，開發調試成本過高；無法模擬只支持某個時間段的返回結果。電動車這里，通過單測的方式Mock各種場景代碼量巨大；部分場景Mock需要研發配合改造代碼，侵入性過高，成本較大。

哈啰HiMock和傳統Mock的對比

傳統Mock在哈啰全場景先天性不足

?

傳統Mock，一是代碼改動頻繁，只要代碼變動，case相關代碼都需要改動，整體耗時較長；二是鏈路簡單，只支持簡單鏈路的Mock；三是Mock難度上，數據構造難，非本業務線同學如果沒有接口文檔，不知道如何快速Mock；四是擴展難度較大，僅支持部分軟件協議，不能擴展。

而哈啰全場景業務特性一是代碼改動難，涉及到多個業務方，研發無法及時配合驗證迭代需求改動相關代碼；二是鏈路復雜，需要支持前后多端、涉及硬件協議鏈路的Mock；三是Mock難度上，并行開發時，多個業務同個接口模擬不同的返回，構造成本較大；四是拓展程度上，需要支持軟硬件協議數據模擬。

打破傳統Mock的設計思路

?

我們為了打破傳統Mock的設計思路，從以下六點設計HiMock。一是低代碼，代碼開發量少，可以快速搭建框架；二是代碼解耦，不需要用戶改動任何代碼；三是高性能，不影響原有系統的性能指標；四是應用性，用戶可以低成本Mock；五是支持前后置場景，如簽名、回調、數據庫操作等；六是全場景，支持前后端各種協議。

Mock技術支撐全場景業務域的實踐

打破傳統互聯網的軟硬件結合的Mock業務架構

?

首先介紹服務鏈路，C端用戶主要來源于哈啰APP、支付寶小程序、微信小程序，通過HTTP網關，再進入各個業務的入口，包括單車、助力車、電動車、換電、順風車等，接下來我們協議攔截之后，再去匹配對應規則引擎里配置的規則來看是不是命中了對應的Mock，并去檢查對應的靜默開關、生效時間、生效范圍、延時、參數替換、后置條件，這些都是通過規則引擎拿到對應的數據。我們通過Mock返回的規則，一站式并支持多端。

接下來介紹產品能力，一是Mock管理，包括case創建、case列表、我的Mock；二是工具管理，主要是YAPI|Swagger接口導入；三是大盤統計，主要是調用統計的分析，包含每個業務域、調用量以及對應的Mock量、各業務線使用的分析等；四是權限管理，包括用戶權限和用戶組權限；五是攔截規則引擎，包括高并發支持、靜默支持、生效范圍和參數替換；六是一體化Mock工作臺，可以集成APP、H5、微信小程序和支付寶小程序，自動接口抓包、一鍵功能，并支持YAPI|Swagger接口導入、接口參數自動獲取、匹配規則參數自動生成；七是自動更新，底層代碼改動，自動更新最新代碼；八是環境穩定性，保證整體研發測試流程不被打斷，Mock可被追溯。

HiMock整體流程

?

我們case的來源分為三部分，包括HiMock、Fox和第三方。左邊這部分就是用戶請求，分為后端請求和前端請求。后端請求我們通過Agent攔截到對應的協議之后，根據Mock、規則引擎去匹配對應的規則，如果能匹配到，就把對應的Mock結果返回出去。

Agent的下載流程也有兩部分，一是Atlas部署的時候，會去檢查Agent是否存在，如果不存在，會自動下載到對應服務的原容器上或者ECS上面。二是添加或更新case的時候，也會去判斷Agent是否存在。前端請求iOS是針對NSURLProtocol協議進行攔截和轉發到對應的Mock規則引擎，去判斷是否命中；安卓是針對OkHttp協議攔截和轉發，其他協議也可以在這里進行兼容適配處理。

HiMock底層Agent設計

?

HiMock底層Agent設計主要分四方面，一是字節碼攔截，我們經過大量的對比分析，最終選型ByteBuddy作為字節碼攔截的底層框架，可實現低代碼，迭代敏捷迅速開發。二是攔截協議，我們實現插件化模式開發，可快速實現攔截協議的開發與配置，支持多維度協議攔截。三是殼化Agent，對外暴露一個premain的殼函數，可實現動態代碼更新相關功能。四是后置處理，復雜鏈路信息，需要在Mock 返回之后，執行一些數據庫操作、消息發送、地址回調等。

?

在HiMock底層Agent實現上，我們首先把Agent進行一個premain函數的殼化處理，再對各個協議攔截的Interceptor封裝。HTTP協議請求，我們針對CloseableHttpClient、HttpClient、OkHttpClient和RestTemplate等等Class進行攔截。RPC協議，我們有進行RpcHandler Class攔截。針對Mq，我們有Hms進行攔截。同理，其他也是攔截對應的核心請求類，再進行協議的攔截。

HiMock規則引擎設計

?

HiMock規則引擎設計思路主要分三方面，包括高并發、兼容性和多端。在方案調研上，基于不同協議，攔截規則不盡相同，但是作為攔截收口，統一轉為JSON進行參數匹配入參條件。最常用的JsonPath框架有fastJson、jackson、json-path和snack3，經過多輪壓測，我們最終選型snack3，支持的選擇器表達式更豐富，性能較優。

在方案執行上，攔截規則判斷時多條件支持，且支持多條件“與、或”組合等。目前支持的條件有equals、not equals、contains、not contains、in等。在方案落地上，攔截規則參數根據入參自動生成，參數預期值智能匹配。

HiMock平臺系統架構

?

HiMock平臺包含WEB、核心功能、數據層、Agent和Mock服務。WEB主要有DashBoard、Mock管理、權限管理、工具管理和平臺指南。核心功能主要有云容器自動部署、自動化部署、添加Mock、Mock列表、Mock日志、Mock規則、工具管理、權限管理、數據統計和用戶手冊。同時我們要適配一些攔截協議，如RPC、HTTP、TCP、MQ、MQTT、DB、ES。

數據層主要分為Mysql、Redis和ES，我們會把數據緩存到Redis里，再定期匯總到Mysql里，并把Redis里的數據進行清空，減輕緩存壓力。Mock的服務請求被對應的Agent攔截到協議請求之后，Agent訪問Mock服務設置的規則數據，拿到規則數據判斷請求是否被匹配到Mock規則。

HiMock落地使用場景

?

HiMock落地使用場景有依賴測試、自動化測試、性能壓測和并行開發等。依賴測試支持 case Mock生效日期和端到端的Mock生效范圍，主要是為了避免某一個case過大影響實際的測試范圍。自動化測試支持自動開啟、關閉對應的Mock開關。

性能壓測支持一鍵靜默，只要把靜默開關打開，所有的調用Mock case都不會生效，這時所有的性能壓測都會走原始的調用請求。并行開發支持生效范圍界定和Mock參數動態調整等。當然我們在測試過程中不要過度依賴基于Mock的測試結果，Mock只是一種提效手段，基于Mock的測試無論如何多么的充分，都不能保證不會遺漏。一個完整的測試策略，一定是由基于Mock的測試和基于非Mock的測試共同組成，二者相輔相成，缺一不可。

HiMock平臺能力介紹

?

這里介紹RPC接口的新增，在Mock標題里可以根據自己的場景設置標題，如助力車賠付，應用名稱、iface、method是要攔截的對應服務以及它對應的method。在右邊，我們也可以看到對應這兩個應用名稱，后面可以查看Atlas的配置,如果選擇在ClientAppId進行Mock攔截，需要把對應服務的自定義啟動參數中Agent啟動命令配置上去。

Mock環境里FAT和UAT都可以選擇，同一個case多個環境同時生效。生效時間默認是永久生效的，如果填寫生效范圍，只會針對生效時間范圍內走Mock邏輯；下面也有對應的是否開啟的開關。添加規則這里，我們支持從用戶請求日志里自動獲取對應的請求有哪些參數，減少用戶手動填入的復雜度。最下面的請求響應、執行日志和變更記錄，主要用來查看預執行的時候對應這個規則能否匹配到，哪一步攔截失敗，進而去調整Mock匹配規則。

針對復雜場景，我們支持后置模擬回調，包括HMS、HTTP等。

?

這里是測試請求，測試請求自動填入，也可以根據實際情況進行動態調整，Mock結果即時校驗。執行日志做到了執行過程的匹配，結果校驗可以實時看到匹配規則是否正常匹配，以及匹配的返回結果是否是想要的。

?

接下來介紹前端一鍵Mock的功能，左邊是我們的APP端，右邊通過掃碼APP-QrCode就可以看到左邊菜單欄有自動抓包的鏈路信息，點擊后會有接口對應的Request和Response。這里我們可以快速Mock對應接口的返回，或者是Mock異常的返回。

HiMock平臺效果價值回收能力分析

?

我們主要從六部分進行HiMock效果價值回收能力分析，包括接口調用統計分析、Mock業務線覆蓋統計分析、Mock占比分析、業務線Mock運營分析、Mock case統計分析和Mock次數、平均耗時統計分析。

?

這里是HiMock平臺整體的調用統計分析，可以看到具體某個業務線、當天調用量和對應的Mock次數。左邊是調用統計的趨勢圖，右邊是業務線Mock次數的占比。

后續規劃&探討

?

Mock平臺我們分三步走，第一步是測試小哥哥小姐姐通過手工Mock的方式人肉抓包Mock返回，后端Mock代碼改動較大，費時費事費人，重復勞動嚴重。第二步是HiMock一體化Mock平臺，可以支持全場景、多端Mock。前端自動抓包一鍵Mock，規則匹配參數自動生成，日志請求自動填充，極大提升了我們Mock case的整體效率。第三步是HiMock智能化，我們后續也會支持適配中間件DB、MQ類型協議的Mock，與仿真實驗室、精準自動化的進一步結合，打造研發、精準測試、高效運營的一體化Mock，并打造智能出行Mock平臺，能夠self-learning自適應，以及更多場景的Mock支持。

審核編輯：劉清