CTO點(diǎn)名要搞個灰度發(fā)布系統(tǒng),不慌!
灰度發(fā)布的定義
互聯(lián)網(wǎng)產(chǎn)品需要快速迭代開發(fā)上線,又要保證質(zhì)量,保證剛上線的系統(tǒng),一旦出現(xiàn)問題可以很快控制影響面,就需要設(shè)計一套灰度發(fā)布系統(tǒng)。
灰度發(fā)布系統(tǒng)的作用,可以根據(jù)配置,將用戶的流量導(dǎo)到新上線的系統(tǒng)上,來快速驗(yàn)證新的功能,而一旦出現(xiàn)問題,也可以馬上的修復(fù),簡單的說,就是一套A/B Test系統(tǒng)。
灰度發(fā)布允許帶著bug上線,只要bug不是致命的,當(dāng)然這個bug是不知道的情況下,如果知道就要很快的改掉
簡單灰度發(fā)布系統(tǒng)的設(shè)計
灰度簡單架構(gòu)如上圖所示,其中的必要組件如下:
-
策略的配置平臺,存放灰度的策略
-
灰度功能的執(zhí)行程序
-
注冊中心,注冊的服務(wù)攜帶ip/Port/name/version
有了上面三個組件,才算一個完整的灰度平臺
灰度的策略
灰度必須要有灰度策略,灰度策略常見的方式有以下幾種
-
基于Request Header進(jìn)行流量切分
-
基于Cookie進(jìn)行流量切分
-
基于請求參數(shù)進(jìn)行流量切分
舉例:根據(jù)請求中攜帶的用戶uid進(jìn)行取模,灰度的范圍是百分之一,那么uid取模的范圍就是100,模是0訪問新版服務(wù),模是1~99的訪問老版服務(wù)。
灰度發(fā)布策略分為兩類,單策略和組合策略
單策略:比如按照用戶的uid、token、ip進(jìn)行取模
組合策略:多個服務(wù)同時灰度,比如我有A/B/C三個服務(wù),需要同時對A和C進(jìn)行灰度,但是B不需要灰度,這個時候就需要一個tag字段,具體實(shí)現(xiàn)在下文詳述
灰度發(fā)布具體的執(zhí)行控制
在上面的簡單灰度發(fā)布系統(tǒng)架構(gòu)中我們了解到,灰度發(fā)布服務(wù)分為上游和下游服務(wù),上游服務(wù)是具體的執(zhí)行灰度策略的程序,這個服務(wù)可以是nginx,也可以是微服務(wù)架構(gòu)中的網(wǎng)關(guān)層/業(yè)務(wù)邏輯層,下面我們就來分析一下不同的上游服務(wù),如何落地
Nginx
如果上游服務(wù)是nginx,那么就需要nginx通過Lua擴(kuò)展nginx實(shí)現(xiàn)灰度策略的配置和轉(zhuǎn)發(fā),因?yàn)閚ginx本身并不具備灰度策略的執(zhí)行
通過lua擴(kuò)展實(shí)現(xiàn)了灰度策略的執(zhí)行,但是問題又來了,nginx本身并不具備接收配置管理平臺的灰度策略,這個時候應(yīng)該怎么辦呢?
解決方案:本地部署Agent(需要自己開發(fā)),接收服務(wù)配置管理平臺下發(fā)的灰度策略,更新nginx配置,優(yōu)雅重啟Nginx服務(wù)
網(wǎng)關(guān)層/業(yè)務(wù)邏輯層/數(shù)據(jù)訪問層
只需要集成配置管理平臺客戶端SDK,接收服務(wù)配置管理平臺下發(fā)的灰度策略,在通過集成的SDK進(jìn)行灰度策略的執(zhí)行即可
灰度發(fā)布復(fù)雜場景
下面舉例兩個稍微復(fù)雜的灰度發(fā)布場景,灰度策略假設(shè)都按照uid取?;叶劝俜种坏挠脩?,看一下如何實(shí)現(xiàn)。
場景1:調(diào)用鏈上同時灰度多個服務(wù)
功能升級涉及到多個服務(wù)變動,網(wǎng)關(guān)層和數(shù)據(jù)訪問層灰度,業(yè)務(wù)邏輯層不變,這個時候應(yīng)該如何進(jìn)行灰度?
解決方案:
經(jīng)過新版本網(wǎng)關(guān)層的請求,全部打上tag T,在業(yè)務(wù)邏輯層根據(jù)tag T進(jìn)行轉(zhuǎn)發(fā), 標(biāo)記Tag T的請求全部轉(zhuǎn)發(fā)到新版數(shù)據(jù)訪問層服務(wù)上,沒有tag T的請求全部轉(zhuǎn)發(fā)到老版數(shù)據(jù)訪問層上。
場景2:涉及數(shù)據(jù)的灰度服務(wù)
涉及到數(shù)據(jù)的灰度服務(wù),一定會使用到數(shù)據(jù)庫,使用到數(shù)據(jù)庫就會涉及到你使用數(shù)據(jù)庫前后的表字段不一致,我老版本是A/B/C三個字段,新版本是A/B/C/D四個字段。這時新版的灰度,就不能往老版的數(shù)據(jù)庫進(jìn)行修改了,這個時候就需要把數(shù)據(jù)copy一份出來做這個事情了
數(shù)據(jù)庫其實(shí)并沒有灰度的概念,這個時候我們只能把數(shù)據(jù)重新拷貝一份出來進(jìn)行讀和寫,因?yàn)檫@時你的寫必須是全量的(雙寫),不能說90%的數(shù)據(jù)寫入到老版本,10%的數(shù)據(jù)寫入到新版本,因?yàn)檫@個時候你會發(fā)現(xiàn)兩個數(shù)據(jù)庫的數(shù)據(jù)都不是全量的。
離線全量復(fù)制數(shù)據(jù)的過程中一定會有數(shù)據(jù)丟失,這個時候就需要業(yè)務(wù)邏輯層寫一份數(shù)據(jù)到MQ中,等數(shù)據(jù)同步完成之后,新版的數(shù)據(jù)訪問層再將MQ的數(shù)據(jù)寫入到新版本的DB中,實(shí)現(xiàn)數(shù)據(jù)的一致性,這個也是引入MQ的主要目的。
灰度過程中需要對兩個數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行對比,觀察數(shù)據(jù)是否一致。這樣不管是灰度失敗,放棄新版DB,還是灰度成功切換到新版DB,數(shù)據(jù)都不會產(chǎn)生丟失。
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點(diǎn),不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!