馬蜂窩ABTest多層分流系統(tǒng)的設計與實現(xiàn)

readersu 2019-05-28

展開全文

什么是 ABTest

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

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

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

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

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

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

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

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

基于 Openresty 的多層分流模型

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

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

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

整體流程

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

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

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

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

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

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

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

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

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

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

示意圖如下：

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

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

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

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

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

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

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

第三層 Redis。

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

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

關鍵特性

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

性能表現(xiàn)

響應時間分布

TPS 分布

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

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

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

A/B發(fā)布

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

小結(jié)

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

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

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

近期規(guī)劃改善：