特點：
藍綠部署無需停機，並且風險較小。

部署過程

部署版本 1 的應用（初始的狀態）
所有外部請求的流量都打到這個版本上。

部署版本 2 的應用
版本 2 的代碼與版本 1 不同(新功能、Bug修復等)。

將流量從版本 1 切換到版本 2。

如版本 2 測試正常，就刪除版本 1 正在使用的資源（例如實例），從此正式用版本 2。
小結

從過程不難發現，在部署的過程中，我們的應用始終在線。並且新版本上線的過程中，並沒有修改老版本的任何內容，在部署期間，老版本的狀態不受影響，這樣風險很小。並且只要老版本的資源不被刪除，理論上，我們可以在任何時間回滾到老版本。

藍綠發布的註意事項

當你切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果你的數據庫後端無法處理，會是一個比較麻煩的問題。

可能會出現需要同時處理微服務架構應用和傳統架構應用的情況，如果在藍綠部署中協調不好這兩者，還是有可能會導致服務停止。
需要提前考慮數據庫與應用部署同步遷移/回滾的問題。
藍綠部署需要有基礎設施支持。
在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。

優勢和不足

優勢
升級切換和回退速度非常快。

不足
切換是全量的，如果 V2 版本有問題，則對用戶體驗有直接影響。
需要兩倍機器資源。

適用場合

對用戶體驗有一定容忍度的場景。
機器資源有富余或者可以按需分配（AWS 雲，或自建容器雲）

灰度發布

定義

灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。AB Test 就是一種灰度發布方式，讓一部分用戶繼續用 A，一部分用戶開始用 B，如果用戶對 B 沒有什麽反對意見，那麽逐步擴大範圍，把所有用戶都遷移到 B 上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。

灰度發布結構圖

A/B Testing

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

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

3. 金絲雀發布

我們平常所說的金絲雀部署也是灰度發布的一種方式，在原有版本可用的情況下，同時部署一個新版本應用作為「金絲雀」服務器來測試新版本的性能和表現，以保障整體系統穩定的情況下，盡早發現、調整問題。

礦井中的金絲雀：17 世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在采礦設備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為瓦斯檢測指標，以便在危險狀況下緊急撤離。

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

準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
從負載均衡列表中移除掉「金絲雀」服務器。
升級「金絲雀」應用（排掉原有流量並進行部署）。
對應用進行自動化測試。
將「金絲雀」服務器重新添加到負載均衡列表中（連通性和健康檢查）。
如果「金絲雀」在線使用測試成功，升級剩余的其他服務器（否則就回滾）。
除此之外灰度發布還可以設置路由權重，動態調整不同的權重來進行新老版本的驗證。

4. 優勢和不足

優勢
用戶體驗影響小，灰度發布過程出現問題只影響少量用戶。

不足
發布自動化程度不夠，發布期間可引發服務中斷。

滾動發布

在金絲雀發布基礎上的進一步優化改進，是一種自動化程度較高的發布方式，用戶體驗比較平滑，是目前成熟型技術組織所采用的主流發布方式。

1. 定義

滾動發布：一般是取出一個或者多個服務器停止服務，執行更新，並重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。

2. 特點

這種部署方式相對於藍綠部署，更加節約資源——它不需要運行兩個集群、兩倍的實例數。我們可以部分部署，例如每次只取出集群的 20% 進行升級。

3. 部署過程

滾動式發布一般先發 1 臺，或者一個小比例，如 2% 服務器，主要做流量驗證用，類似金絲雀 (Canary) 測試。
滾動式發布需要比較復雜的發布工具和智能 LB，支持平滑的版本替換和流量拉入拉出。
每次發布時，先將老版本 V1 流量從 LB 上摘除，然後清除老版本，發新版本 V2，再將 LB 流量接入新版本。這樣可以盡量保證用戶體驗不受影響。
一次滾動式發布一般由若幹個發布批次組成，每批的數量一般是可以配置的（可以通過發布模板定義）。例如第一批 1 臺（金絲雀），第二批 10%，第三批 50%，第四批 100%。每個批次之間留觀察間隔，通過手工驗證或監控反饋確保沒有問題再發下一批次，所以總體上滾動式發布過程是比較緩慢的 (其中金絲雀的時間一般會比後續批次更長，比如金絲雀 10 分鐘，後續間隔 2 分鐘)。
回退是發布的逆過程，將新版本流量從 LB 上摘除，清除新版本，發老版本，再將 LB 流量接入老版本。和發布過程一樣，回退過程一般也比較慢的。

4. 優勢和不足

優勢
用戶體驗影響小，體驗較平滑。

不足
發布和回退時間比較緩慢。
發布工具比較復雜，LB 需要平滑的流量摘除和拉入能力。

上述都是偏傳統的發布方式，能覆蓋大部分應用發布場景。針對一些關鍵新功能的上線發布，或者一些特定的場景，還有一些特殊的發布方式。

功能開關發布

1. 部署過程

功能開關發布需要一個配置中心或者開關中心這樣的服務支持，例如攜程的 Apollo 配置中心或者開源的 FF4J，這些都支持開關發布。業界還有專門的功能開關 SaaS 服務，例如 LaunchDarkly。通過配置中心，運維或研發人員可以在運行期動態配置功能開關的值。當然，功能開關發布只是配置中心的一種使用場景，配置中心還能支持其它很多動態配置場景。
功能開關服務一般提供客戶端 SDK，方便開發人員集成。在運行期，客戶端 SDK 會同步最新的開關值，技術實現有推方式 (push)，也有拉方式 (pull)，或者推拉結合方式。
新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中，新功能隱藏在開關後面，如果開關沒有打開，則走老代碼邏輯，如果開關打開，則走新代碼邏輯。技術實現上可以理解為一個簡單的 if/else 邏輯。
應用上線後，開關先不打開，然後運維或研發人員通過開關中心打開新功能，經過流量驗證新功能沒有問題，則發布完成；如果有問題，則隨時可以通過開關中心切回老功能邏輯。

2. 優勢和不足

優勢
升級切換和回退速度非常快。
相對於復雜的發布工具，實施比較簡單，成本相對低廉。
研發能夠靈活定制發布邏輯，支持 DevOps 自助發布。

不足
切換是全量的，如果 V2 版本有問題，則對用戶體驗有直接影響。
對代碼有侵入，代碼邏輯會變復雜，需要定期清理老版本邏輯，維護成本變高。

其他發布下次記錄
系統運維工程師 李超

運維發布系統詳談