一文明白藍綠部署滾動部署灰度發布金絲雀發布

說明

藍綠部署、a/b測試、金絲雀發布，以及灰度發布、流量切分等，經常被混為一談，影響溝通效率。根本原因是這些名詞經常出現，人們耳熟能詳能夠熟練地談起，對這些術語的理解卻沒有達成一致。

下面是從blue-green deployments, a/b testing, and canary releases中整理出來的定義。

藍綠部署

在、藍綠部署的目的是減少發布時的中斷時間、能夠快速撤回發布。

最初，沒有任何系統，沒有藍綠之分。

然後，第一套系統開發完成，直接上線，這個過程只有乙個系統，也沒有藍綠之分。

用來做發布前測試，測試過程中發現任何問題，可以直接在藍色系統上修改，不干擾使用者正在使用的系統。（注意，兩套系統沒有耦合的時候才能百分百保證不干擾）

藍色系統經過反覆的測試、修改、驗證，確定達到上線標準之後，直接將使用者切換到藍色系統：

切換後的一段時間內，依舊是藍綠兩套系統並存，但是使用者訪問的已經是藍色系統。這段時間內觀察藍色系統（新系統）工作狀態，如果出現問題，直接切換回綠色系統。

當確信對外提供服務的藍色系統工作正常，不對外提供服務的綠色系統已經不再需要的時候，藍色系統正式成為對外提供服務系統，成為新的綠色系統。原先的綠色系統可以銷毀，將資源釋放出來，用於部署下乙個藍色系統。

藍綠部署只是上線策略中的一種，它不是可以應對所有情況的萬能方案。藍綠部署能夠簡單快捷實施的前提假設是目標系統是非常內聚的，如果目標系統相當複雜，那麼如何切換、兩套系統的資料是否需要以及如何同步等，都需要仔細考慮。

bluegreendeployment中給出的一張圖特別形象：

金絲雀發布

金絲雀發布（canary）也是一種發布策略，和國內常說的灰度發布是同一類策略。

藍綠部署是準備兩套系統，在兩套系統之間進行切換，金絲雀策略是只有一套系統，逐漸替換這套系統。

譬如說，目標系統是一組無狀態的web伺服器，但是數量非常多，假設有一萬台。

這時候，藍綠部署就不能用了，因為你不可能申請一萬台伺服器專門用來部署藍色系統（在藍綠部署的定義中，藍色的系統要能夠承接所有訪問）。

可以想到的乙個方法是：

只準備幾台伺服器，在上面部署新版本的系統並測試驗證。測試通過之後，擔心出現意外，還不敢立即更新所有的伺服器。先將線上的一萬台伺服器中的10臺更新為最新的系統，然後觀察驗證。確認沒有異常之後，再將剩餘的所有伺服器更新。

這個方法就是金絲雀發布。

實際操作中還可以做更多控制，譬如說，給最初更新的10臺伺服器設定較低的權重、控制傳送給這10臺伺服器的請求數，然後逐漸提高權重、增加請求數。

這個控制叫做「流量切分」，既可以用於金絲雀發布，也可以用於後面的a/b測試。

藍綠部署和金絲雀發布是兩種發布策略，都不是萬能的。有時候兩者都可以使用，有時候只能用其中一種。

上面的例子中可以用金絲雀，不能用藍綠，那麼什麼時候可以用藍綠，不能用金絲雀呢？整個系統只有一台伺服器的時候。

a/b測試

首先需要明確的是，a/b測試和藍綠部署以及金絲雀，完全是兩回事。

藍綠部署和金絲雀是發布策略，目標是確保新上線的系統穩定，關注的是新系統的bug、隱患。

a/b測試是效果測試，同一時間有多個版本的服務對外服務，這些服務都是經過足夠測試，達到了上線標準的服務，有差異但是沒有新舊之分（它們上線時可能採用了藍綠部署的方式）。

a/b測試關注的是不同版本的服務的實際效果，譬如說轉化率、訂單情況等。

a/b測試時，線上同時執行多個版本的服務，這些服務通常會有一些體驗上的差異，譬如說頁面樣式、顏色、操作流程不同。相關人員通過分析各個版本服務的實際效果，選出效果最好的版本。

一文明白藍綠部署 滾動部署 灰度發布 金絲雀發布