作者 | 小楊互聯網
灰度發佈的定義
互聯網產品需要快速迭代開發上線,又要保證質量,保證剛上線的系統,一旦出現問題可以很快控制影響面,就需要設計一套灰度發佈系統。
灰度發佈系統的作用,可以根據配置,將用戶的流量導到新上線的系統上,來快速驗證新的功能,而一旦出現問題,也可以馬上的修復,簡單的說,就是一套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,數據都不會產生丟失。
往期推薦
本文分享自微信公衆號 - 程序猿DD(didispace)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。