本文主要講解幾種服務上線釋出的方式和方法，主要包括：

1. 藍綠部署
2. 金絲雀部署
3. 滾動部署
4. 紅黑部署
5. A/B 測試

0. 概述

在有關微服務、DevOps、Cloud-native、系統部署等的討論中，藍綠部署、A/B 測試、灰度釋出、滾動釋出、紅黑部署等概念經常被提到，下面就簡單的介紹下幾種部署的區別以及優劣勢。

1. 藍綠部署（Blue/Green Deployment）

過去的 10 年裡，很多公司都在使用藍綠部署（釋出）來實現熱部署，這種部署方式具有安全、可靠的特點。藍綠部署雖然算不上“ Sliver Bullet”，但確實很實用。

1.1 描述

藍綠部署是最常見的一種0 downtime部署的方式，是一種以可預測的方式釋出應用的技術，目的是減少釋出過程中服務停止的時間。

藍綠色部署是一種通過執行兩個相同的稱為 BLUE 和 GREEN 的生產環境來減少停機時間和降低風險的技術。

藍綠部署，以顏色命名，簡單的理解就是，線上有兩套叢集環境，在架構圖中，一套標記成藍色，稱為藍色叢集BLUE；一套標記為綠色，稱為綠色叢集GREEN。通過將流量引入兩個叢集，完成系統升級切換。

1.2 原理

藍綠部署原理上很簡單，就是通過冗餘來解決問題。通常生產環境需要兩組配置（藍綠配置），一組是active的生產環境的配置（綠配置），一組是inactive的配置（藍綠配置）。

使用者訪問的時候，只會讓使用者訪問active的伺服器叢集。在綠色環境（active）運行當前生產環境中的應用，也就是舊版本應用version1。

當你想要升級到version2 ，在藍色環境（inactive）中進行操作，即部署新版本應用，並進行測試。如果測試沒問題，就可以把負載均衡器／反向代理／路由指向藍色環境了。

隨後需要監測新版本應用，也就是version2 是否有故障和異常。如果執行良好，就可以刪除version1 使用的資源。

如果執行出現了問題，可以通過負載均衡器指向快速回滾到綠色環境。

1.3 部署流程

1. 部署版本1（藍色叢集）的應用（一開始的狀態），所有外部請求的流量都打到這個版本上。
2. 部署版本2（綠色叢集）的應用，版本2的程式碼與版本1不同(新功能、Bug修復等)。 這個時候是初始狀態
3. 將流量從版本1（藍色叢集）切換到版本2（綠色叢集）。 藍色叢集流量不變，向綠色叢集引入流量。這個過程可以分成幾個階段完成。第一個階段，引入少量非實時流量，僅用於資料測試；第二個階段，引入全部實時流量，用於做系統驗證。
4. 如版本2（綠色叢集）測試正常，就刪除版本1（藍色叢集）正在使用的資源（例如例項），從此正式用版本2（綠色叢集）。 切斷向藍色叢集引入流量，將全部流量引入綠色叢集。這個時候，綠色叢集已經承擔全部責任，接收全部流量。這個過程也可以分階段操作。第一個階段，平衡藍色和綠色叢集流量，也就是藍色和綠色叢集一同承擔職責；第二個階段，切斷藍色叢集流量，流量全部寫入綠色叢集。是否採用分階段操作，完全看升級的功能是否是破壞性的，是否可相容。
5. 監控系統執行，這個過程是必要的。因為沒有人能夠保證測試時100%的覆蓋的，所以新叢集可能會出現這樣那樣、或大或小的問題，如果評估需要回滾，就需要將全部流量切換到藍色叢集。也完成了版本回滾。

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

1.4 優點

藍綠部署的優點： 這種方式的好處在你可以始終很放心的去部署inactive環境，如果出錯並不影響生產環境的服務，如果切換後出現問題，也可以在非常短的時間內把再做一次切換，就完成了回滾。

而且同時線上的只有一個版本。藍綠部署無需停機，並且風險較小。

1.5 缺點

藍綠部署的弱點： 使用藍綠部署需要注意的一些細節包括：

1. 當切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果資料庫後端無法處理，會是一個比較麻煩的問題。
2. 有可能會出現需要同時處理“微服務架構應用”和“傳統架構應用”的情況，如果在藍綠部署中協調不好這兩者，還是有可能導致服務停止。
3. 需要提前考慮資料庫與應用部署同步遷移/回滾的問題。
4. 藍綠部署需要有基礎設施支援。
5. 在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。
6. 另外，這種方式不好的地方還在於冗餘產生的額外維護、配置的成本，以及伺服器本身執行的開銷。

1.6 適用場景

1. 不停止老版本，額外搞一套新版本，等測試發現新版本OK後，刪除老版本。
2. 藍綠髮布是一種用於升級與更新的釋出策略，部署的最小維度是容器，而釋出的最小維度是應用。
3. 藍綠髮布對於增量升級有比較好的支援，但是對於涉及資料表結構變更等等不可逆轉的升級，並不完全合適用藍綠髮布來實現，需要結合一些業務的邏輯以及資料遷移與回滾的策略才可以完全滿足需求。

2.灰度釋出／金絲雀釋出

2.1 概述

金絲雀釋出，與藍綠部署不同的是，它不是非黑即白的部署方式，所以又稱為灰度釋出。

灰度釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。它能夠緩慢的將修改推廣到一小部分使用者，驗證沒有問題後，再推廣到全部使用者，以降低生產環境引入新功能帶來的風險。

灰度釋出是增量釋出的一種型別，灰度釋出是在原有版本可用的情況下，同時部署一個新版本應用作為“金絲雀”（金絲雀對瓦斯極敏感，礦井工人攜帶金絲雀，以便及時發發現危險），測試新版本的效能和表現，以保障整體系統穩定的情況下，儘早發現、調整問題。

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

2.2 部署流程

1. 準備好部署各個階段的工件，包括：構建工件，測試指令碼，配置檔案和部署清單檔案。
2. 從負載均衡列表中移除掉“金絲雀”伺服器：將流量從待部署節點移出，更新該節點服務到待發布狀態，將該節點稱為金絲雀節點。
3. 升級“金絲雀”應用（排掉原有流量並進行部署）：根據不同策略，將流量引入金絲雀節點。策略可以根據情況指定，比如隨機樣本策略（隨機引入）、狗糧策略（就是內部使用者或員工先嚐鮮）、分割槽策略（不同區域使用者使用不同版本）、使用者特徵策略（這種比較複雜，需要根據使用者個人資料和特徵進行分流，類似於千人千面）。
4. 對應用進行自動化測試。
5. 將“金絲雀”伺服器重新新增到負載均衡列表中（連通性和健康檢查）。
6. 如果“金絲雀”線上使用測試成功，升級剩餘的其他伺服器。（否則就回滾） 灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。

2.3 優點

小步快跑，快速迭代

2.4 缺點

只能適用於相容迭代的方式，如果是大版本不相容的場景，就沒辦法使用這種方式了

2.3 適用場景

灰度釋出/金絲雀部署適用的場景：

1. 不停止老版本，額外搞一套新版本，不同版本應用共存。
2. 灰度釋出中，常常按照使用者設定路由權重，例如90%的使用者維持使用老版本，10%的使用者嚐鮮新版本。
3. 經常與A/B測試一起使用，用於測試選擇多種方案。AB test就是一種灰度釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。

3. 滾動釋出（rolling update）

3.1 概述

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

3.2 優點

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

3.3 缺點

這種方式也有很多缺點

1. 沒有一個確定OK的環境。使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動釋出，我們無法確定。
2. 修改了現有的環境。
3. 如果需要回滾，很困難。舉個例子，在某一次釋出中，我們需要更新100個例項，每次更新10個例項，每次部署需要5分鐘。當滾動釋出到第80個例項時，發現了問題，需要回滾。此時，脾氣不好的程式猿很可能想掀桌子，因為回滾是一個痛苦，並且漫長的過程。
4. 有的時候，我們還可能對系統進行動態伸縮，如果部署期間，系統自動擴容/縮容了，我們還需判斷到底哪個節點使用的是哪個程式碼。儘管有一些自動化的運維工具，但是依然令人心驚膽戰。並不是說滾動釋出不好，滾動釋出也有它非常合適的場景。

4. 紅黑部署（Red-Black Deployment）

4.1 概述

紅黑部署是 Netflix 採用的部署手段，Netflix的主要基礎設施是在AWS上，所以它利用AWS的特性，在部署新的版本時，通過AutoScaling Group用包含新版本應用的AMI的LaunchConfiguration建立新的伺服器。

測試不通過，找到問題原因後，直接幹掉新生成的伺服器以及Autoscaling Group就可以；測試通過，則將ELB指向新的伺服器叢集，然後銷燬掉舊的伺服器叢集以及AutoScaling Group。

4.2 優點

紅黑部署的好處是服務始終線上，同時採用不可變部署的方式，也不像藍綠部署一樣得保持冗餘的服務始終線上。

5. A/B 測試（A/B Testing）

5.1 概述

A/B 測試是用來測試應用功能表現的方法，例如可用性、受歡迎程度、可見性等等。 藍綠部署的目的是安全穩定地釋出新版本應用，並在必要時回滾。

A/B 測試與藍綠部署的區別在於， A/B 測試目的在於通過科學的實驗設計、取樣樣本代表性、流量分割與小流量測試等方式來獲得具有代表性的實驗結論，並確信該結論在推廣到全部流量可信。

AB測試和上面的幾種釋出方式不是一個範圍的概念，它是為了進行效果驗證的手段，其他兩種是為了實現線上平穩釋出的手段。

AB測試是線上同時執行多個不同版本的服務，這些服務更多的是使用者側的體驗不同，比如頁面佈局、按鈕顏色，互動方式等，通常底層業務邏輯還是一樣的，也就是通常說的換湯不換藥。

A/B 測試和藍綠部署/金絲雀部署等可以同時使用。

這個沒有具體的步驟（也可以採用金絲雀部署的步驟，只不過不是全量更新），根據策略（這個策略可以是金絲雀分佈中的策略一致），將一部分流量引入A版本，另外一部分流量引入B版本，也可能出現CDEF版本。

然後相關人員通過分析不同版本的實際效果，選出最優解。最優解可能是一個版本獲勝，取代另一個版本，也可能是催生出更多的版本，服務於使用者，還有可能是多個版本在不同區域同時提供服務。

6. 參考資料

• 藍綠部署、紅黑部署、AB測試、灰度釋出、金絲雀釋出、滾動釋出的概念與區別
• 藍綠部署、金絲雀釋出（灰度釋出）、AB測試