藍(lán)綠部署
藍(lán)綠部署叁怪，英文名為 Blue Green Deployment蕊连，是一種可以保證系統(tǒng)在不間斷提供服務(wù)的情況下上線的部署方式缎脾。
如何保證系統(tǒng)不間斷提供服務(wù)呢祝闻？那就是同時部署兩個集群，但僅對外提供一個集群的服務(wù)遗菠，當(dāng)需要升級時联喘，切換集群進(jìn)行升級华蜒。藍(lán)綠部署無需停機(jī)，并且風(fēng)險較小豁遭。其大致步驟為：
部署集群 1 的應(yīng)用（初始狀態(tài)）叭喜，將所有外部請求的流量都打到這個集群上
部署集群 2 的應(yīng)用，集群 2 的代碼與集群 1 不同蓖谢，如新功能或者 Bug 修復(fù)等
將流量從集群 1 切換到集群 2
如集群 2 測試正常捂蕴，就刪除集群 1 正在使用的資源（例如實例），使用集群 2 對外提供服務(wù)
因為在使用藍(lán)綠部署的方式時闪幽，我們需要控制流量啥辨，所以我們需要借助路由服務(wù)，如 Nginx 等盯腌。
滾動部署
滾動部署溉知，英文名為 Rolling Update，同樣是一種可以保證系統(tǒng)在不間斷提供服務(wù)的情況下上線的部署方式腊嗡。和藍(lán)綠部署不同的是着倾，滾動部署對外提供服務(wù)的版本并不是非此即彼拾酝，而是在更細(xì)的粒度下平滑完成版本的升級燕少。
如何做到細(xì)粒度平滑升級版本呢？滾動部署只需要一個集群蒿囤，集群下的不同節(jié)點可以獨立進(jìn)行版本升級客们。比如在一個 12 節(jié)點的集群中，我們每次升級 4 個節(jié)點材诽，并將升級后的節(jié)點重新投入使用底挫，周而復(fù)始，直到集群中所有的節(jié)點都更新為新版本脸侥。
這種部署方式相對于藍(lán)綠部署建邓，更加節(jié)約資源，因為它不需要運行兩個集群睁枕。但這種方式也有很多缺點官边，例如：
沒有一個確定 OK 的環(huán)境。使用藍(lán)綠部署外遇，我們能夠清晰地知道老版本是 OK 的注簿，而使用滾動發(fā)布，我們無法確定跳仿。
修改了現(xiàn)有的環(huán)境诡渴。
如果需要回滾，很困難菲语。舉個例子妄辩，在某一次發(fā)布中惑灵，我們需要更新 100 個實例，每次更新 10 個實例眼耀，每次部署需要 5 分鐘泣棋。當(dāng)滾動發(fā)布到第 80 個實例時，發(fā)現(xiàn)了問題畔塔，需要回滾潭辈。這時，我們估計就要瘋了澈吨。
有的時候把敢，我們還可能對系統(tǒng)進(jìn)行動態(tài)伸縮，如果部署期間谅辣，系統(tǒng)自動擴(kuò)容/縮容了修赞，我們還需判斷到底哪個節(jié)點使用的是哪個代碼。盡管有一些自動化的運維工具桑阶，但是依然令人心驚膽戰(zhàn)柏副。
并不是說滾動發(fā)布不好，滾動發(fā)布也有它非常合適的場景蚣录。
金絲雀部署
金絲雀部署又稱灰度部署（或者割择，灰度發(fā)布），英文名為 Canary Deployment萎河，是指在黑與白之間荔泳，能夠平滑過渡的一種發(fā)布方式。
金絲雀的名稱來源于「礦井中的金絲雀」虐杯，早在 17 世紀(jì)玛歌，英國礦井工人發(fā)現(xiàn)，金絲雀對瓦斯這種氣體十分敏感擎椰，空氣中哪怕有極其微量的瓦斯支子，金絲雀也會停止歌唱；而當(dāng)瓦斯含量超過一定限度時达舒，雖然魯鈍的人類毫無察覺值朋，金絲雀卻早已毒發(fā)身亡。當(dāng)時在采礦設(shè)備相對簡陋的條件下休弃，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標(biāo)”吞歼，以便在危險狀況下緊急撤離。
我們來看一下金絲雀部署的步驟：
準(zhǔn)備好部署各個階段的工件塔猾，包括：構(gòu)建工件篙骡，測試腳本，配置文件和部署清單文件
從負(fù)載均衡列表中移除掉“金絲雀”服務(wù)器
升級“金絲雀”應(yīng)用（切斷原有流量并進(jìn)行部署）
對應(yīng)用進(jìn)行自動化測試
將“金絲雀”服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）
如果“金絲雀”在線使用測試成功，升級剩余的其他服務(wù)器（否則就回滾）
在金絲雀部署中糯俗，常常按照用戶量設(shè)置路由權(quán)重尿褪，例如 90% 的用戶維持使用老版本，10% 的用戶嘗鮮新版本得湘。不同版本應(yīng)用共存杖玲，經(jīng)常與 A/B 測試一起使用，用于測試選擇多種方案淘正。
金絲雀部署比較典型的例子摆马，就是我們在使用某個應(yīng)用的時候，該應(yīng)用邀請我們進(jìn)行“內(nèi)測”或者“新版本體驗”鸿吆，如果我們同意了囤采，那么我們就成了金絲雀。
