前端灰度發佈落地方案

一個大型的前端項目在發佈時，都會採取灰度策略。很多時候，不可能全量放出一個新的 feature，可能帶來的風險很大，一般都會先進行部門灰度，然後再 20%，40% 灰度，直到全量發佈。

那到底灰度是啥，它的原理是什麼? 本文值得收藏後閱讀～

前言

前段時間在面試的時候遇到過前端灰度發佈相關的問題，剛好在之前公司有設計過前端灰度發佈的方案，這套方案也在多個系統上得到過驗證了，最近有時間整理，現在也拿出來和大家交流下，在結尾也給大家留下了一些的代碼實現，有興趣的夥伴可以去查看下

tips

關於灰度規則的一些放量算法也比較容易找到，熊貓這篇文章重點不是講算法，只是更多貼合實際場景把灰度方案落地，對於放量算法有高要求的夥伴可以自行搜一下放量算法相關，桶漏、令牌算法等

什麼是灰度發佈

將某個功能灰度發佈（逐漸放量）給特定線上人羣，避免新功能全量上線帶來的風險

上白話文，某項目當前處於 1.0 版本，但是想更新一個 1.1 版本，1.1 版本內測沒有問題了，但是由於改動了關鍵的功能，想要實現只給一部分線上用戶使用體驗，看看反饋。這個時候線上就需要一部分用戶繼續用 1.0 版本，一部分用 1.1 的版本，如果 1.1 版本接收到反饋的問題嚴重到影響上線了，那麼就回退 1.0 版本，影響的用戶範圍比較小，如果 1.1 版本穩定，那就直接給所有用戶過度到 1.1 版本。實現這種場景效果，就是灰度發佈。

什麼是灰度規則？灰度規則可以是用戶等級、性別、地區、客戶端等業務信息或者設備信息，比如灰度規則設定爲廣東地區的用戶放問 1.1 版本，那麼廣東用戶訪問項目的時候就算命中了灰度規則，給他們轉去 1.1 版本，其他地區的用戶繼續使用 1.0 版本

常見灰度發佈方案

灰度方案各式各樣，既有多樣就有對比，沒有最好，只有最合適自己的業務場景，這裏給大家介紹幾種方案，以便大家做比較選擇

1. 簡單 ngxin 分流（推薦指數：⭐️）

本身只依賴 nginx 來做的分流還算不上灰度發佈的，但是偶然間跟朋友聊起了他們小公司的騷操作實現，賴着說要我寫進來，說他們已經試驗過了

優點： 簡單，不涉及後端操作缺點：

  1. 只能簡單依賴 nginx 加權輪詢百分比來控制流量，全靠前端，無法結合業務做分流

  2. 可控性弱，在灰度版本出現問題的時候，只能通過修改 nginx 配置來讓用戶回退版本

  3. 問題收集能力差，只能等待用戶反饋

  4. 在客戶端 cookie 被清理掉後，用戶需要重新通過 nginx 的加權輪詢進入，有可能被分配到與上一個分配不同的版本

2. nginx + lua + redis（推薦指數：⭐️⭐️）

tips：這套方案可能是熊貓沒找到好的資料或者對這套方案理解得不夠深刻，熊貓覺得靈活性有些欠缺，比較難結合複雜的業務做過多的灰度邏輯判斷，如果有大佬用過這套方案的，求不吝賜教。

nginx + lua + redis 方案網上的資料也比較多，大家可以自行了解，雖然熊貓對着套方案理解不透徹，從整個鏈路長度理論來看這套方案效率應該是比較高的，所以還是給大家貼了一些文章參考:

3. 服務端渲染分流（推薦指數：⭐️⭐️⭐️）

服務器渲染分流的方案，其實也是我覺得比較好使的一個方案，這裏我先做一些流程簡述，後續也會單獨對着一塊做一些介紹

優點：靈活、可控性強，可結合業務體系做灰度放量規則 缺點：幾乎是後端一把梭，對服務器有壓力，需要多做相關優化，多頁面應用使用比較麻煩

4. 客戶端註釋判斷（比較難維護）（推薦指數：推條毛毛，不推薦）

客戶端通過註釋條件編譯，來做灰度，其實就是根據灰度規則對應在代碼層面上做判斷顯示哪些版本的功能，這種方案也有公司在使用，灰度功能一但多了，極其難維護，不推薦，這裏就不過多介紹了

5. nginx + 服務端 + redis + [前端 sdk] （推薦指數：⭐️⭐️⭐️）

整體方案概述

方案設計圖示

名詞代號

具體實現（簡單演示）

  1. 分別創建兩個 html 假設是兩個項目，beta 是新功能灰度版本，stable 是當前生產環境版本

  2. 在前端引入 sdk（前端 sdk 非必須，看業務場景使用）

  3. 前端發起請求，獲取版本信息（如果引入了 sdk，可以通過配置做這一步驟）

  1. 後端服務邏輯：

後臺實現代碼

//這裏只是演示，直接通過鏈接獲取用戶id，實際場景應該是通過獲取用戶會話去判別用戶相關信息
const uuid = ctx.query.uuid; 
//可以進入灰度版本的uuid，在數據庫存放
const uuids = ['123','456','789'] 
//redis 中存放了的的用戶id，如果清理了redis，則意味着，取消用戶的版本標識，這裏簡單的用數組存放，實際應用場景根據各自的業務信息考慮是否需要多集合存放
const redisUuids = [{id: '789', version: 'beta'}, {id: '333', version: 'stable'}];
複製代碼

上面代碼邏輯是當 uuid 爲 123 或者 456 或者 789 的時候就命中灰度規則，就進入 beta 版本 redis 中已經存放了 uuid 爲 789 和 333 的用戶了

  1. 效果：

灰度問題處理操作

代碼

彩蛋代碼

公司後端是用了 java 去實現的，熊貓在這裏爲了方便大家更好的去理解整個流程，也用 node 給大家實現了一遍，有興趣的小夥伴去可以直接去看代碼 github(https://github.com/wujianrong/gray-released)，大體的設計思路是一樣的

注意點：   爲了方便運行查看演示，熊貓是通過 docker compose 來跑的，在有 docker 和 docker compose 的前提下，可以直接通過命令跑起示例

docker-compose build

docker-compose up -d

localhost:8000
複製代碼

近況

最近是處於一個離職的交接期，在離職期間，熊貓在目前的公司是一個前端組的小頭目，在提出離職一週後，優先開始做了管理崗相關的交接，在做完管理方面的交接後呢，迅速就被 OOXX 了，哈哈哈哈，面對一些人的態度也開始轉變，心裏拔涼拔涼的，原本排了計劃給團隊做一些基建的優化和幾個課題的分享，也許並不需要熊貓太操心了，關掉了之前的博客站，轉到了在掘金這邊學習也試着更新一些文章，有一些心態上的調節，也更多的心思迴歸到技術的同時也好好整理一下自己，接下來做好離職前的技術項目交接就散場了，感謝給過熊貓點贊支持的靚仔靚女們。

結語

方案千千萬，選擇自己合適的就好，演示代碼中熊貓只是簡單的寫了一些邏輯性的代碼，並不是真正可放到項目的邏輯，具體還是要結合實際的項目場景調整，前端 sdk 和 java 部分的代碼熊貓沒有放出來，是因爲該方案已經在公司實行過的，不便放出，大家可以根據大致的思路來編寫，有疑問歡迎來討論，文中有錯的地方或者有更好的方案還望各位大佬不吝賜教。

作者：超神熊貓

來源：juejin.cn/post/7010751591087079460

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gRP21MlLLMuU2Fm6XCtwzw

猜你喜歡