哈啰業(yè)務(wù)數(shù)據(jù)場(chǎng)景痛點(diǎn)

軟硬件一體化應(yīng)用場(chǎng)景

?

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

研發(fā)測(cè)試階段遇到的痛點(diǎn)

?

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

順風(fēng)車這里，對(duì)接眾多第三方平臺(tái)，迭代回歸第三方接口，各種場(chǎng)景返回難以構(gòu)造。支付這里，異常場(chǎng)景眾多，實(shí)名認(rèn)證信息難以構(gòu)造。

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

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

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

?

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

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

打破傳統(tǒng)Mock的設(shè)計(jì)思路

?

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

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

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

?

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

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

HiMock整體流程

?

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

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

HiMock底層Agent設(shè)計(jì)

?

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

?

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

HiMock規(guī)則引擎設(shè)計(jì)

?

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

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

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

?

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

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

HiMock落地使用場(chǎng)景

?

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

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

HiMock平臺(tái)能力介紹

?

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

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

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

?

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

?

接下來(lái)介紹前端一鍵Mock的功能，左邊是我們的APP端，右邊通過(guò)掃碼APP-QrCode就可以看到左邊菜單欄有自動(dòng)抓包的鏈路信息，點(diǎn)擊后會(huì)有接口對(duì)應(yīng)的Request和Response。這里我們可以快速M(fèi)ock對(duì)應(yīng)接口的返回，或者是Mock異常的返回。

HiMock平臺(tái)效果價(jià)值回收能力分析

?

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

?

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

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

?

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

審核編輯：劉清