目錄
說明
藍綠部署、A/B測試、金絲雀發佈，以及灰度發佈、流量切分等，經常被混爲一談，影響溝通效率。 根本原因是這些名詞經常出現，人們耳熟能詳能夠熟練地談起，對這些術語的理解卻沒有達成一致。
下面是從Blue-green Deployments, A/B Testing, and Canary Releases中整理出來的定義。
藍綠部署
藍綠部署的目的是減少發佈時的中斷時間、能夠快速撤回發佈。
It’s basically a technique for releasing your application in a predictable manner with an goal of reducing any downtime associated with a release. It’s a quick way to prime your app before releasing, and also quickly roll back if you find issues.
藍綠部署中，一共有兩套系統：一套是正在提供服務系統，標記爲“綠色”；另一套是準備發佈的系統，標記爲“藍色”。兩套系統都是功能完善的，並且正在運行的系統，只是系統版本和對外服務情況不同。
最初，沒有任何系統，沒有藍綠之分。
然後，第一套系統開發完成，直接上線，這個過程只有一個系統，也沒有藍綠之分。
後來，開發了新版本，要用新版本替換線上的舊版本，在線上的系統之外，搭建了一個使用新版本代碼的全新系統。 這時候，一共有兩套系統在運行，正在對外提供服務的老系統是綠色系統，新部署的系統是藍色系統。
藍色系統不對外提供服務，用來做啥？
用來做發佈前測試，測試過程中發現任何問題，可以直接在藍色系統上修改，不干擾用戶正在使用的系統。（注意，兩套系統沒有耦合的時候才能百分百保證不干擾）
藍色系統經過反覆的測試、修改、驗證，確定達到上線標準之後，直接將用戶切換到藍色系統：
切換後的一段時間內，依舊是藍綠兩套系統並存，但是用戶訪問的已經是藍色系統。這段時間內觀察藍色系統（新系統）工作狀態，如果出現問題，直接切換回綠色系統。
當確信對外提供服務的藍色系統工作正常，不對外提供服務的綠色系統已經不再需要的時候，藍色系統正式成爲對外提供服務系統，成爲新的綠色系統。 原先的綠色系統可以銷燬，將資源釋放出來，用於部署下一個藍色系統。
藍綠部署只是上線策略中的一種，它不是可以應對所有情況的萬能方案。 藍綠部署能夠簡單快捷實施的前提假設是目標系統是非常內聚的，如果目標系統相當複雜，那麼如何切換、兩套系統的數據是否需要以及如何同步等，都需要仔細考慮。
BlueGreenDeployment中給出的一張圖特別形象：
金絲雀發佈
金絲雀發佈（Canary）也是一種發佈策略，和國內常說的灰度發佈是同一類策略。
藍綠部署是準備兩套系統，在兩套系統之間進行切換，金絲雀策略是隻有一套系統，逐漸替換這套系統。
譬如說，目標系統是一組無狀態的Web服務器，但是數量非常多，假設有一萬臺。
這時候，藍綠部署就不能用了，因爲你不可能申請一萬臺服務器專門用來部署藍色系統（在藍綠部署的定義中，藍色的系統要能夠承接所有訪問）。
可以想到的一個方法是：
只准備幾臺服務器，在上面部署新版本的系統並測試驗證。測試通過之後，擔心出現意外，還不敢立即更新所有的服務器。 先將線上的一萬臺服務器中的10臺更新爲最新的系統，然後觀察驗證。確認沒有異常之後，再將剩餘的所有服務器更新。
這個方法就是金絲雀發佈。
實際操作中還可以做更多控制，譬如說，給最初更新的10臺服務器設置較低的權重、控制發送給這10臺服務器的請求數，然後逐漸提高權重、增加請求數。
這個控制叫做“流量切分”，既可以用於金絲雀發佈，也可以用於後面的A/B測試。
藍綠部署和金絲雀發佈是兩種發佈策略，都不是萬能的。有時候兩者都可以使用，有時候只能用其中一種。
上面的例子中可以用金絲雀，不能用藍綠，那麼什麼時候可以用藍綠，不能用金絲雀呢？整個系統只有一臺服務器的時候。
A/B測試
首先需要明確的是，A/B測試和藍綠部署以及金絲雀，完全是兩回事。
藍綠部署和金絲雀是發佈策略，目標是確保新上線的系統穩定，關注的是新系統的BUG、隱患。
A/B測試是效果測試，同一時間有多個版本的服務對外服務，這些服務都是經過足夠測試，達到了上線標準的服務，有差異但是沒有新舊之分（它們上線時可能採用了藍綠部署的方式）。
A/B測試關注的是不同版本的服務的實際效果，譬如說轉化率、訂單情況等。
A/B測試時，線上同時運行多個版本的服務，這些服務通常會有一些體驗上的差異，譬如說頁面樣式、顏色、操作流程不同。相關人員通過分析各個版本服務的實際效果，選出效果最好的版本。
在A/B測試中，需要能夠控制流量的分配，譬如說，爲A版本分配10%的流量，爲B版本分配10%的流量，爲C版本分配80%的流量。