随着微服務架構的普及，線上服務越來越多，随之而來的就是部署越來越頻繁；随着網際網路行業的興旺，産品疊代的頻率也是越來越快，服務上線速度逐漸提升。有上線、有部署，就有風險。有風險，就對業務有影響，然後就有了一系列減少這種風險的部署方案：藍綠部署、金絲雀釋出（灰階釋出），也有适應産品疊代頻率的AB測試。
本文主要是簡單解釋下這幾個概念，幫助自己了解，如果有錯誤，請大佬們斧正。
藍綠部署
藍綠色部署是一種通過運作兩個相同的稱為 BLUE 和 GREEN 的生産環境來減少停機時間和降低風險的技術。
藍綠部署，以顔色命名，簡單的了解就是，線上有兩套叢集環境，在架構圖中，一套标記成藍色，稱為藍色叢集BLUE；一套标記為綠色，稱為綠色叢集GREEN。通過将流量引入兩個叢集，完成系統更新切換。
步驟一：部署綠色叢集，這個時候是初始狀态，藍色叢集承擔全部責任，接收全部流量，等待被替換。綠色叢集剛剛部署，還沒有投入使用，流量為0，等待驗證和上線。
步驟二：藍色叢集流量不變，向綠色叢集引入流量。這個過程可以分成幾個階段完成。第一個階段，引入少量非實時流量，僅用于資料測試；第二個階段，引入全部實時流量，用于做系統驗證。
步驟三：切斷向藍色叢集引入流量，将全部流量引入綠色叢集。這個時候，綠色叢集已經承擔全部責任，接收全部流量。這個過程也可以分階段操作。第一個階段，平衡藍色和綠色叢集流量，也就是藍色和綠色叢集一同承擔職責；第二個階段，切斷藍色叢集流量，流量全部寫入綠色叢集。是否采用分階段操作，完全看更新的功能是否是破壞性的，是否可相容。
步驟四：監控系統運作，這個過程是必要的。因為沒有人能夠保證測試時100%的覆寫的，是以新叢集可能會出現這樣那樣、或大或小的問題，如果評估需要復原，就需要将全部流量切換到藍色叢集。也完成了版本復原。
金絲雀釋出（灰階釋出）
金絲雀釋出，與藍綠部署不同的是，它不是非黑即白的部署方式，是以又稱為灰階釋出。它能夠緩慢的将修改推廣到一小部分使用者，驗證沒有問題後，再推廣到全部使用者，以降低生産環境引入新功能帶來的風險。
步驟一：将流量從待部署節點移出，更新該節點服務到待釋出狀态，将該節點稱為金絲雀節點；
步驟二：根據不同政策，将流量引入金絲雀節點。政策可以根據情況指定，比如随機樣本政策（随機引入）、狗糧政策（就是内部使用者或員工先嘗鮮）、分區政策（不同區域使用者使用不同版本）、使用者特征政策（這種比較複雜，需要根據使用者個人資料和特征進行分流，類似于千人千面）；
步驟三：金絲雀節點驗證通過後，選取更多的節點稱為金絲雀節點，重複步驟一和步驟二，直到所有節點全部更新
AB測試
AB測試和上面兩種釋出方式不是一個範圍的概念，它是為了進行效果驗證的手段，其他兩種是為了實作線上平穩釋出的手段，這裡把他們放在一起說，是因為這三個概念很容易弄混。
AB測試是線上同時運作多個不同版本的服務，這些服務更多的是使用者側的體驗不同，比如頁面布局、按鈕顔色，互動方式等，通常底層業務邏輯還是一樣的，也就是通常說的換湯不換藥。
這個沒有具體的步驟（也可以采用金絲雀部署的步驟，隻不過不是全量更新），根據政策（這個政策可以是金絲雀分布中的政策一緻），将一部分流量引入A版本，另外一部分流量引入B版本，也可能出現CDEF版本。然後相關人員通過分析不同版本的實際效果，選出最優解。最優解可能是一個版本獲勝，取代另一個版本，也可能是催生出更多的版本，服務于使用者，還有可能是多個版本在不同區域同時提供服務。
最後
這裡總結一下：
參考：
Using Blue-Green Deployment to Reduce Downtime and Risk
Blue Green Deployment
Blue-green Deployments, A/B Testing, and Canary Releases
Canary Release