通用的微服務中的解決方案如下圖所示：通過配置管理平臺下發(fā)恢復發(fā)布策略給網(wǎng)關層。

我們知道，一個RPC傳輸協(xié)議的請求報文中，會包含很多字段：

灰度發(fā)布策略要放在定長的header里組，可以根據(jù)上圖紅框標識字段做。

如果我們要做多層的灰度發(fā)布，就需要使用數(shù)據(jù)協(xié)議中的tag。

也就是說，通過網(wǎng)關層上層的NGINX做Header的過濾來轉發(fā)流量，

那么，NGINX怎么過濾呢？

規(guī)則按優(yōu)先順序進行如下排序：canary-by-header - > canary-by-cookie- > canary-weight

也就是說，我們通過請求header中的tag進行匹配。將請求轉發(fā)到對應版本的網(wǎng)關層。

在實際項目中，灰度發(fā)布還需要考慮數(shù)據(jù)庫。即灰度和正常流量的數(shù)據(jù)，應該都是完整的兩份。這樣當灰度上線時，舊版本才能整套下線。

如下圖所示，我們可以在新版數(shù)據(jù)訪問層前面放一個MQ。當應用向舊的數(shù)據(jù)訪問層寫入數(shù)據(jù)時，數(shù)據(jù)也向MQ寫入一份，保證新版數(shù)據(jù)訪問層是數(shù)據(jù)是全量的。

在實際項目中，我不建議過度依賴代碼實現(xiàn)灰度發(fā)布。原因很簡單：客戶的應用系統(tǒng)很多，不太可能把代碼都改一遍。此外，微服務的環(huán)境本身是跨語言的，有Java，JS，python，go等。此外，可以的應用還可能跨物理機、VM、容器，全通過該代碼是比較費勁的。

這里，我推薦使用Ansible這種“外科手術式”、“代碼無侵入”的方式來實現(xiàn)。

通過Ansible發(fā)布NGINX的yaml配置文件（提前把配置寫好，歸類成不同的文件）、控制業(yè)務邏輯層到數(shù)據(jù)訪問層的關系。例如在SpringBoot的application.properties中可以其訪問的DB：

當然，這就還牽扯一個Ansible操作容器云平臺的問題。

Ansible調(diào)用K8S、OpenShift有以下兩種方式。我們知道，在K8S中，通過使用不同deployment或者修改一個deployment中的image，可以發(fā)布指定版本的應用。如果在OpenShift中，我們用ImageStream控制容器鏡像的版本，就更方便了，還能結合S2I的技術，實現(xiàn)從源碼構建應用。

最后，在介紹一個通過Ansible做混合云應用發(fā)布的場景。

也就說說，開發(fā)環(huán)境是容器云，生產(chǎn)環(huán)境有VM on AWS和容器云，需要一鍵式發(fā)布應用。

解決的方法就是：

對于生產(chǎn)環(huán)境容器云，發(fā)布容器鏡像，通過Jenkins Pipeline部署過去。

對于生產(chǎn)環(huán)境是AWS VM，將開發(fā)環(huán)境的war包拷貝到VM的tomcat對應目錄中。

拷貝war包到tomcat的范例如下：