微服務部署：藍綠部署、滾動部署、灰度發布、金絲雀發布
在項目迭代的過程中，不可避免需要”上線“。上線對應着部署，或者重新部署；部署對應着修改；修改則意味着風險。
目前有很多用於部署的技術，有的簡單，有的復雜；有的得停機，有的不需要停機即可完成部署。本文的目的就是將目前常用的布署方案做一個總結。
一、藍綠布署
Blue/Green Deployment（藍綠部署）
1、定義
藍綠部署是不停老版本，部署新版本然后進行測試，確認OK，將流量切到新版本，然后老版本同時也升級到新版本。
1、特點
藍綠部署無需停機，並且風險較小。
2、布署過程
第一步、部署版本1的應用（一開始的狀態）
所有外部請求的流量都打到這個版本上。
第二步、部署版本2的應用
版本2的代碼與版本1不同(新功能、Bug修復等)。
第三步、將流量從版本1切換到版本2。
第四步、如版本2測試正常，就刪除版本1正在使用的資源（例如實例），從此正式用版本2。
3、小結
從過程不難發現，在部署的過程中，我們的應用始終在線。並且，新版本上線的過程中，並沒有修改老版本的任何內容，在部署期間，老版本的狀態不受影響。這樣風險很小，並且，只要老版本的資源不被刪除，理論上，我們可以在任何時間回滾到老版本。
4、藍綠發布的注意事項
當你切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果你的數據庫后端無法處理，會是一個比較麻煩的問題；
- 可能會出現需要同時處理“微服務架構應用”和“傳統架構應用”的情況，如果在藍綠部署中協調不好這兩者，還是有可能會導致服務停止。
- 需要提前考慮數據庫與應用部署同步遷移 /回滾的問題。
- 藍綠部署需要有基礎設施支持。
- 在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。
二、Rolling update（滾動發布）
1、滾動發布定義
滾動發布：一般是取出一個或者多個服務器停止服務，執行更新，並重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。
2、特點
這種部署方式相對於藍綠部署，更加節約資源——它不需要運行兩個集群、兩倍的實例數。我們可以部分部署，例如每次只取出集群的20%進行升級。
這種方式也有很多缺點，例如：
(1) 沒有一個確定OK的環境。使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動發布，我們無法確定。
(2) 修改了現有的環境。
(3) 如果需要回滾，很困難。舉個例子，在某一次發布中，我們需要更新100個實例，每次更新10個實例，每次部署需要5分鍾。當滾動發布到第80個實例時，發現了問題，需要回滾，這個回滾卻是一個痛苦，並且漫長的過程。
(4) 有的時候，我們還可能對系統進行動態伸縮，如果部署期間，系統自動擴容/縮容了，我們還需判斷到底哪個節點使用的是哪個代碼。盡管有一些自動化的運維工具，但是依然令人心驚膽戰。
(5) 因為是逐步更新，那么我們在上線代碼的時候，就會短暫出現新老版本不一致的情況，如果對上線要求較高的場景，那么就需要考慮如何做好兼容的問題。
三、灰度發布/金絲雀部署
1、定義
灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。AB test就是一種灰度發布方式，讓一部分用戶繼續用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發布的一種方式。
注釋：礦井中的金絲雀
17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在采礦設備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標”，以便在危險狀況下緊急撤離。
灰度發布結構圖如下：
2、灰度發布／金絲雀發布由以下幾個步驟組成：
- 准備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
- 從負載均衡列表中移除掉“金絲雀”服務器。
- 升級“金絲雀”應用（排掉原有流量並進行部署）。
- 對應用進行自動化測試。
- 將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。
- 如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）
除此之外灰度發布還可以設置路由權重，動態調整不同的權重來進行新老版本的驗證。