第四步、如版本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上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發布的一種方式。

注釋：礦井中的金絲雀

灰度發布結構圖如下：

2、灰度發布／金絲雀發布由以下幾個步驟組成：

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

除此之外灰度發布還可以設置路由權重，動態調整不同的權重來進行新老版本的驗證。

作者：小程故事多

鏈接：https://www.jianshu.com/p/022685baba7d

來源：簡書

著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

推薦閱讀：