藍綠部署是不停老版本,部署新版本而後進行測試。確認OK後將流量切到新版本,而後老版本同時也升級到新版本。前端
藍綠部署無需停機,而且風險較小。數據庫
全部外部請求的流量都打到這個版本上。後端
版本 2 的代碼與版本 1 不一樣(新功能、Bug修復等)。安全
從過程不難發現,在部署的過程當中,咱們的應用始終在線。而且新版本上線的過程當中,並無修改老版本的任何內容,在部署期間,老版本的狀態不受影響,這樣風險很小。而且只要老版本的資源不被刪除,理論上,咱們能夠在任什麼時候間回滾到老版本。服務器
當你切換到藍色環境時,須要穩當處理未完成的業務和新的業務。若是你的數據庫後端沒法處理,會是一個比較麻煩的問題。架構
升級切換和回退速度很是快。負載均衡
切換是全量的,若是 V2 版本有問題,則對用戶體驗有直接影響。 須要兩倍機器資源。微服務
灰度發佈是指在黑與白之間,可以平滑過渡的一種發佈方式。AB Test 就是一種灰度發佈方式,讓一部分用戶繼續用 A,一部分用戶開始用 B,若是用戶對 B 沒有什麼反對意見,那麼逐步擴大範圍,把全部用戶都遷移到 B 上面來。灰度發佈能夠保證總體系統的穩定,在初始灰度的時候就能夠發現、調整問題,以保證其影響度。工具
A/B 測試是用來測試應用功能表現的方法,例如可用性、受歡迎程度、可見性等等。 A/B 測試一般用在應用的前端上,不過固然須要後端來支持。性能
A/B 測試與藍綠部署的區別在於, A/B 測試目的在於經過科學的實驗設計、採樣樣本表明性、流量分割與小流量測試等方式來得到具備表明性的實驗結論,並確信該結論在推廣到所有流量可信;藍綠部署的目的是安全穩定地發佈新版本應用,並在必要時回滾。
咱們日常所說的金絲雀部署也是灰度發佈的一種方式,在原有版本可用的狀況下,同時部署一個新版本應用做爲「金絲雀」服務器來測試新版本的性能和表現,以保障總體系統穩定的狀況下,儘早發現、調整問題。
礦井中的金絲雀:17 世紀,英國礦井工人發現,金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯,金絲雀也會中止歌唱;當瓦斯含量超過必定限度時,雖然魯鈍的人類毫無察覺,金絲雀卻早已毒發身亡。當時在採礦設備相對簡陋的條件下,工人們每次下井都會帶上一隻金絲雀做爲瓦斯檢測指標,以便在危險情況下緊急撤離。
灰度發佈/金絲雀發佈由如下幾個步驟組成:
除此以外灰度發佈還能夠設置路由權重,動態調整不一樣的權重來進行新老版本的驗證。
用戶體驗影響小,灰度發佈過程出現問題隻影響少許用戶。
發佈自動化程度不夠,發佈期間可引起服務中斷。
在金絲雀發佈基礎上的進一步優化改進,是一種自動化程度較高的發佈方式,用戶體驗比較平滑,是目前成熟型技術組織所採用的主流發佈方式。
滾動發佈:通常是取出一個或者多個服務器中止服務,執行更新,並從新將其投入使用。周而復始,直到集羣中全部的實例都更新成新版本。
這種部署方式相對於藍綠部署,更加節約資源——它不須要運行兩個集羣、兩倍的實例數。咱們能夠部分部署,例如每次只取出集羣的 20% 進行升級。
用戶體驗影響小,體驗較平滑。
發佈和回退時間比較緩慢。 發佈工具比較複雜,LB 須要平滑的流量摘除和拉入能力。