通用的微服務(wù)中的解決方案如下圖所示:通過配置管理平臺(tái)下發(fā)恢復(fù)發(fā)布策略給網(wǎng)關(guān)層。
我們知道,一個(gè)RPC傳輸協(xié)議的請(qǐng)求報(bào)文中,會(huì)包含很多字段:
灰度發(fā)布策略要放在定長(zhǎng)的header里組,可以根據(jù)上圖紅框標(biāo)識(shí)字段做。
如果我們要做多層的灰度發(fā)布,就需要使用數(shù)據(jù)協(xié)議中的tag。
也就是說,通過網(wǎng)關(guān)層上層的NGINX做Header的過濾來轉(zhuǎn)發(fā)流量,
那么,NGINX怎么過濾呢?
規(guī)則按優(yōu)先順序進(jìn)行如下排序:canary-by-header - > canary-by-cookie- > canary-weight
也就是說,我們通過請(qǐng)求header中的tag進(jìn)行匹配。將請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)版本的網(wǎng)關(guān)層。
在實(shí)際項(xiàng)目中,灰度發(fā)布還需要考慮數(shù)據(jù)庫。即灰度和正常流量的數(shù)據(jù),應(yīng)該都是完整的兩份。這樣當(dāng)灰度上線時(shí),舊版本才能整套下線。
如下圖所示,我們可以在新版數(shù)據(jù)訪問層前面放一個(gè)MQ。當(dāng)應(yīng)用向舊的數(shù)據(jù)訪問層寫入數(shù)據(jù)時(shí),數(shù)據(jù)也向MQ寫入一份,保證新版數(shù)據(jù)訪問層是數(shù)據(jù)是全量的。
在實(shí)際項(xiàng)目中,我不建議過度依賴代碼實(shí)現(xiàn)灰度發(fā)布。原因很簡(jiǎn)單:客戶的應(yīng)用系統(tǒng)很多,不太可能把代碼都改一遍。此外,微服務(wù)的環(huán)境本身是跨語言的,有Java,JS,python,go等。此外,可以的應(yīng)用還可能跨物理機(jī)、VM、容器,全通過該代碼是比較費(fèi)勁的。
這里,我推薦使用Ansible這種“外科手術(shù)式”、“代碼無侵入”的方式來實(shí)現(xiàn)。
通過Ansible發(fā)布NGINX的yaml配置文件(提前把配置寫好,歸類成不同的文件)、控制業(yè)務(wù)邏輯層到數(shù)據(jù)訪問層的關(guān)系。例如在SpringBoot的application.properties中可以其訪問的DB:
當(dāng)然,這就還牽扯一個(gè)Ansible操作容器云平臺(tái)的問題。
Ansible調(diào)用K8S、OpenShift有以下兩種方式。我們知道,在K8S中,通過使用不同deployment或者修改一個(gè)deployment中的image,可以發(fā)布指定版本的應(yīng)用。如果在OpenShift中,我們用ImageStream控制容器鏡像的版本,就更方便了,還能結(jié)合S2I的技術(shù),實(shí)現(xiàn)從源碼構(gòu)建應(yīng)用。
最后,在介紹一個(gè)通過Ansible做混合云應(yīng)用發(fā)布的場(chǎng)景。
也就說說,開發(fā)環(huán)境是容器云,生產(chǎn)環(huán)境有VM on AWS和容器云,需要一鍵式發(fā)布應(yīng)用。
解決的方法就是:
對(duì)于生產(chǎn)環(huán)境容器云,發(fā)布容器鏡像,通過Jenkins Pipeline部署過去。
對(duì)于生產(chǎn)環(huán)境是AWS VM,將開發(fā)環(huán)境的war包拷貝到VM的tomcat對(duì)應(yīng)目錄中。
拷貝war包到tomcat的范例如下: