過去的10多年裏,不少大公司都在使用藍綠部署,安全、可靠是這種部署方式的特色。藍綠部署雖然算不上」Sliver Bullet「,但確實很實用。在有關於「微服務」、「DevOps」、「Cloud-native」的討論中,藍綠部署、A/B測試、灰度發佈,這三種部署方式每每同時出鏡。html
那麼問題來了,藍綠部署、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 version一、App2 version一、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