藍綠發布，紅黑發布和灰度發布是什麼

我們先來看看藍綠部署（blue-green deployment）、紅黑部署（red-black deployment）和灰度發布（gray release ，或 dark launch）的定義和流程吧。

藍綠部署，是採用兩個分開的集群對軟體版本進行公升級的一種方式。它的部署模型中包括乙個藍色集群 a 和乙個綠色集群 b，在沒有新版本上線的情況下，兩個集群上執行的版本是一致的，同時對外提供服務。

系統公升級時，藍綠部署的流程是：

首先，從負載均衡器列表中刪除集群 a，讓集群 b 單獨提供服務。然後，在集群 a 上部署新版本。

接下來，集群 a 公升級完畢後，把負載均衡列表全部指向 a，並刪除集群 b，由 a 單獨提供服務。

在集群 b 上部署完新版本後，再把它新增回負載均衡列表中。

這樣，我們就完成了兩個集群上所有機器的版本公升級。

與藍綠部署類似，紅黑部署也是通過兩個集群完成軟體版本的公升級。

當前提供服務的所有機器都執行在紅色集群 a 中，當需要發布新版本的時候，具體流程是這樣的：

先在雲上申請乙個黑色集群 b，在 b 上部署新版本的服務；等到 b 公升級完成後，我們一次性地把負載均衡全部指向 b；

把 a 集群從負載均衡列表中刪除，並釋放集群 a 中所有機器。

這樣就完成了乙個版本的公升級。

可以看到，與藍綠部署相比，紅黑部署只不過是充分利用了雲計算的彈性伸縮優勢，從而獲得了兩個收益：一是，簡化了流程；二是，避免了在公升級的過程中，由於只有一半的伺服器提供服務，而可能導致的系統過載問題。

至於這兩種部署方式名字中的「藍綠」「紅黑」，只是為了方便討論，給不同的集群取的名字而已，通過不同顏色表明它們會在系統公升級時執行不同的版本。

灰度發布，也被叫作金絲雀發布。與藍綠部署、紅黑部署不同的是，灰度發布屬於增量發布方法。也就是說，服務公升級的過程中，新舊版本會同時為使用者提供服務。

灰度發布的具體流程是這樣的：在集群的一小部分機器上部署新版本，給一部分使用者使用，以測試新版本的功能和效能；確認沒有問題之後，再對整個集群進行公升級。簡單地說，灰度發布就是把部署好的服務分批次、逐步暴露給越來越多的使用者，直到最終完全上線。

之所以叫作灰度發布，是因為它介於黑與白之間，並不是版本之間的直接切換，而是乙個平滑過渡的過程。

之所以又被叫作金絲雀發布，是因為金絲雀對瓦斯極其敏感，17 世紀時英國礦井工人會攜帶金絲雀下井，以便及時發現危險。這就與灰色發布過程中，先發布給一部分使用者來測試相似，因而得名。

究其根本，這些部署、發布方法，是為了解決頻繁發布的生產模式帶來的兩個問題：

減少發布過程中新舊服務切換造成的服務停止時間。藍綠部署和紅黑部署都能實現無宕機時間部署（0 downtime deployment）。

控制新版本發布因為質量問題帶來的風險。灰度發布就是乙個例子。

實現這兩個目標的基本原則，是把服務上線過程拆分為部署、發布和發布後 3 個階段，並

充分利用這 3 個階段的特點來提高服務上線的效率、質量和安全性。

這 3 個階段的詳細定義和特點分別是：

部署（deploy），指的是我們把乙個**包拷貝到伺服器上執行，但並不把它暴露給用戶，也就是並不給使用者提供服務。這個階段比較耗時，但因為還沒有面向使用者，所以風險很小。

發布（release），是把部署好的服務暴露給使用者的過程，也就是開始真正上線服務使用者了。這個過程可以通過負載均衡的切換很快實現，但風險很大，一旦出現問題損失就會比較大。

發布後（post-release），指的是服務完全上線以後的階段。因為產品已經完全上線，我們的主要工作不再是預防，而是變成了監控和降低損失。

以紅黑部署為例，從開始在新生成的集群 b 上部署新的版本，到線上的流量通過負載均衡指向 b 之前，是處於部署階段；而負載均衡從 a 指向 b 的過程，就是發布階段；等到負載均衡完全指向 b 之後，就進入了發布後階段。

部署、發布、上線這幾個名詞，其實區分不太明顯，我們平時在討論服務部署上線時，也經常會混用。在這裡，我之所以要和你明確區分這幾個階段，是因為我們可以針對每個階段的特點來實現兩個目標：

提高上線產品的效率，也就是減少發布過程中新舊服務切換造成的服務停止時間。提高上線產品的安全性，也就是控制新版本引入的質量問題。

關於提高上線產品的效率，實踐主要有兩個：一是利用負載均衡切換線上流量，二是使用功能開關切換線上流量。這兩種方法都比較簡單。

而提高上線產品的安全性，相對來說就比較複雜了，但又很重要。因為在敏捷、持續交付等開發模式愈發流行的今天，產品的研發節奏越來越快，我們必須在上線過程中，在生產環境上進行更多的測試，以保證產品質量。