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

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

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

如果我們要做多層的灰度發布，就需要使用數據協議中的tag。

也就是說，通過網關層上層的NGINX做Header的過濾來轉發流量，

那么，NGINX怎么過濾呢？

規則按優先順序進行如下排序：canary-by-header - > canary-by-cookie- > canary-weight

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

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

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

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

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

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

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

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

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

也就說說，開發環境是容器云，生產環境有VM on AWS和容器云，需要一鍵式發布應用。

解決的方法就是：

對于生產環境容器云，發布容器鏡像，通過Jenkins Pipeline部署過去。

對于生產環境是AWS VM，將開發環境的war包拷貝到VM的tomcat對應目錄中。

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