灰度發佈架構設計！值得品鑑

灰度發佈的定義

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

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

灰度發佈容許帶着bug上線，只要bug不是致命的，固然這個bug是不知道的狀況下，若是知道就要很快的改掉

簡單灰度發佈系統的設計

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

• 一、策略的配置平臺，存放灰度的策略
• 二、灰度功能的執行程序
• 三、註冊中心，註冊的服務攜帶ip/Port/name/version

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

灰度的策略

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

• 一、基於Request Header進行流量切分
• 二、基於Cookie進行流量切分
• 三、基於請求參數進行流量切分

舉例：根據請求中攜帶的用戶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，數據都不會產生丟失。

地址：http://www.fblinux.com/?p=1672 做者：西門飛冰