灰度發佈的定義

互聯網產品需要快速迭代開發上線，又要保證質量，保證剛上線的系統，一旦出現問題可以很快控制影響面，就需要設計一套灰度發佈系統。

灰度發佈系統的作用，可以根據配置，將用戶的流量導到新上線的系統上，來快速驗證新的功能，而一旦出現問題，也可以馬上的修復，簡單的說，就是一套 A/B Test 系統。

灰度發佈允許帶着 bug 上線，只要 bug 不是致命的，當然這個 bug 是不知道的情況下，如果知道就要很快的改掉

簡單灰度發佈系統的設計

灰度簡單架構如上圖所示，其中的必要組件如下：

1、策略的配置平臺，存放灰度的策略

2、灰度功能的執行程序

3、註冊中心，註冊的服務攜帶 ip/Port/name/version

有了上面三個組件，纔算一個完整的灰度平臺

灰度的策略

灰度必須要有灰度策略，灰度策略常見的方式有以下幾種

1、基於 Request Header 進行流量切分

2、基於 Cookie 進行流量切分

3、基於請求參數進行流量切分

舉例：根據請求中攜帶的用戶 uid 進行取模，灰度的範圍是百分之一，那麼 uid 取模的範圍就是 100，模是 0 訪問新版服務，模是 1~99 的訪問老版服務。

灰度發佈策略分爲兩類，單策略和組合策略

單策略：比如按照用戶的 uid、token、ip 進行取模

組合策略：多個服務同時灰度，比如我有 A/B/C 三個服務，需要同時對 A 和 C 進行灰度，但是 B 不需要灰度，這個時候就需要一個 tag 字段，具體實現在下文詳述

灰度發佈具體的執行控制

在上面的簡單灰度發佈系統架構中我們瞭解到，灰度發佈服務分爲上游和下游服務，上游服務是具體的執行灰度策略的程序，這個服務可以是 nginx，也可以是微服務架構中的網關層 / 業務邏輯層，下面我們就來分析一下不同的上游服務，如何落地

Nginx

如果上游服務是 nginx，那麼就需要 nginx 通過 Lua 擴展 nginx 實現灰度策略的配置和轉發，因爲 nginx 本身並不具備灰度策略的執行

通過 lua 擴展實現了灰度策略的執行，但是問題又來了，nginx 本身並不具備接收配置管理平臺的灰度策略，這個時候應該怎麼辦呢？

解決方案：本地部署 Agent（需要自己開發），接收服務配置管理平臺下發的灰度策略，更新 nginx 配置，優雅重啓 Nginx 服務

網關層 / 業務邏輯層 / 數據訪問層

只需要集成配置管理平臺客戶端 SDK，接收服務配置管理平臺下發的灰度策略，在通過集成的 SDK 進行灰度策略的執行即可

灰度發佈複雜場景

下面舉例兩個稍微複雜的灰度發佈場景，灰度策略假設都按照 uid 取模灰度百分之一的用戶，看一下如何實現。

場景 1：調用鏈上同時灰度多個服務

功能升級涉及到多個服務變動，網關層和數據訪問層灰度，業務邏輯層不變，這個時候應該如何進行灰度？

解決方案：

經過新版本網關層的請求，全部打上 tag T，在業務邏輯層根據 tag T 進行轉發， 標記 Tag T 的請求全部轉發到新版數據訪問層服務上，沒有 tag T 的請求全部轉發到老版數據訪問層上。

場景 2：涉及數據的灰度服務

涉及到數據的灰度服務，一定會使用到數據庫，使用到數據庫就會涉及到你使用數據庫前後的表字段不一致，我老版本是 A/B/C 三個字段，新版本是 A/B/C/D 四個字段。這時新版的灰度，就不能往老版的數據庫進行修改了，這個時候就需要把數據 copy 一份出來做這個事情了

數據庫其實並沒有灰度的概念，這個時候我們只能把數據重新拷貝一份出來進行讀和寫，因爲這時你的寫必須是全量的（雙寫），不能說 90% 的數據寫入到老版本，10% 的數據寫入到新版本，因爲這個時候你會發現兩個數據庫的數據都不是全量的。

離線全量複製數據的過程中一定會有數據丟失，這個時候就需要業務邏輯層寫一份數據到 MQ 中，等數據同步完成之後，新版的數據訪問層再將 MQ 的數據寫入到新版本的 DB 中，實現數據的一致性，這個也是引入 MQ 的主要目的。

灰度過程中需要對兩個數據庫的數據進行對比，觀察數據是否一致。這樣不管是灰度失敗，放棄新版 DB，還是灰度成功切換到新版 DB，數據都不會產生丟失。

如果您喜歡本文，歡迎點擊右上角，把文章分享到朋友圈~~
如果有想了解和學習的知識點或技術點，也可以留言給若飛安排分享

作者：kelgon

來源：https://www.toutiao.com/i6910008843955192323/

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