來源 | https://www.jianshu.com/p/0df88fe4a1e3

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

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

藍綠部署

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

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

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

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

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

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

金絲雀發佈（灰度發佈）

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

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

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

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

AB 測試

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

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

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

最後

這裏總結一下：

2zr8iZ

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

參考：Using Blue-Green Deployment to Reduce Downtime and Risk

Blue Green Deployment

Blue-green Deployments, A/B Testing, and Canary Releases

Canary Release

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1FfhGNRQH03VScIghQblLQ