在專案迭代的過程中，不可避免需要”上線“。上線對應著部署，或者重新部署；部署對應著修改；修改則意味著風險。

目前有很多用於部署的技術，有的簡單，有的複雜；有的得停機，有的不需要停機即可完成部署。本文的目的就是將目前常用的佈署方案做一個總結。

一、藍綠佈署

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、灰度釋出／金絲雀釋出由以下幾個步驟組成：

準備好部署各個階段的工件，包括：構建工件，測試指令碼，配置檔案和部署清單檔案。

從負載均衡列表中移除掉“金絲雀”伺服器。

升級“金絲雀”應用（排掉原有流量並進行部署）。

對應用進行自動化測試。

將“金絲雀”伺服器重新新增到負載均衡列表中（連通性和健康檢查）。

如果“金絲雀”線上使用測試成功，升級剩餘的其他伺服器。（否則就回滾）

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