摘要：為了解決以上問題，我們的分流系統(tǒng)選擇基于實(shí)現(xiàn)，通過或者協(xié)議來傳遞分流信息。正交是指用戶進(jìn)入所有的實(shí)驗(yàn)之間沒有必然關(guān)系。流量層內(nèi)實(shí)驗(yàn)分流流量層內(nèi)實(shí)驗(yàn)的因子有設(shè)備流量層。統(tǒng)計(jì)功效對(duì)于置信區(qū)間特征值等產(chǎn)品化功能支持。

產(chǎn)品的改變不是由我們隨便「拍腦袋」得出，而是需要由實(shí)際的數(shù)據(jù)驅(qū)動(dòng)，讓用戶的反饋來指導(dǎo)我們?nèi)绾胃玫馗纳品?wù)。正如馬蜂窩 CEO 陳罡在接受專訪時(shí)所說：「有些東西是需要 Sense，但大部分東西是可以用 Science 來做判斷的?！?/p>

說到 ABTest 相信很多讀者都不陌生。簡(jiǎn)單來說，ABTest?就是將用戶分成不同的組，同時(shí)在線試驗(yàn)產(chǎn)品的不同版本，通過用戶反饋的真實(shí)數(shù)據(jù)來找出采用哪一個(gè)版本方案更好的過程。

我們將原始版本作為對(duì)照組，以每個(gè)版本進(jìn)行盡量是小的流量迭代作為原則去使用 ABTest。一旦指標(biāo)分析完成，用戶反饋數(shù)據(jù)表現(xiàn)最佳的版本再去全量上線。

很多時(shí)候，一個(gè)按鈕、一張圖片或者一句文案的調(diào)整，可能都會(huì)帶來非常明顯的增長(zhǎng)。這里分享一個(gè)ABTest 在馬蜂窩的應(yīng)用案例：

如圖所示，之前我們交易中心的電商業(yè)務(wù)團(tuán)隊(duì)希望優(yōu)化一個(gè)關(guān)于「滑雪」的搜索列表。可以看到優(yōu)化之前的頁面顯示從感覺上是比較單薄的。但是大家又不確定復(fù)雜一些的展現(xiàn)形式會(huì)不會(huì)讓用戶覺得不夠簡(jiǎn)潔，產(chǎn)生反感。因此，我們將改版前后的頁面放在線上進(jìn)行了 ABTest。最終的數(shù)據(jù)反饋表明，優(yōu)化之后的樣式 UV 提高了 15.21%，轉(zhuǎn)化率提高了 11.83%。使用 ABTest 幫助我們降低了迭代的風(fēng)險(xiǎn)。

通過這個(gè)例子，我們可以更加直觀地理解 ABTest 的幾個(gè)特性：

先驗(yàn)性：采用流量分割與小流量測(cè)試的方式，先讓線上部分小流量用戶使用，來驗(yàn)證我們的想法，再根據(jù)數(shù)據(jù)反饋來推廣到全流量，減少產(chǎn)品損失。

并行性：我們可以同時(shí)運(yùn)行兩個(gè)或兩個(gè)以上版本的試驗(yàn)同時(shí)去對(duì)比，而且保證每個(gè)版本所處的環(huán)境一致的，這樣以前整個(gè)季度才能確定要不要發(fā)版的情況，現(xiàn)在可能只需要一周的時(shí)間，避免流程復(fù)雜和周期長(zhǎng)的問題，節(jié)省驗(yàn)證時(shí)間。

科學(xué)性：統(tǒng)計(jì)試驗(yàn)結(jié)果的時(shí)候，ABTest 要求用統(tǒng)計(jì)的指標(biāo)來判斷這個(gè)結(jié)果是否可行，避免我們依靠經(jīng)驗(yàn)主義去做決策。

為了讓我們的驗(yàn)證結(jié)論更加準(zhǔn)確、合理并且高效，我們參照 Google 的做法實(shí)現(xiàn)了一套算法保障機(jī)制，來嚴(yán)格實(shí)現(xiàn)流量的科學(xué)分配。

大部分公司的 ABTest 都是通過提供接口，由業(yè)務(wù)方獲取用戶數(shù)據(jù)然后調(diào)用接口的方式進(jìn)行，這樣會(huì)將原有的流量放大一倍，并且對(duì)業(yè)務(wù)侵入比較明顯，支持場(chǎng)景較為單一，導(dǎo)致多業(yè)務(wù)方需求需要開發(fā)出很多分流系統(tǒng)，針對(duì)不同的場(chǎng)景也難以復(fù)用。

為了解決以上問題，我們的分流系統(tǒng)選擇基于 Openresty 實(shí)現(xiàn)，通過 HTTP 或者 GRPC 協(xié)議來傳遞分流信息。這樣一來，分流系統(tǒng)就工作在業(yè)務(wù)的上游，并且由于 Openresty 自帶流量分發(fā)的特性不會(huì)產(chǎn)生二次流量。對(duì)于業(yè)務(wù)方而言，只需要提供差異化的服務(wù)即可，不會(huì)侵入到業(yè)務(wù)當(dāng)中。

選型?Openresty?來做?ABTest?的原因主要有以下幾個(gè)：

在設(shè)計(jì) ABTest 系統(tǒng)的時(shí)候我們拆分出來分流三要素，第一是確定的終端，終端上包含了設(shè)備和用戶信息；第二是確定的 URI ；第三是與之匹配的分配策略，也就是流量如何分配。

首先設(shè)備發(fā)起請(qǐng)求，AB 網(wǎng)關(guān)從請(qǐng)求中提取設(shè)備 ID 、URI 等信息，這時(shí)終端信息和 URI 信息已經(jīng)確定了。然后通過 URI 信息遍歷匹配到對(duì)應(yīng)的策略，請(qǐng)求經(jīng)過分流算法找到當(dāng)前匹配的 AB 實(shí)驗(yàn)和版本后，AB 網(wǎng)關(guān)會(huì)通過兩種方式來通知下游。針對(duì)運(yùn)行在物理 web 機(jī)的應(yīng)用會(huì)在 header 中添加一個(gè)名為 abtest 的 key，里面包含命中的 AB 實(shí)驗(yàn)和版本信息。針對(duì)微服務(wù)應(yīng)用，會(huì)將命中微服務(wù)的信息添加到 Cookie 中交由微服務(wù)網(wǎng)關(guān)去處理。

分流算法我們采用的 MurmurHash 算法，參與算法的 Hash 因子有設(shè)備 id、策略 id、流量層 id。

MurmurHash 是業(yè)內(nèi) ABTest 常用的一個(gè)算法，它可以應(yīng)用到很多開源項(xiàng)目上，比如說 Redis、Memcached、Cassandra、HBase 等。MurmurHash 有兩個(gè)明顯的特點(diǎn)：

快，比安全散列算法快幾十倍

變化足夠激烈，對(duì)于相似字符串，比如說「abc」和「 abd 」能夠均勻散布在哈希環(huán)上，主要是用來實(shí)現(xiàn)正交和互斥實(shí)驗(yàn)的分流

下面簡(jiǎn)單解釋下正交和互斥：

互斥。指兩個(gè)實(shí)驗(yàn)流量獨(dú)立，用戶只能進(jìn)入其中一個(gè)實(shí)驗(yàn)。一般是針對(duì)于同一流量層上的實(shí)驗(yàn)而言，比如圖文混排列表實(shí)驗(yàn)和純圖列表實(shí)驗(yàn)，同一個(gè)用戶在同一時(shí)刻只能看到一個(gè)實(shí)驗(yàn)，所以他們互斥。

正交。正交是指用戶進(jìn)入所有的實(shí)驗(yàn)之間沒有必然關(guān)系。比如進(jìn)入實(shí)驗(yàn) 1 中 a 版本的用戶再進(jìn)行其它實(shí)驗(yàn)時(shí)也是均勻分布的，而不是集中在某一塊區(qū)間內(nèi)。

流量層內(nèi)實(shí)驗(yàn)分流

流量層內(nèi)實(shí)驗(yàn)的 hash 因子有設(shè)備 id、流量層 id。當(dāng)請(qǐng)求流經(jīng)一個(gè)流量層時(shí)，只會(huì)命中層內(nèi)一個(gè)實(shí)驗(yàn)，即同一個(gè)用戶同一個(gè)請(qǐng)求每層最多只會(huì)命中一個(gè)實(shí)驗(yàn)。首先對(duì) hash 因子進(jìn)行 hash 操作，采用 murmurhash2 算法，可以保證 hash 因子微小變化但是結(jié)果的值變化激烈，然后對(duì) 100 求余之后+1，最終得到 1 到 100 之間的數(shù)值。

示意圖如下：

實(shí)驗(yàn)內(nèi)版本分流

實(shí)驗(yàn)的 hash 因子有設(shè)備 id、策略 id、流量層 id。采用相同的策略進(jìn)行版本匹配。匹配規(guī)則如下：

剛才說到，每一個(gè)請(qǐng)求來臨之后，系統(tǒng)都會(huì)嘗試去獲取與之匹配的實(shí)驗(yàn)策略。實(shí)驗(yàn)策略是在從后臺(tái)配置的，我們通過消息隊(duì)列的形式，將經(jīng)過配置之后的策略，同步到我們的策略池當(dāng)中。

我們最初的方案是每一個(gè)請(qǐng)求來臨之后，都會(huì)從 Redis 當(dāng)中去讀取數(shù)據(jù)，這樣的話對(duì) Redis 的穩(wěn)定性要求較高，大量的請(qǐng)求也會(huì)對(duì) Redis 造成比較高的壓力。因此，我們引入了多級(jí)緩存機(jī)制來組成策略池。策略池總共分為三層：

第一層 lrucache，是一個(gè)簡(jiǎn)單高效的緩存策略。它的特點(diǎn)是伴隨著 Nginx worker 進(jìn)程的生命周期存在，worker 獨(dú)占，十分高效。由于獨(dú)占的特性，每一份緩存都會(huì)在每個(gè) worker 進(jìn)程中存在，所以它會(huì)占用較多的內(nèi)存。

第二層?lua_shared_dict，顧名思義，這個(gè)緩存可以跨 worker 共享。當(dāng) Nginx reload 時(shí)它的數(shù)據(jù)也會(huì)不丟失，只有當(dāng) restart 的時(shí)候才會(huì)丟失。但有個(gè)特點(diǎn)，為了安全讀寫，實(shí)現(xiàn)了讀寫鎖。所以再某些極端情況下可能會(huì)存在性能問題。

第三層?Redis。

從整套策略上來看，雖然采用了多級(jí)緩存，但仍然存在著一定的風(fēng)險(xiǎn)，就是當(dāng) L1、L2 緩存都失效的時(shí)候（比如 Nginx restart），可能會(huì)面臨因?yàn)榱髁刻笞?Redis 「裸奔」的風(fēng)險(xiǎn)，這里我們用到 lua-resty-lock 來解決這個(gè)問題，在緩存失效時(shí)只有拿到鎖的這部分請(qǐng)求才可以進(jìn)行回源，保證了 Redis 的壓力不會(huì)那么大。

我們?cè)诰彺?30s 的情況下對(duì)線上數(shù)據(jù)的進(jìn)行統(tǒng)計(jì)顯示，第一級(jí)緩存命中率在 99% 以上，第二級(jí)緩存命中率在 0.5 %，回源到 Redis 的請(qǐng)求只有 0.03 %。

吞吐量：當(dāng)前承擔(dān)全站 5% 流量

低延遲：線上平均延時(shí)低于 2ms

全平臺(tái)：支持 App、H5、WxApp、PC，跨語言

容災(zāi)：

自動(dòng)降級(jí)：當(dāng)從 redis 中讀取策略失敗后，ab 會(huì)自動(dòng)進(jìn)入到不分流模式，以后每 30s 嘗試 (每臺(tái)機(jī)器) 讀取 redis，直到讀取到數(shù)據(jù)，避免頻繁發(fā)送

請(qǐng)求手動(dòng)降級(jí)：當(dāng)出現(xiàn) server_event 日志過多或系統(tǒng)負(fù)載過高時(shí)，通過后臺(tái)「一鍵關(guān)閉」來關(guān)閉所有實(shí)驗(yàn)或關(guān)閉 AB 分流

響應(yīng)時(shí)間分布

TPS 分布

測(cè)試工具采用 JMeter，并發(fā)數(shù) 100，持續(xù) 300s。?

從響應(yīng)時(shí)間來看，除了剛開始的時(shí)候請(qǐng)求偏離值比較大，之后平均起來都在 1ms 以內(nèi)。分析剛開始的時(shí)候差距比較大的原因在于當(dāng)時(shí)的多級(jí)緩存里面沒有數(shù)據(jù)。

TPS的壓測(cè)表現(xiàn)有一些輕微的下降，因?yàn)楫吘勾嬖?hash 算法，但總體來說在可以接受的范圍內(nèi)。?

常規(guī) A/B 發(fā)布主要由 API 網(wǎng)關(guān)來做，當(dāng)面臨的業(yè)務(wù)需求比較復(fù)雜時(shí)， A/B 發(fā)布會(huì)通過與與微服務(wù)交互的方式，來開放更復(fù)雜維度的 A/B 發(fā)布能力。

需要注意的是，ABTest 并不完全適用于所有的產(chǎn)品，因?yàn)?ABTest 的結(jié)果需要大量數(shù)據(jù)支撐，日流量越大的網(wǎng)站得出結(jié)果越準(zhǔn)確。通常來說，我們建議在進(jìn)行 A/B 測(cè)試時(shí)，能夠保證每個(gè)版本的日流量在 1000 個(gè) UV 以上，否則試驗(yàn)周期將會(huì)很長(zhǎng)，或很難獲得準(zhǔn)確（結(jié)果收斂）的數(shù)據(jù)結(jié)果推論。

要設(shè)計(jì)好一套完整的 ABTest 平臺(tái)，需要進(jìn)行很多細(xì)致的工作，由于篇幅所限，本文只圍繞分流算法進(jìn)行了重點(diǎn)分享?？偨Y(jié)看來，馬蜂窩 ABTest 分流系統(tǒng)重點(diǎn)在以下幾個(gè)方面取得了一些效果：

采用流量攔截分發(fā)的方式，摒棄了原有接口的形式，對(duì)業(yè)務(wù)代碼沒有侵入，性能沒有明顯影響，且不會(huì)產(chǎn)生二次流量。

采用流量分層并綁定實(shí)驗(yàn)的策略，可以更精細(xì)直觀的去定義分流實(shí)驗(yàn)。通過和客戶端上報(bào)已命中實(shí)驗(yàn)版本的機(jī)制，減少了服務(wù)數(shù)據(jù)的存儲(chǔ)并可以實(shí)現(xiàn)串行實(shí)驗(yàn)分流的功能。

在數(shù)據(jù)傳輸方面，通過在 HTTP 頭部增加分流信息，業(yè)務(wù)方無需關(guān)心具體的實(shí)現(xiàn)語言。

近期規(guī)劃改善：

監(jiān)控體系。

用戶畫像等精細(xì)化定制AB。

統(tǒng)計(jì)功效對(duì)于置信區(qū)間、特征值等產(chǎn)品化功能支持。

通過?AARRR?模型評(píng)估實(shí)驗(yàn)對(duì)北極星指標(biāo)的影響。

這套系統(tǒng)未來需要改進(jìn)的地方還有很多，我們也將持續(xù)探索，期待和大家一起交流。

本文作者：李培，馬蜂窩基礎(chǔ)平臺(tái)信息化研發(fā)技術(shù)專家；張立虎，馬蜂窩酒店研發(fā)靜態(tài)數(shù)據(jù)團(tuán)隊(duì)工程師。

（馬蜂窩技術(shù)原創(chuàng)內(nèi)容，轉(zhuǎn)載務(wù)必注明出處保存文末二維碼圖片，謝謝配合。）

關(guān)注馬蜂窩技術(shù)，找到更多你需要的內(nèi)容