編輯導語：灰度，就是存在於黑與白之間的一個平滑過渡的區域。對於網際網路產品來說，上線和未上線就是黑與白之分，而實現未上線功能平穩過渡的一種方式就叫做灰度釋出。不少大廠在產品上線前都會進行灰度測試，本文作者為大家總結了大廠常用的幾種灰度釋出方案。
什麼是灰度釋出？百度百科的解釋是這樣的：
灰度釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。
AB test就是一種灰度釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
從上述可以看出，灰度釋出的作用有以下幾點：
降低釋出帶來的影響，雖然功能都在測試環境測過，但畢竟沒有釋出到生產環境，如果先讓少部分使用者先使用新版本，提前發現bug，或者效能問題，提前做好修復，就可以降低新版本帶來的影響；
透過對新老版本的對比，觀察新版本帶來的效果。
結合工作中使用到的灰度釋出實踐和對其他大廠的灰度釋出調研，總結了以下灰度釋出方案。
一、灰度釋出的劃分
灰度釋出如果按照端來分的話，可以分為web前端、客戶端、服務端灰度。
無論是哪種灰度，一般需要滿足以下2點要求：
需要一個放量配置，給產品/運營等工作人員配置放量策略；
需要做到同一個使用者始終訪問的是同一個版本的程式碼，如果同個使用者上個請求訪問的是A版本，下個請求訪問的是B版本，就可能會出問題。
1. web前端灰度
假設我們的前端資源存放在CDN上面：我們每次釋出一個新版本，就把資源增量式地上傳到CDN，然後給它分配一個唯一的版本號，再把所有的版本號儲存起來。當處理請求時，根據動態配置的分流策略來決定使用者使用哪個版本。
比如分流策略是放量10%，即新版本隨機放量給10%的使用者使用，當用戶首次命中資源版本號時，需要把使用者id和版本號的對映關係儲存起來（可存到cookie），這樣就能保證同個使用者上次請求和下次請求訪問到的都是同個版本的程式碼。
那如果線上有緊急bug需要修復，又要重新發布新版本，該如何處理當前灰度的狀態？是趕緊結束上一個灰度然後全量釋出還是一起發上去同時灰度？一般來說，再有新版本釋出或者放量策略發生變化時，應該重新分流灰度。
1. web前端灰度
服務端灰度分為相容變更灰度和不相容變更灰度。
2. 服務端灰度
相容變更又可分為物理灰度和邏輯灰度。
物理灰度：物理灰度比較簡單，根據機器維度進行灰度，直接部署新老版本在不同機器，流量均勻地打在新老版本上面。這種方式雖然簡單，但不適用於不相容變更；
邏輯灰度：邏輯灰度就是根據更精確的流量策略來控制流量，這種灰度一般要寫一定的灰度程式碼。這種方式能比較精確地控制流量，但是增加了一定的灰度程式碼，灰度完成後要刪除相關灰度程式碼，有點麻煩。
2. 服務端灰度
不相容變更指的是更改了當前功能，即介面邏輯跟之前版本發生很大變化，必須要前後端同時釋出，否則會有一段時間服務不可用。
一般的做法是引入介面版本號，新老版本介面並存，比如 /v1/api 和 /v2/api。前端使用/v2/api版本，當過去一段穩定期後（可以是登入態時間失效後），就可下掉/v1/api版本。
1）相容變更
web前端和服務端灰度釋出可以在客戶無感知的情況下平滑進行，遇到問題也可以快速回滾，但是移動客戶端涉及到使用者的主動安裝行為，所以上述的方式已經不適用。
如果一個帶有bug的安裝包全量釋出出去，一旦有問題，我們只能快速定位問題來提醒使用者安裝新版本，是否安裝取決於使用者，所以客戶端灰度釋出是非常有必要的。
客戶端在啟動時，會向灰度系統發起請求，灰度系統根據客戶端傳過來的引數和當前的放量策略來決定是否要給客戶端升級提醒。一般會根據以下幾種策略來決定給予使用者升級提醒：
根據使用者裝置的系統和應用版本；
根據渠道：釋出到不同應用市場的app都會被打上渠道標籤，所以可以根據渠道來區分使用者；
根據裝置ID和使用者ID。
透過裝置ID主要是為了控制提醒頻率，使用者ID主要是為了區分出特性使用者，比如對活躍使用者傳送提醒。
二、灰度放量策略
流量策略一般分為以下幾種：
2）不相容變更
先到先得的方式比如限制10%的使用者體驗的是新版本，90%的使用者體驗的是老版本。先訪問網站的使用者就優先命中新版本，直到流量用完為止。
3. 客戶端灰度
按使用者id、使用者ip、裝置型別比如可透過平時的埋點上報資料得知使用者的pv、uv、頁面平均訪問時長等資料，根據使用者活躍度來讓使用者優先體驗新版本，進而快速觀察使用效果。
按地域、性別、年齡等使用者畫像比如可透過使用者的性別、年齡等做下新老版本的對比效果來看看目標使用者在新版本的使用年齡段，性別範圍是多少。
3. 客戶端灰度
比如根據使用者的註冊來源來放量。
三、灰度釋出的代價
透過上面的講解，可以看到一個完整的灰度釋出，包括前端、後臺都需要額外的程式碼量去實現，如果只有幾萬的使用者，要去實現這樣一套灰度釋出，代價是比較高的。
但如果是百萬～億級使用者，灰度釋出是很值得的，它不僅能降低新版本bug的風險，還能透過版本對比，推出最好效果的版本應用。
前百度前端工程師，現騰訊前端工程師，公眾號：產品的技術小課。
本文由 @lemon 原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議