什么是 ABTest

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

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

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

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

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

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

• 先驗性：采用流量分割與小流量測試的方式，先讓線上部分小流量用戶使用，來驗證我們的想法，再根據(jù)數(shù)據(jù)反饋來推廣到全流量，減少產(chǎn)品損失。
• 并行性：我們可以同時運行兩個或兩個以上版本的試驗同時去對比，而且保證每個版本所處的環(huán)境一致的，這樣以前整個季度才能確定要不要發(fā)版的情況，現(xiàn)在可能只需要一周的時間，避免流程復(fù)雜和周期長的問題，節(jié)省驗證時間。
• 科學(xué)性：統(tǒng)計試驗結(jié)果的時候，ABTest 要求用統(tǒng)計的指標(biāo)來判斷這個結(jié)果是否可行，避免我們依靠經(jīng)驗主義去做決策。

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

基于 Openresty 的多層分流模型

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

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

選型 Openresty 來做 ABTest 的原因主要有以下幾個：

整體流程

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

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

穩(wěn)定分流保障：MurmurHash算法

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

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

1. 快，比安全散列算法快幾十倍
2. 變化足夠激烈，對于相似字符串，比如說「abc」和「 abd 」能夠均勻散布在哈希環(huán)上，主要是用來實現(xiàn)正交和互斥實驗的分流

下面簡單解釋下正交和互斥：

• 互斥。指兩個實驗流量獨立，用戶只能進入其中一個實驗。一般是針對于同***量層上的實驗而言，比如圖文混排列表實驗和純圖列表實驗，同一個用戶在同一時刻只能看到一個實驗，所以他們互斥。
• 正交。正交是指用戶進入所有的實驗之間沒有必然關(guān)系。比如進入實驗 1 中 a 版本的用戶再進行其它實驗時也是均勻分布的，而不是集中在某一塊區(qū)間內(nèi)。

流量層內(nèi)實驗分流

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

示意圖如下：

實驗內(nèi)版本分流

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

穩(wěn)定性保障：多級緩存策略

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

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

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

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

第三層 Redis。

從整套策略上來看，雖然采用了多級緩存，但仍然存在著一定的風(fēng)險，就是當(dāng) L1、L2 緩存都失效的時候(比如 Nginx restart)，可能會面臨因為流量太大讓 Redis 「裸奔」的風(fēng)險，這里我們用到 lua-resty-lock 來解決這個問題，在緩存失效時只有拿到鎖的這部分請求才可以進行回源，保證了 Redis 的壓力不會那么大。

我們在緩存 30s 的情況下對線上數(shù)據(jù)的進行統(tǒng)計顯示，***級緩存***率在 99% 以上，第二級緩存***率在 0.5 %，回源到 Redis 的請求只有 0.03 %。

關(guān)鍵特性

• 吞吐量：當(dāng)前承擔(dān)全站 5% 流量
• 低延遲：線上平均延時低于 2ms
• 全平臺：支持 App、H5、WxApp、PC，跨語言
• 容災(zāi)：
  • 自動降級：當(dāng)從 redis 中讀取策略失敗后，ab 會自動進入到不分流模式，以后每 30s 嘗試 (每臺機器) 讀取 redis，直到讀取到數(shù)據(jù)，避免頻繁發(fā)送
  • 請求手動降級：當(dāng)出現(xiàn) server_event 日志過多或系統(tǒng)負載過高時，通過后臺「一鍵關(guān)閉」來關(guān)閉所有實驗或關(guān)閉 AB 分流

性能表現(xiàn)

響應(yīng)時間分布

TPS 分布

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

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

TPS的壓測表現(xiàn)有一些輕微的下降，因為畢竟存在 hash 算法，但總體來說在可以接受的范圍內(nèi)。

A/B發(fā)布

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

小結(jié)

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

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

• 采用流量攔截分發(fā)的方式，摒棄了原有接口的形式，對業(yè)務(wù)代碼沒有侵入，性能沒有明顯影響，且不會產(chǎn)生二次流量。
• 采用流量分層并綁定實驗的策略，可以更精細直觀的去定義分流實驗。通過和客戶端上報已***實驗版本的機制，減少了服務(wù)數(shù)據(jù)的存儲并可以實現(xiàn)串行實驗分流的功能。
• 在數(shù)據(jù)傳輸方面，通過在 HTTP 頭部增加分流信息，業(yè)務(wù)方無需關(guān)心具體的實現(xiàn)語言。

近期規(guī)劃改善：

• 監(jiān)控體系。
• 用戶畫像等精細化定制AB。
• 統(tǒng)計功效對于置信區(qū)間、特征值等產(chǎn)品化功能支持。
• 通過 AARRR 模型評估實驗對北極星指標(biāo)的影響。

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

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

【本文是51CTO專欄作者馬蜂窩技術(shù)的原創(chuàng)文章，作者微信公眾號馬蜂窩技術(shù)(ID：mfwtech)】

戳這里，看該作者更多好文