過去的10多年里，很多大公司都在使用藍綠部署，安全、可靠是這種部署方式的特點。藍綠部署雖然算不上”Sliver Bullet“，但確實很實用。在有關於“微服務”、“DevOps”、“Cloud-native”的討論中，藍綠部署、A/B測試、灰度發布，這三種部署方式往往同時出鏡。
那么問題來了，藍綠部署、A/B測試、灰度發布，這三者之間究竟有何不同？
A/B測試
-
消除 客戶體驗（UX）設計中不同意見的紛爭，根據實際效果確定最佳方案；
-
通過對比試驗，找到問題的真正原因，提高產品設計和運營水平；
-
建立數據驅動、持續不斷優化的閉環過程；
-
通過A/B測試，降低新產品或新特性的發布風險，為產品創新提供保障。
參考：https://baike.baidu.com/item/AB%E6%B5%8B%E8%AF%95/9231223?fr=aladdin
但是關於A/B測試的有效性，在一份關於 A/B 測試的報告中，Qubit 的 Martin Goodson 認為：大多數 A/B 測試的結果都不太准確。Web Arts 的 Andre Morys 甚至斷論：“ 這些測試結果 90% 都是假的。”如果真的是這樣，那么很多決策的制定都基於這些無效的實驗，這也是之所以很多非首席風險官經理對 A/B 測試結果的可持續性持懷疑態度的原因。
參考：http://baijiahao.baidu.com/s?id=1603336396513574172
藍綠部署
Martin Flower曾在文章中闡述了藍綠部署的整體要點，建議大家看看。
基本上，藍綠部署是一種以可預測的方式發布應用的技術，目的是減少發布過程中服務停止的時間。
簡單來說，你需要准備兩個相同的環境（基礎架構），在藍色環境運行當前生產環境中的應用，也就是舊版本應用，如圖中App1 version1、App2 version1、App3 version3。
當你想要升級App2到version2，在藍色環境中進行操作，即部署新版本應用，並進行測試。如果測試沒問題，就可以把負載均衡器／反向代理／路由指向藍色環境了。
隨后你需要監測新版本應用，也就是App2 version2是否有故障和異常。如果運行良好，就可以刪除App2 version1使用的資源。如果運行出現了問題，你可以通過負載均衡器指向快速回滾到綠色環境。
理論上聽起來很棒，但還是要注意一些細節：
-
當你切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果你的數據庫后端無法處理，會是一個比較麻煩的問題；
-
有可能會出現需要同時處理“微服務架構應用”和“傳統架構應用”的情況，如果在藍綠部署中協調不好這兩者，還是有可能導致服務停止的；
-
需要提前考慮數據庫與應用部署同步遷移/回滾的問題；
-
藍綠部署需要有基礎設施支持
-
在非隔離基礎架構（VM、Docker等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。
藍綠測試適合於任何的環境，無論是互聯網應用還是企業應用。
灰度發布（金絲雀發布）
金絲雀發布（Canary）也是一種發布策略，和國內常說的灰度發布是同一類策略。
藍綠部署是准備兩套系統，在兩套系統之間進行切換，金絲雀策略是只有一套系統，逐漸替換這套系統。
譬如說，目標系統是一組無狀態的Web服務器，但是數量非常多，假設有一萬台。
這時候，藍綠部署就不能用了，因為你不可能申請一萬台服務器專門用來部署藍色系統（在藍綠部署的定義中，藍色的系統要能夠承接所有訪問）。
可以想到的一個方法是：
只准備幾台服務器，在上面部署新版本的系統並測試驗證。測試通過之后，擔心出現意外，還不敢立即更新所有的服務器。
先將線上的一萬台服務器中的10台更新為最新的系統，然后觀察驗證。確認沒有異常之后，再將剩余的所有服務器更新。
這個方法就是金絲雀發布。
實際操作中還可以做更多控制，譬如說，給最初更新的10台服務器設置較低的權重、控制發送給這10台服務器的請求數，然后逐漸提高權重、增加請求數。
這個控制叫做“流量切分”，既可以用於金絲雀發布，也可以用於后面的A/B測試。
藍綠部署和金絲雀發布是兩種發布策略，都不是萬能的。有時候兩者都可以使用，有時候只能用其中一種。
上面的例子中可以用金絲雀，不能用藍綠，那么什么時候可以用藍綠，不能用金絲雀呢？整個系統只有一台服務器的時候。
參考：
https://www.v2ex.com/t/344341
https://www.jianshu.com/p/5862d7573bf2