大廠常用的幾種灰度發佈方案

什麼是灰度發佈？百度百科的解釋是這樣的：

從上述可以看出，灰度發佈的作用有以下幾點：

1. 降低發佈帶來的影響，雖然功能都在測試環境測過，但畢竟沒有發佈到生產環境，如果先讓少部分用户先使用新版本，提前發現bug，或者性能問題，提前做好修復，就可以降低新版本帶來的影響；
2. 通過對新老版本的對比，觀察新版本帶來的效果。

結合工作中使用到的灰度發佈實踐和對其他大廠的灰度發佈調研，總結了以下灰度發佈方案。

一、灰度發佈的劃分

灰度發佈如果按照端來分的話，可以分為web前端、客户端、服務端灰度。

無論是哪種灰度，一般需要滿足以下2點要求：

1. 需要一個放量配置，給產品/運營等工作人員配置放量策略；
2. 需要做到同一個用户始終訪問的是同一個版本的代碼，如果同個用户上個請求訪問的是A版本，下個請求訪問的是B版本，就可能會出問題。

1. web前端灰度

假設我們的前端資源存放在CDN上面：我們每次發佈一個新版本，就把資源增量式地上傳到CDN，然後給它分配一個唯一的版本號，再把所有的版本號存儲起來。當處理請求時，根據動態配置的分流策略來決定用户使用哪個版本。

比如分流策略是放量10%，即新版本隨機放量給10%的用户使用，當用户首次命中資源版本號時，需要把用户id和版本號的映射關係存儲起來（可存到cookie），這樣就能保證同個用户上次請求和下次請求訪問到的都是同個版本的代碼。

那如果線上有緊急bug需要修復，又要重新發布新版本，該如何處理當前灰度的狀態？是趕緊結束上一個灰度然後全量發佈還是一起發上去同時灰度？一般來説，再有新版本發佈或者放量策略發生變化時，應該重新分流灰度。

2. 服務端灰度

服務端灰度分為兼容變更灰度和不兼容變更灰度。

1）兼容變更

兼容變更又可分為物理灰度和邏輯灰度。

• 物理灰度：物理灰度比較簡單，根據機器維度進行灰度，直接部署新老版本在不同機器，流量均勻地打在新老版本上面。這種方式雖然簡單，但不適用於不兼容變更；
• 邏輯灰度：邏輯灰度就是根據更精確的流量策略來控制流量，這種灰度一般要寫一定的灰度代碼。這種方式能比較精確地控制流量，但是增加了一定的灰度代碼，灰度完成後要刪除相關灰度代碼，有點麻煩。

2）不兼容變更

不兼容變更指的是更改了當前功能，即接口邏輯跟之前版本發生很大變化，必須要前後端同時發佈，否則會有一段時間服務不可用。

一般的做法是引入接口版本號，新老版本接口並存，比如 /v1/api 和 /v2/api。前端使用/v2/api版本，當過去一段穩定期後（可以是登錄態時間失效後），就可下掉/v1/api版本。

3. 客户端灰度

web前端和服務端灰度發佈可以在客户無感知的情況下平滑進行，遇到問題也可以快速回滾，但是移動客户端涉及到用户的主動安裝行為，所以上述的方式已經不適用。

如果一個帶有bug的安裝包全量發佈出去，一旦有問題，我們只能快速定位問題來提醒用户安裝新版本，是否安裝取決於用户，所以客户端灰度發佈是非常有必要的。

客户端在啓動時，會向灰度系統發起請求，灰度系統根據客户端傳過來的參數和當前的放量策略來決定是否要給客户端升級提醒。一般會根據以下幾種策略來決定給予用户升級提醒：

1. 根據用户設備的系統和應用版本；
2. 根據渠道：發佈到不同應用市場的app都會被打上渠道標籤，所以可以根據渠道來區分用户；
3. 根據設備ID和用户ID。

通過設備ID主要是為了控制提醒頻率，用户ID主要是為了區分出特性用户，比如對活躍用户發送提醒。

二、灰度放量策略

流量策略一般分為以下幾種：

1. 按流量百分比

先到先得的方式比如限制10%的用户體驗的是新版本，90%的用户體驗的是老版本。先訪問網站的用户就優先命中新版本，直到流量用完為止。

2. 按人羣劃分

1. 按用户id、用户ip、設備類型比如可通過平時的埋點上報數據得知用户的pv、uv、頁面平均訪問時長等數據，根據用户活躍度來讓用户優先體驗新版本，進而快速觀察使用效果。
2. 按地域、性別、年齡等用户畫像比如可通過用户的性別、年齡等做下新老版本的對比效果來看看目標用户在新版本的使用年齡段，性別範圍是多少。

3. 按渠道劃分

比如根據用户的註冊來源來放量。

三、灰度發佈的代價

通過上面的講解，可以看到一個完整的灰度發佈，包括前端、後台都需要額外的代碼量去實現，如果只有幾萬的用户，要去實現這樣一套灰度發佈，代價是比較高的。

但如果是百萬～億級用户，灰度發佈是很值得的，它不僅能降低新版本bug的風險，還能通過版本對比，推出最好效果的版本應用。

前百度前端工程師，現騰訊前端工程師，公眾號：產品的技術小課。

本文由 @lemon 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議