【微服務從入門到精通】：（一）微服務的藍綠髮布及灰度發佈

藍綠部署

基本上，藍綠部署是一種以可預測的方式發佈應用的技術，目的是減小發布過程當中服務中止的時間。

簡單來講，你須要準備兩個相同的環境（基礎架構），在藍色環境運行當前生產環境中的應用，也就是舊版本應用，如圖中 App1 version1 、 App2 version1 、 App3 version3 。

當你想要升級 App2 到 version2 ，在藍色環境中進行操做，即部署新版本應用，並進行測試。若是測試沒問題，就能夠把負載均衡器／反向代理／路由指向藍色環境了。

隨後你須要監測新版本應用，也就是 App2 version2 是否有故障和異常。若是運行良好，就能夠刪除 App2 version1 使用的資源。若是運行出現了問題，你能夠經過負載均衡器指向快速回滾到綠色環境。

理論上聽起來很棒，但仍是要注意一些細節：

• 當你切換到藍色環境時，須要穩當處理未完成的業務和新的業務。若是你的數據庫後端沒法處理，會是一個比較麻煩的問題；

• 有可能會出現須要同時處理「微服務架構應用」和「傳統架構應用」的狀況，若是在藍綠部署中協調很差這二者，仍是有可能致使服務中止的；

• 須要提早考慮數據庫與應用部署同步遷移 /回滾的問題；

• 藍綠部署須要有基礎設施支持

• 在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險

A/B Testing

A/B 測試跟藍綠部署徹底是兩碼事。

A/B 測試是用來測試應用功能表現的方法，例如可用性、受歡迎程度、可見性等等。 A/B 測試一般用在應用的前端上，不過固然須要後端來支持。

A/B 測試與藍綠部署的區別在於， A/B 測試目的在於經過科學的實驗設計、採樣樣本表明性、流量分割與小流量測試等方式來得到具備表明性的實驗結論，並確信該結論在推廣到所有流量可信；藍綠部署的目的是安全穩定地發佈新版本應用，並在必要時回滾。

A/B 測試和藍綠部署能夠同時使用。

灰度發佈／金絲雀發佈

灰度發佈是在原有版本可用的狀況下，同時部署一個新版本應用做爲「金絲雀」（金絲雀對瓦斯極敏感，礦井工人攜帶金絲雀，以便及時發發現危險），測試新版本的性能和表現，以保障總體系統穩定的狀況下，儘早發現、調整問題。

灰度發佈／金絲雀發佈由如下幾個步驟組成：

• 準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
• 從負載均衡列表中移除掉「金絲雀」服務器。
• 升級「金絲雀」應用（排掉原有流量並進行部署）。
• 對應用進行自動化測試。
• 將「金絲雀」服務器從新添加到負載均衡列表中（連通性和健康檢查）。
• 若是「金絲雀」在線使用測試成功，升級剩餘的其餘服務器。（不然就回滾）

總結

對於雲計算來講，以上三種策略都是可用的。不難想象，經過 docker 和 kubernetes ，咱們能夠很簡單的實現藍綠部署、 A/B 測試、灰度發佈……，深度整合 Docker 和 Kubernetes ，提供給用戶包括代碼滾動上線、一鍵代碼回滾等功能和特性在內的強大的 CI/CD 體驗：）

 

注：本文非原創。參考互聯網博文，好文分享給你們