哈啰業(yè)務數(shù)據(jù)場景痛點

軟硬件一體化應用場景

?

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

研發(fā)測試階段遇到的痛點

?

單車這里，紅包車數(shù)據(jù)測試鏈路過長，手工構(gòu)造一次數(shù)據(jù)需要0.5天以上；不同入?yún)⒎祷夭煌Y(jié)果，難以構(gòu)造模擬返回數(shù)據(jù)。助力車這里，超區(qū)斷電依賴地圖算法模型，測試線下路上跑來跑去模擬臨區(qū)超區(qū)耗時過長。

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

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

哈啰HiMock和傳統(tǒng)Mock的對比

傳統(tǒng)Mock在哈啰全場景先天性不足

?

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

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

打破傳統(tǒng)Mock的設計思路

?

我們?yōu)榱舜蚱苽鹘y(tǒng)Mock的設計思路，從以下六點設計HiMock。一是低代碼，代碼開發(fā)量少，可以快速搭建框架；二是代碼解耦，不需要用戶改動任何代碼；三是高性能，不影響原有系統(tǒng)的性能指標；四是應用性，用戶可以低成本Mock；五是支持前后置場景，如簽名、回調(diào)、數(shù)據(jù)庫操作等；六是全場景，支持前后端各種協(xié)議。

Mock技術(shù)支撐全場景業(yè)務域的實踐

打破傳統(tǒng)互聯(lián)網(wǎng)的軟硬件結(jié)合的Mock業(yè)務架構(gòu)

?

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

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

HiMock整體流程

?

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

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

HiMock底層Agent設計

?

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

?

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

HiMock規(guī)則引擎設計

?

HiMock規(guī)則引擎設計思路主要分三方面，包括高并發(fā)、兼容性和多端。在方案調(diào)研上，基于不同協(xié)議，攔截規(guī)則不盡相同，但是作為攔截收口，統(tǒng)一轉(zhuǎn)為JSON進行參數(shù)匹配入?yún)l件。最常用的JsonPath框架有fastJson、jackson、json-path和snack3，經(jīng)過多輪壓測，我們最終選型snack3，支持的選擇器表達式更豐富，性能較優(yōu)。

在方案執(zhí)行上，攔截規(guī)則判斷時多條件支持，且支持多條件“與、或”組合等。目前支持的條件有equals、not equals、contains、not contains、in等。在方案落地上，攔截規(guī)則參數(shù)根據(jù)入?yún)⒆詣由?，參?shù)預期值智能匹配。

HiMock平臺系統(tǒng)架構(gòu)

?

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

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

HiMock落地使用場景

?

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

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

HiMock平臺能力介紹

?

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

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

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

?

這里是測試請求，測試請求自動填入，也可以根據(jù)實際情況進行動態(tài)調(diào)整，Mock結(jié)果即時校驗。執(zhí)行日志做到了執(zhí)行過程的匹配，結(jié)果校驗可以實時看到匹配規(guī)則是否正常匹配，以及匹配的返回結(jié)果是否是想要的。

?

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

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

?

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

?

這里是HiMock平臺整體的調(diào)用統(tǒng)計分析，可以看到具體某個業(yè)務線、當天調(diào)用量和對應的Mock次數(shù)。左邊是調(diào)用統(tǒng)計的趨勢圖，右邊是業(yè)務線Mock次數(shù)的占比。

后續(xù)規(guī)劃&探討

?

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

審核編輯：劉清