一篇文章理解AB測試和灰度發布

  • 2019 年 11 月 22 日
  • 筆記

版權聲明:本文為部落客原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接和本聲明。

本文鏈接:https://blog.csdn.net/pyycsd/article/details/103178565

一、灰度發布

1.1 簡介

灰度發布,是指黑與白之間,能夠平滑過渡的一種發布方式。 通過不同策略對用戶進行分流,不同的用戶組使用不同的應用版本。

1.2 優缺點

  • 優點 互聯網服務變動頻繁,發布周期短。速度和品質總是難以雙全。灰度發布有以下優點: (1)降低發布風險,減少影響範圍 (2)可以灰度測試帳號,降低測試依賴,減少自測的數據構造成本 (3)方便回滾
  • 缺點 (1)開發、測試和部署的成本較高 (2)數據存儲層需要兼容

二、AB測試

2.1 簡介

AB Test是一種灰度方式,通常差異度較小,側重從多種方案中選擇最優方案。

簡單的說,就是為同一個目標制定兩個方案(比如兩個頁面),讓一部分用戶使用 A 方案,另一部分用戶使用 B 方案, 記錄下用戶的使用情況,看哪個方案更符合。

一般來說,每個設計方案大體上是相同的,只是某一個地方有所不同,比如某出排版、文案、圖片、顏色等。然後對不同的用戶展示不同的方案。

2.2 優缺點

  • 優點:避免選擇分歧和反覆試錯,優化決策,最終方案有數據支援
  • 缺點:開發和測試周期增加,多套方案出現want的可能性高

2.3 核心思想

  • 多方案並行測試
  • 同一個用戶(一般通過cookie控制)展示同一版本
  • 以某種規則優勝劣汰

2.4 實現步驟

  1. 定義策略:確定分流的目的、放量規模、遞增的頻率、回滾的策略等;
  2. 篩選用戶:確定分流訪問的用戶特徵,定義規則(根據IP,user_id,cookie,業務需求(商戶)等因素,指定分流策略)或導入名單;
  3. 訪問分流:技術支撐,根據分流策略向用戶展示不同內容;
  4. 發布運行:根據不同的實現方案進行部署;
  5. 採集分析:收集數據,比較不同的方案效果,確定最終方案。

2.5 實現方案

關鍵點:控制邏輯的顆粒度

2.5.1 Nginx控制

兩套程式碼分布部署在不同的機器,通過Nginx配置分流 大多數公司採用這種方案(google,阿里,騰訊,新浪等)

優缺點: 優點:對業務侵入性小,灰度發布和正式上線都非常方便 缺點:開發流程是分支開發模式;程式碼部署比較複雜

實現

  • Nginx 根據權重分流
  • Nginx + Lua + redis/memcache
  • Nginx + cookie

2.5.2 後台程式碼控制

業務邏輯中控制分流

優缺點: 優點:對外部系統以來小,全部邏輯都在業務伺服器完成,適合主幹開發的模式; 缺點:對業務侵入性大,灰度發布不方便,程式碼維護還有整潔度下降。

實現

  • 路由層控制
  • Control 層控制重定向

2.5.3 前台程式碼控制

js 通過 if-else 控制分流

優缺點和第二種類似,比較適合差異度小的測試

兩個版本只有一個較小的區域不一樣,我們可以同時將兩個區域的 HTML 都載入到當前頁面中,先用 CSS 把他們隱藏起來(也可以默認顯示一個版本),等通過 JS 判斷該顯示哪個版本後,再控制對應版本的 CSS 顯示。

測試區域比較大,程式碼比較多,或者需要後台比較多的計算資源,如果一開始就把兩個版本的 HTML 全部都載入噹噹前頁面中,就會需要比較大的開銷(比如頻寬、後台計算量)。這種情況下,我們可以先把測試區留空,之後再用Ajax的方式延遲載入。

2.5.4 第三方框架

三、總結

以上就是我們為大家總結的AB測試和灰度發布了,可以說這兩者是一個包含的關係,灰度發布方法裡面是可以包含AB測試的,反之,AB測試是灰度發布眾多方法當中的其中一個

參考資料