藍綠部署、金絲雀釋出（灰度釋出）、AB測試

隨著微服務架構的普及，線上服務越來越多，隨之而來的就是部署越來越頻繁；隨著網際網路行業的興旺，產品迭代的頻率也是越來越快，服務上線速度逐步提升。有上線、有部署，就有風險。有風險，就對業務有影響，然後就有了一系列減少這種風險的部署方案：藍綠部署、金絲雀釋出（灰度釋出），也有適應產品迭代頻率的AB測試。

本文主要是簡單解釋下這幾個概念，幫助自己理解，如果有錯誤，請大佬們斧正。

藍綠部署

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

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

圖片

步驟一：部署綠色叢集，這個時候是初始狀態，藍色叢集承擔全部責任，接收全部流量，等待被替換。綠色叢集剛剛部署，還沒有投入使用，流量為0，等待驗證和上線。

步驟二：藍色叢集流量不變，向綠色叢集引入流量。這個過程可以分成幾個階段完成。第一個階段，引入少量非實時流量，僅用於資料測試；第二個階段，引入全部實時流量，用於做系統驗證。

步驟三：切斷向藍色叢集引入流量，將全部流量引入綠色叢集。這個時候，綠色叢集已經承擔全部責任，接收全部流量。這個過程也可以分階段操作。第一個階段，平衡藍色和綠色叢集流量，也就是藍色和綠色叢集一同承擔職責；第二個階段，切斷藍色叢集流量，流量全部寫入綠色叢集。是否採用分階段操作，完全看升級的功能是否是破壞性的，是否可相容。

步驟四：監控系統執行，這個過程是必要的。因為沒有人能夠保證測試時100%的覆蓋的，所以新叢集可能會出現這樣那樣、或大或小的問題，如果評估需要回滾，就需要將全部流量切換到藍色叢集。也完成了版本回滾。

金絲雀釋出（灰度釋出）

金絲雀釋出，與藍綠部署不同的是，它不是非黑即白的部署方式，所以又稱為灰度釋出。它能夠緩慢的將修改推廣到一小部分使用者，驗證沒有問題後，再推廣到全部使用者，以降低生產環境引入新功能帶來的風險。

步驟一：將流量從待部署節點移出，更新該節點服務到待發布狀態，將該節點稱為金絲雀節點；

步驟二：根據不同策略，將流量引入金絲雀節點。策略可以根據情況指定，比如隨機樣本策略（隨機引入）、狗糧策略（就是內部使用者或員工先嚐鮮）、分割槽策略（不同區域使用者使用不同版本）、使用者特徵策略（這種比較複雜，需要根據使用者個人資料和特徵進行分流，類似於千人千面）；

步驟三：金絲雀節點驗證通過後，選取更多的節點稱為金絲雀節點，重複步驟一和步驟二，直到所有節點全部更新

AB測試

AB測試和上面兩種釋出方式不是一個範圍的概念，它是為了進行效果驗證的手段，其他兩種是為了實現線上平穩釋出的手段，這裡把他們放在一起說，是因為這三個概念很容易弄混。

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

這個沒有具體的步驟（也可以採用金絲雀部署的步驟，只不過不是全量更新），根據策略（這個策略可以是金絲雀分佈中的策略一致），將一部分流量引入A版本，另外一部分流量引入B版本，也可能出現CDEF版本。然後相關人員通過分析不同版本的實際效果，選出最優解。最優解可能是一個版本獲勝，取代另一個版本，也可能是催生出更多的版本，服務於使用者，還有可能是多個版本在不同區域同時提供服務。

小結

這裡總結一下：

AB測試和上面兩個不是一個範疇，不做比較。但是需要說明的一點，AB測試可以採用上面兩種部署方式的手法。

以上，希望對你有所幫助！