vivo霍金實(shí)驗(yàn)平臺(tái)設(shè)計(jì)與實(shí)踐-平臺(tái)產(chǎn)品系列02
一、前言
互聯(lián)網(wǎng)企業(yè)經(jīng)歷過(guò)野蠻生長(zhǎng)的開拓紅利期之后，逐漸越發(fā)重視產(chǎn)品發(fā)展的科學(xué)化、精細(xì)化，從粗放型向集約型轉(zhuǎn)換。在美國(guó)，增長(zhǎng)黑客等數(shù)據(jù)驅(qū)動(dòng)增長(zhǎng)的方法論，正在幫助如Google、Microsoft、Facebook等全球科技巨頭實(shí)現(xiàn)持續(xù)的業(yè)務(wù)增長(zhǎng)；在國(guó)內(nèi)，數(shù)據(jù)精細(xì)運(yùn)營(yíng)、AB實(shí)驗(yàn)分析來(lái)驅(qū)動(dòng)業(yè)務(wù)有效增長(zhǎng)也逐漸成為共識(shí)，成為核心手段。其中，A/B測(cè)試平臺(tái)作為典型代表，自然成為了國(guó)內(nèi)主流公司中必不可少的核心工具，有效的提升流量的轉(zhuǎn)化效率和產(chǎn)研的迭代效率。
在過(guò)去幾年，vivo互聯(lián)網(wǎng)持續(xù)重視科學(xué)的實(shí)驗(yàn)決策，這意味著所有對(duì)用戶的改動(dòng)的發(fā)布，都要決策者以相應(yīng)的實(shí)驗(yàn)結(jié)論作為依據(jù)。比如，修改頂部廣告的背景色、測(cè)試一個(gè)新的廣告點(diǎn)擊率 (CTR) 預(yù)測(cè)算法，都需要通過(guò)實(shí)驗(yàn)的方式進(jìn)行，那么一個(gè)強(qiáng)大的A/B實(shí)驗(yàn)平臺(tái)就非常重要了。vivo霍金實(shí)驗(yàn)平臺(tái)（以下簡(jiǎn)稱霍金）已經(jīng)從一個(gè)單一系統(tǒng)成長(zhǎng)為了解決A/B實(shí)驗(yàn)相關(guān)問(wèn)題的公司級(jí)一站式平臺(tái)，助力互聯(lián)網(wǎng)核心業(yè)務(wù)的快速、準(zhǔn)確實(shí)驗(yàn)，高效推動(dòng)業(yè)務(wù)增長(zhǎng)。
二、項(xiàng)目介紹
2.1 A/B實(shí)驗(yàn)
在互聯(lián)網(wǎng)領(lǐng)域，A/B實(shí)驗(yàn)通常指一種迭代方法，這種方法可以指導(dǎo)如何改進(jìn)現(xiàn)有產(chǎn)品或者服務(wù)。以提升某個(gè)產(chǎn)品下單轉(zhuǎn)化率為例，AB實(shí)驗(yàn)過(guò)程中，我們?cè)O(shè)計(jì)了新的下單頁(yè)面，和原頁(yè)面相比，頁(yè)面布局和文案做了調(diào)整。我們將用戶流量隨機(jī)分成A/B兩組（分別對(duì)應(yīng)新舊頁(yè)面），50%用戶看到A版本頁(yè)面，50%用戶看到B版本頁(yè)面，經(jīng)過(guò)一段時(shí)間的觀察和統(tǒng)計(jì)，發(fā)現(xiàn)A版本用戶下單轉(zhuǎn)化率為70%，高于B版本的50%。那么我們得出A版本效果好，進(jìn)而將新頁(yè)面推送并展示給所有用戶。
以上就是一個(gè)利用AB測(cè)試迭代產(chǎn)品功能的具體應(yīng)用，我們將A/B實(shí)驗(yàn)的完整生命周期分為三個(gè)階段：
- 實(shí)驗(yàn)前，明確改進(jìn)目標(biāo)，定義實(shí)驗(yàn)指標(biāo)，完成相關(guān)功能開發(fā)和上線；
- 實(shí)驗(yàn)中，制定每個(gè)實(shí)驗(yàn)組流量比例，按照分流比例開放線上流量進(jìn)行測(cè)試；
- 實(shí)驗(yàn)后，實(shí)驗(yàn)效果評(píng)估并決策。
2.2 分層實(shí)驗(yàn)?zāi)Ｐ?/span>
霍金的分層實(shí)驗(yàn)?zāi)Ｐ蛥⒖脊雀璋l(fā)布的重疊實(shí)驗(yàn)框架論文：《??Overlapping Experiment Infrastructure: More, Better, Faster Experimentation??》完成設(shè)計(jì)。
2.3 平臺(tái)發(fā)展及在vivo業(yè)務(wù)中的應(yīng)用和價(jià)值
霍金啟動(dòng)于2019年，歷經(jīng)三年多的發(fā)展，目前日均實(shí)驗(yàn)數(shù)量達(dá)到900多個(gè)，高峰期1000+。
- 支撐vivo國(guó)內(nèi)與海外業(yè)務(wù)，服務(wù)公司20多個(gè)部門。
- 通過(guò)標(biāo)準(zhǔn)化的實(shí)驗(yàn)流程降低了實(shí)驗(yàn)門檻，提升實(shí)驗(yàn)效率。
- 通過(guò)自動(dòng)化的數(shù)據(jù)分析工具輔助業(yè)務(wù)快速?zèng)Q策，提升產(chǎn)品迭代速度，有效助力業(yè)務(wù)發(fā)展。
- 平臺(tái)能力復(fù)用，避免不同組織重復(fù)建設(shè)的情況，有效的提升了生產(chǎn)效率。
三、霍金系統(tǒng)架構(gòu)
3.1【實(shí)驗(yàn)人員】
實(shí)驗(yàn)人員包含多個(gè)角色，供業(yè)務(wù)方在霍金管理后臺(tái)進(jìn)行實(shí)驗(yàn)、指標(biāo)的管理和實(shí)驗(yàn)效果的分析。
3.2【實(shí)驗(yàn)門戶】
包括兩部分功能：實(shí)驗(yàn)管理和實(shí)驗(yàn)效果分析。
3.2.1 實(shí)驗(yàn)管理
平臺(tái)提供可視化頁(yè)面供業(yè)務(wù)方進(jìn)行實(shí)驗(yàn)配置、分流策略的選擇、流量的分配以及白名單的管理。
3.2.2 實(shí)驗(yàn)效果分析
包括如下4個(gè)核心能力：
1. 指標(biāo)管理
不同實(shí)驗(yàn)關(guān)注指標(biāo)不同，為了實(shí)現(xiàn)效果評(píng)估自動(dòng)化，平臺(tái)提供了指標(biāo)配置和集成能力。
【必看指標(biāo)】：通常為業(yè)務(wù)核心指標(biāo)，每個(gè)實(shí)驗(yàn)都需要保障不能有明顯負(fù)向的指標(biāo)，平臺(tái)通過(guò)集成大數(shù)據(jù)指標(biāo)管理系統(tǒng)，這部分指標(biāo)結(jié)果直接復(fù)用指標(biāo)管理系統(tǒng)的數(shù)據(jù)服務(wù)。
【個(gè)性化指標(biāo)】：通常為實(shí)驗(yàn)中臨時(shí)分析的指標(biāo)，如某banner樣式實(shí)驗(yàn)，觀察的指定banner的曝光點(diǎn)擊率。平臺(tái)提供了自定義指標(biāo)配置的能力，并通過(guò)大數(shù)據(jù)計(jì)算平臺(tái)自動(dòng)生成計(jì)算任務(wù)，實(shí)現(xiàn)自定義指標(biāo)自動(dòng)化產(chǎn)出數(shù)據(jù)的能力。
2. 對(duì)比分析和顯著性結(jié)論
效果評(píng)估的可視化展示，平臺(tái)沉淀了對(duì)比分析和顯著性結(jié)論等可視化組件。非常直觀的告知實(shí)驗(yàn)者，每個(gè)實(shí)驗(yàn)方案相比對(duì)照方案整體提升幅度以及每日的漲跌幅。同時(shí)給出指標(biāo)的置信區(qū)間和顯著性結(jié)論。
3. AA分析
平臺(tái)提供的AA分析，目的是幫助實(shí)驗(yàn)者驗(yàn)證實(shí)際進(jìn)入實(shí)驗(yàn)的不同方案的人群，實(shí)驗(yàn)前在業(yè)務(wù)核心指標(biāo)上是否存在顯著差異，輔助實(shí)驗(yàn)者判斷實(shí)驗(yàn)結(jié)論是否可靠。
4.分流實(shí)時(shí)監(jiān)控
可以直觀的看到實(shí)時(shí)分流的效果，針對(duì)流量異?？梢约皶r(shí)人工干預(yù)和解決。
3.3 【實(shí)驗(yàn)分流服務(wù)】
1. 多端接入服務(wù)
平臺(tái)根據(jù)業(yè)務(wù)的不同訴求提供豐富的接入能力，如針對(duì)安卓客戶端的Android SDK、服務(wù)端的JAVA SDK、基于NGINX進(jìn)行分流的H5實(shí)驗(yàn)服務(wù)、dubbo/http服務(wù)，C++ SDK待建設(shè)。
2.實(shí)驗(yàn)分流的方式
平臺(tái)提供了穩(wěn)定高效的在線實(shí)時(shí)分流服務(wù)。
- 【隨機(jī)分流】：根據(jù)用戶標(biāo)識(shí)符基于哈希算法對(duì)人群進(jìn)行隨機(jī)分組并分流
- 【指定人群分流】：實(shí)驗(yàn)前圈定一撥人群并打上標(biāo)簽進(jìn)行分流
- 【協(xié)變量均勻分流】：在基于哈希算法對(duì)人群隨機(jī)分組的時(shí)候，雖然分組的人群數(shù)量等比例劃分，但是分組的人群分布的指標(biāo)存在不均勻的情況，導(dǎo)致實(shí)驗(yàn)效果達(dá)不到預(yù)期。為了解決這個(gè)痛點(diǎn)，平臺(tái)推出了協(xié)變量平衡算法，
該算法能夠保證人群在進(jìn)行分組樣本量均勻的同時(shí)，人群上指標(biāo)分布也是均勻的。
詳見本文：4. vivo霍金實(shí)驗(yàn)平臺(tái)實(shí)踐→4.1 協(xié)變量平衡算法 的詳細(xì)介紹。
- 【基于openresty web服務(wù)分流】：針對(duì)服務(wù)端非JAVA語(yǔ)言，對(duì)性能有著嚴(yán)苛要求的業(yè)務(wù)方，我們?cè)贜GINX基于OpenResty采用lua腳本實(shí)現(xiàn)了一套實(shí)驗(yàn)分流功能，以http接口提供服務(wù)，平均響應(yīng)時(shí)間小于1ms，p9999<20ms。
3.4 【分流數(shù)據(jù)處理服務(wù)】
采用公司統(tǒng)一的數(shù)據(jù)采集組件進(jìn)行分流數(shù)據(jù)的采集、加工，并最終存儲(chǔ)至HDFS。
3.5【指標(biāo)計(jì)算服務(wù)】
獨(dú)立的服務(wù)用于高效計(jì)算指標(biāo)結(jié)果，同時(shí)配備了指標(biāo)計(jì)算失敗重試和監(jiān)控告警機(jī)制，有效的保證了指標(biāo)計(jì)算成功率。
3.6【數(shù)據(jù)存儲(chǔ)】
主要是利用MySQL來(lái)進(jìn)行業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)，同時(shí)采用Ehcahe進(jìn)行實(shí)驗(yàn)配置的主要緩存，Redis作為輔助緩存，最后實(shí)驗(yàn)分流的數(shù)據(jù)經(jīng)過(guò)加工處理后保存到HDSF中，供后續(xù)的實(shí)驗(yàn)數(shù)據(jù)分析使用。
四、霍金實(shí)踐
上面介紹了霍金的發(fā)展情況以及整體的系統(tǒng)架構(gòu)，接下來(lái)介紹下在平臺(tái)發(fā)展過(guò)程中遇到的問(wèn)題以及對(duì)應(yīng)的解決方案。
4.1 協(xié)變量平衡算法
4.1.1 遇到的問(wèn)題
業(yè)務(wù)方在進(jìn)行實(shí)驗(yàn)對(duì)象分組的時(shí)候，最常用的做法是根據(jù)實(shí)驗(yàn)對(duì)象的某個(gè)屬性進(jìn)行哈希后對(duì)100取模，根據(jù)結(jié)果分到不同組。雖然hash算法分流可以做到尾號(hào)號(hào)段分布均勻，但是分完組后，可能存在不同組的實(shí)驗(yàn)對(duì)象在某些指標(biāo)特征上分布不勻均，導(dǎo)致實(shí)驗(yàn)效果評(píng)估不準(zhǔn)確。如下圖所示（圖中四個(gè)不同顏色代表不同的人群以及對(duì)應(yīng)的指標(biāo)類型）：
有沒(méi)有一種方式能夠?qū)崿F(xiàn)對(duì)人群進(jìn)行均勻分組的同時(shí)，保證人群對(duì)應(yīng)的指標(biāo)分布也是均勻的呢，如下圖所示：
4.1.2 解決方案
1. 協(xié)變量平衡算法
該算法能夠保證對(duì)人群進(jìn)行均勻分組的同時(shí)，人群對(duì)應(yīng)的指標(biāo)分布也是均勻的。整體由三部分組成，示意圖如下：
（1）離線分層抽樣
需要經(jīng)歷如下3個(gè)步驟：
- 和業(yè)務(wù)方確定核心指標(biāo)
- 采用等比例分層+Kmeans聚類模型完成指標(biāo)對(duì)應(yīng)的用戶的分層抽樣
- 將分層抽樣好的數(shù)據(jù)寫入hive庫(kù)相關(guān)表中
這里介紹下等比例分層抽樣
等比例分層抽樣：
第i層應(yīng)抽取的樣本數(shù)量；第i層的總體樣本數(shù)量；N 全體可用的流量總數(shù)；n 本次實(shí)驗(yàn)設(shè)定的流量樣本數(shù)量
假設(shè)N為3kw，n為50w。按照以下維度進(jìn)行分類：
共有9種組合，確定每種組合別在總量中的占比（總數(shù)N=3kw，通過(guò)在全體可用流量中篩取特定人群）：
通過(guò)公式計(jì)算得到每層的樣本數(shù)量；對(duì)應(yīng)分類的樣本數(shù)量（總樣本量60w）：
至此完成了整個(gè)離線分層抽樣的工作，接下來(lái)介紹下實(shí)時(shí)均勻分組。
（2）實(shí)時(shí)均勻分組
需要經(jīng)歷如下4個(gè)步驟：
- 數(shù)據(jù)同步
通過(guò)配置的定時(shí)任務(wù)將準(zhǔn)備好的分層抽樣數(shù)據(jù)由hive庫(kù)相關(guān)表同步至redis，數(shù)據(jù)包括每天的用戶標(biāo)識(shí)符（uid，下同）到層的映射，以及每天每層所擁有的用戶占比。
- 實(shí)驗(yàn)創(chuàng)建
通過(guò)實(shí)驗(yàn)編號(hào)，實(shí)驗(yàn)組編號(hào)和每個(gè)實(shí)驗(yàn)組的樣本量創(chuàng)建實(shí)驗(yàn)。創(chuàng)建的實(shí)驗(yàn)會(huì)與當(dāng)前最新一天的用戶數(shù)據(jù)相關(guān)聯(lián)，通過(guò) 樣本量 * 層用戶占比可以確定該層每個(gè)實(shí)驗(yàn)組的樣本量。
- 實(shí)驗(yàn)分流
通過(guò)實(shí)驗(yàn)編號(hào)和用戶標(biāo)識(shí)符（uid） 先找到用戶所在的層，之后將用戶均勻的分配到該層下的實(shí)驗(yàn)組中，保證實(shí)驗(yàn)組之間在不同層上分流的用戶均勻。如下圖所示：
- 用戶數(shù)據(jù)刪除
因?yàn)槲覀儾扇〉姆桨感枰刻焱酱罅繑?shù)據(jù)，所以對(duì)于無(wú)用的用戶數(shù)據(jù)需要及時(shí)刪除，增加資源利用率。
實(shí)時(shí)均勻分組整體流程圖如下：
在做實(shí)時(shí)均勻分組的時(shí)候，面臨性能和存儲(chǔ)的壓力，為此我們分別設(shè)計(jì)了高性能分流方案和高內(nèi)存利用率用戶信息存儲(chǔ)方案設(shè)計(jì)。
高性能分流方案
我們通過(guò)不同的redis數(shù)據(jù)結(jié)構(gòu)和lua腳本完成層下桶的均勻分配
方案1
預(yù)先分配每一個(gè)桶的樣本量，每次選出當(dāng)前樣本量最多的桶
Redis結(jié)構(gòu)：HASH，field為對(duì)應(yīng)的桶編號(hào)，value為桶對(duì)應(yīng)的當(dāng)前樣本量
方案2
預(yù)先分配每一個(gè)桶的樣本量，每次選出當(dāng)前樣本量最多的桶
Redis結(jié)構(gòu)：SORTED SET，key為對(duì)應(yīng)的桶編號(hào)，score為桶對(duì)應(yīng)的當(dāng)前樣本量
方案3
通過(guò)當(dāng)前層樣本量與桶大小取模選出命中的桶
Redis結(jié)構(gòu)：HASH
方案1：在只有兩個(gè)桶時(shí)擁有最高的性能，是方案3的1.05倍，但其性能隨著桶的增多而線性減少。
方案2：擁有穩(wěn)定的性能。
方案3：擁有穩(wěn)定的性能，但性能是方案2的1.12倍，是單GET請(qǐng)求性能的58%。
綜合考慮選擇方案3。
高內(nèi)存利用率用戶信息存儲(chǔ)方案設(shè)計(jì)
uid-層的內(nèi)存消耗對(duì)比
方案1：使用redis string存儲(chǔ)。
方案2：分為10000個(gè)hash存儲(chǔ)。
方案3：分為10000個(gè)一級(jí)桶，每個(gè)一級(jí)桶下有125個(gè)二級(jí)桶。
假設(shè)uid為15位數(shù)字，層id為2位數(shù)字，考慮過(guò)期時(shí)間，不考慮cluser模式下的額外消耗，不考慮malloc內(nèi)存碎片和占用。
綜合考慮選擇方案3。
（3）離線分析驗(yàn)證
因?yàn)閰f(xié)變量算法實(shí)驗(yàn)流程比較復(fù)雜，所以我們還是采用人工取數(shù)的方式進(jìn)行實(shí)驗(yàn)效果的分析。
4.2 Java SDK
4.2.1 遇到的問(wèn)題
早期Java SDK的能力較弱，只提供了分流，需要接入方上報(bào)分流結(jié)果數(shù)據(jù)，對(duì)接入方而言改造成本較大；故當(dāng)時(shí)主要以Dubbo接口對(duì)外分流服務(wù)，在服務(wù)內(nèi)由平臺(tái)服務(wù)端統(tǒng)一進(jìn)行分流結(jié)果數(shù)據(jù)的上報(bào)。
隨著接入方越來(lái)越多，頻繁發(fā)生Dubbo線程池耗盡、或者因?yàn)榫W(wǎng)絡(luò)原因?qū)е路至魇〉那闆r發(fā)生，導(dǎo)致分流體驗(yàn)很差，影響實(shí)驗(yàn)效果分析；面對(duì)上述問(wèn)題，平臺(tái)除了不斷地做性能優(yōu)化外，還需要不停的對(duì)應(yīng)用服務(wù)器等資源做擴(kuò)容，造成一定的資源浪費(fèi)。
4.2.2 解決方案
針對(duì)上述情況，霍金開發(fā)團(tuán)隊(duì)經(jīng)過(guò)充分的技術(shù)方案研究，對(duì)Java SDK進(jìn)行了數(shù)次升級(jí)，成功解決上述問(wèn)題。目前具備了實(shí)驗(yàn)分流、分流結(jié)果的上報(bào)、實(shí)驗(yàn)配置實(shí)時(shí)&增量更新、SDK自監(jiān)控等核心功能，極大的提升了分流的穩(wěn)定性和成功率。
4.2.3 SDK6大核心能力
1. 分流結(jié)果上報(bào)
在SDK內(nèi)部依托公司的數(shù)據(jù)采集組件進(jìn)行分流結(jié)果的上報(bào)。
2. 分流結(jié)果上報(bào)失敗的兜底方案
在進(jìn)行分流上報(bào)的時(shí)候，因?yàn)閿?shù)據(jù)鏈路無(wú)法保證數(shù)據(jù)100%的完整性，如果遇到機(jī)器宕機(jī)，業(yè)務(wù)服務(wù)異常，網(wǎng)絡(luò)異常等情況，實(shí)驗(yàn)分流數(shù)據(jù)上報(bào)失敗，直接影響實(shí)驗(yàn)效果分析。
如何保證在任何情況下實(shí)驗(yàn)分流數(shù)據(jù)100%不丟失，為此霍金實(shí)驗(yàn)平臺(tái)設(shè)計(jì)了一套分流數(shù)據(jù)落磁盤的方案，作為異常場(chǎng)景的兜底措施，從而100%保證了數(shù)據(jù)的完整性，設(shè)計(jì)圖如下：
3. 實(shí)驗(yàn)配置實(shí)時(shí)&增量更新
在通過(guò)定時(shí)任務(wù)拉取實(shí)驗(yàn)配置至業(yè)務(wù)方本地緩存的方式外，還提供了實(shí)時(shí)和增量更新，適用于對(duì)實(shí)驗(yàn)配置變更時(shí)效性要求高的業(yè)務(wù)，可以通過(guò)開關(guān)控制，動(dòng)態(tài)生效，默認(rèn)采用實(shí)時(shí)增量更新 + 定期全量更新，方便業(yè)務(wù)方靈活使用。下面是配置實(shí)時(shí)與增量更新的流程圖：
在實(shí)時(shí)更新發(fā)生失敗的情況下，我們?cè)O(shè)計(jì)了失敗退避策略：采用指數(shù)級(jí)失敗退避策略, 默認(rèn)長(zhǎng)輪詢的間隔為1s，每次失敗間隔增加2倍, 最大為60, 所以增長(zhǎng)序列為1, 2, 4, 8, 16, 32, 60；每次成功將間隔置為1。
此外我們做了數(shù)據(jù)最終一致性的保證，保證SDK拉取配置時(shí)最終可以拉取到最新的配置，且不會(huì)出現(xiàn)配置回退：
- 實(shí)驗(yàn)信息和模塊信息緩存的刷新是線性的。
- 同一次變更的實(shí)驗(yàn)信息緩存的刷新在模塊信息緩存刷新之前（發(fā)送緩存刷新消息時(shí)保證實(shí)驗(yàn)緩存刷新消息在模塊緩存刷新消息之前）。
- 模塊信息緩存的刷新時(shí)不會(huì)出現(xiàn)版本號(hào)跳躍問(wèn)題（緩存方法入?yún)⒓由习姹咎?hào)，刷新緩存時(shí)將數(shù)據(jù)庫(kù)的版本號(hào)與傳入的版本號(hào)對(duì)比，如果版本號(hào)不一致則打印日志并使用傳入的版本號(hào)作為此次緩存刷新的版本號(hào)）。
- SDK拉取配置并更新本地配置時(shí)，只更新拉取配置版本號(hào)大于等于本地配置版本號(hào)的配置
4. 多級(jí)配置管理
SDK 支持多級(jí)配置管理，優(yōu)先級(jí)依次為：方法入?yún)⒌呐渲?原有) > 業(yè)務(wù)方配置中心灰度配置 > 業(yè)務(wù)方配置中心配置 > 遠(yuǎn)程默認(rèn)配置 > 本地默認(rèn)配置；業(yè)務(wù)方配置中心灰度配置是指在配置中心通過(guò)配置指定機(jī)器ip進(jìn)行功能灰度。
5. 分流策略兜底
采用SDK痛點(diǎn)之一是新增功能后需要業(yè)務(wù)方隨之升級(jí)，否則新功能無(wú)法使用，進(jìn)而影響業(yè)務(wù)。為此霍金設(shè)計(jì)了一套兜底方案，在SDK中探測(cè)到新增的策略不存在時(shí)，通過(guò)dubbo泛化調(diào)用的方式訪問(wèn)霍金服務(wù)器，保證分流功能正常；有效的保證業(yè)務(wù)方有充足的時(shí)間升級(jí)到最新版本，提升用戶體驗(yàn)。
6. SDK監(jiān)控告警
采用SDK的另一個(gè)痛點(diǎn)是SDK集成在業(yè)務(wù)方服務(wù)端的進(jìn)程中，所打印的錯(cuò)誤信息自己看不到，依賴業(yè)務(wù)方的反饋，顯得很被動(dòng)，不能第一時(shí)間跟進(jìn)處理和解決問(wèn)題；針對(duì)這種情況，霍金實(shí)驗(yàn)平臺(tái)設(shè)計(jì)一套SDK自監(jiān)控方案。
自監(jiān)控?cái)?shù)據(jù)按照時(shí)間精度預(yù)聚合后通過(guò)埋點(diǎn)域名上報(bào)到通用監(jiān)控，自監(jiān)控支持內(nèi)銷，新加坡和印度環(huán)境。通過(guò)監(jiān)控我們可以直觀的看到每個(gè)業(yè)務(wù)、實(shí)驗(yàn)、SDK版本等維度是否存在錯(cuò)誤信息，并根據(jù)相應(yīng)維度配置告警，方便開發(fā)人員第一時(shí)間跟進(jìn)處理和解決問(wèn)題。
4.3 H5實(shí)驗(yàn)
4.3.1 遇到的問(wèn)題
業(yè)界在做H5實(shí)驗(yàn)時(shí)，通常做法是開發(fā)H5 SDK，讓業(yè)務(wù)方前端引入。
存在如下幾個(gè)問(wèn)題：
- 需要業(yè)務(wù)方前端做代碼改動(dòng)進(jìn)行適配
- 另外需要對(duì)實(shí)驗(yàn)的頁(yè)面或者元素做遮罩，因存在頁(yè)面跳轉(zhuǎn)對(duì)用戶體驗(yàn)有一定影響
- 實(shí)驗(yàn)功能發(fā)生變化時(shí)，需要業(yè)務(wù)方升級(jí)H5 SDK
- 整個(gè)H5實(shí)驗(yàn)接入周期比較長(zhǎng)，存在一定的接入門檻
4.3.2 解決方案
那么有沒(méi)有一種簡(jiǎn)單快捷的方式，只需要接入方在后臺(tái)配置完實(shí)驗(yàn)就完成整個(gè)H5實(shí)驗(yàn)的接入呢？為此霍金開發(fā)團(tuán)隊(duì)設(shè)計(jì)了一套方案順利解決了該問(wèn)題，整個(gè)H5實(shí)驗(yàn)架構(gòu)基于開源apisix搭建，業(yè)務(wù)方在霍金管理后臺(tái)創(chuàng)建實(shí)驗(yàn)時(shí)，所有基于nginx的路由配置全部自動(dòng)化通過(guò)接口下發(fā)完成（配合工單審核），無(wú)需接入方在代碼層面做任何修改，無(wú)侵入性，大大提升業(yè)務(wù)方做H5實(shí)驗(yàn)的效率。
這里解釋下幾個(gè)名詞：
- 【公共VUA】：vivo unified access。vivo統(tǒng)一接入層，可以理解是后續(xù)替換nginx的產(chǎn)品，基于開源apisix搭建。
- 【霍金VUA】：為霍金單獨(dú)搭建的VUA平臺(tái)，做H5實(shí)驗(yàn)時(shí)，公共VUA將需要做實(shí)驗(yàn)的頁(yè)面代理到霍金VUA，霍金VUA通過(guò)開發(fā)的霍金分流APISIX插件完成實(shí)驗(yàn)分流。
- 【VUA變更平臺(tái)】：基于NGINX的配置變更通過(guò)在該平臺(tái)上可視化操作后下發(fā)至VUA平臺(tái)（公共VUA/霍金VUA）。
（1）H5實(shí)驗(yàn)的整體時(shí)序圖
（2）NGINX → VUA 分流方案切換
公共VUA將需要做實(shí)驗(yàn)的頁(yè)面代理到霍金VUA，霍金VUA通過(guò)開發(fā)的霍金實(shí)驗(yàn)平臺(tái)分流APISIX插件完成實(shí)驗(yàn)分流。
多版本實(shí)驗(yàn)分流
1）H5多版本實(shí)驗(yàn)介紹
同一個(gè)url做實(shí)驗(yàn)，通過(guò)霍金分流，不同用戶訪問(wèn)到的url都是相同的，但是頁(yè)面訪問(wèn)內(nèi)容不同（因?yàn)槎喟姹緦?shí)驗(yàn)是將頁(yè)面版本資源發(fā)布到不同的機(jī)器上），然后通過(guò)霍金實(shí)驗(yàn)平臺(tái)分流訪問(wèn)不同的資源。
2）H5多版本實(shí)驗(yàn)分流原理
- 公共VUA將多版本實(shí)驗(yàn)對(duì)應(yīng)的靜態(tài)資源請(qǐng)求代理到霍金VUA。
- 霍金VUA通過(guò)APISIX插件 按照實(shí)驗(yàn)配置選擇upstream并代理到對(duì)應(yīng)的靜態(tài)資源服務(wù)器。
3）流程示意圖
- 多版本實(shí)驗(yàn)分流
- 多頁(yè)面實(shí)驗(yàn)分流
- 霍金實(shí)驗(yàn)平臺(tái)分流APISIX插件
- H5實(shí)驗(yàn)的分流數(shù)據(jù)采集
多頁(yè)面實(shí)驗(yàn)分流
1）H5多頁(yè)面實(shí)驗(yàn)介紹
多個(gè)不同url做實(shí)驗(yàn)，通過(guò)霍金分流，不同用戶訪問(wèn)到不同的url頁(yè)面。
2）H5多頁(yè)面實(shí)驗(yàn)原理
- 公共VUA將多頁(yè)面實(shí)驗(yàn)對(duì)應(yīng)的入口業(yè)務(wù)路徑的靜態(tài)資源請(qǐng)求代理到霍金VUA。
- 霍金VUA通過(guò)APISIX插件 按照實(shí)驗(yàn)配置重寫路徑到不同的頁(yè)面。
3）流程示意圖
霍金實(shí)驗(yàn)平臺(tái)分流APISIX插件
流程示意圖如下：
插件開發(fā)規(guī)范參考：
??https://apisix.apache.org/zh/docs/apisix/plugin-develop??
H5實(shí)驗(yàn)的分流數(shù)據(jù)采集
H5實(shí)驗(yàn)的分流數(shù)據(jù)保存在霍金VUA平臺(tái)的access_log中，經(jīng)過(guò)如下幾個(gè)步驟最終存入HIVE庫(kù)的DW表中，供后續(xù)的數(shù)據(jù)分析使用。
五、實(shí)驗(yàn)效果分析
該模塊包括指標(biāo)服務(wù)、數(shù)據(jù)分析與效果展示、準(zhǔn)實(shí)時(shí)指標(biāo)計(jì)算、AA分析等功能，因篇幅有限，不在此展開。
六、總結(jié)與展望
本文主要通過(guò)介紹A/B實(shí)驗(yàn)在vivo的平臺(tái)化、產(chǎn)品化的建設(shè)和實(shí)踐，實(shí)現(xiàn)了以下的價(jià)值和能力：
- 用戶可在平臺(tái)上完成創(chuàng)建實(shí)驗(yàn)-數(shù)據(jù)分析-決策-調(diào)整實(shí)驗(yàn)的閉環(huán)，操作簡(jiǎn)單，靈活性高；
- 提供科學(xué)可靠的多層分流算法，流量可復(fù)用，無(wú)需發(fā)版即可快速驗(yàn)證產(chǎn)品方案、運(yùn)營(yíng)策略、優(yōu)化算法；
- 提供實(shí)時(shí)實(shí)驗(yàn)分流監(jiān)控、小時(shí)級(jí)的指標(biāo)監(jiān)控以及離線數(shù)據(jù)分析功能；
- 支持自定義指標(biāo)，無(wú)需等待分析師開發(fā)報(bào)表，即配即查。
但還存在用戶體驗(yàn)等問(wèn)題，后續(xù)我們會(huì)重點(diǎn)在實(shí)驗(yàn)流程，數(shù)據(jù)服務(wù)功能諸如指標(biāo)配置（常用指標(biāo)固化、指標(biāo)配置簡(jiǎn)化）和數(shù)據(jù)展示（交互優(yōu)化、多維分析、歸因分析）等進(jìn)行優(yōu)化和完善，持續(xù)提升用戶體驗(yàn)。
參考資料：
