一文搞懂藍綠髮布、灰度發佈與滾動更新

應用程序升級面臨最大挑戰是新舊業務切換，將軟件從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務。
長期以來，業務升級漸漸造成了幾個發佈策略：藍綠髮布、灰度發佈和滾動發佈，目的是儘量避免因發佈致使的流量丟失或服務不可用問題。

7.1 藍綠髮布
項目邏輯上分爲AB組，在項目系統時，首先把A組從負載均衡中摘除，進行新版本的部署。B組仍然繼續提供服務。
一文搞懂藍綠髮布、灰度發佈和滾動發佈
當A組升級完畢，負載均衡從新接入A組，再把B組從負載列表中摘除，進行新版本的部署。A組從新提供服務。

最後，B組也升級完成，負載均衡從新接入B組，此時，AB組版本都已經升級完成，而且都對外提供服務。

特色
若是出問題，影響範圍較大；
發佈策略簡單；
用戶無感知，平滑過渡；
升級/回滾速度快。
缺點
須要準備正常業務使用資源的兩倍以上服務器，防止升級期間單組沒法承載業務突發；
短期內浪費必定資源成本；
基礎設施無改動，增大升級穩定性。
藍綠髮布在早期物理服務器時代，仍是比較昂貴的，因爲雲計算普及，成本也大大下降。

7.2 灰度發佈
灰度發佈只升級部分服務，即讓一部分用戶繼續用老版本，一部分用戶開始用新版本，若是用戶對新版本沒什麼意見，那麼逐步擴大範圍，把全部用戶都遷移到新版本上面來。
一文搞懂藍綠髮布、灰度發佈和滾動發佈

特色
保證總體系統穩定性，在初始灰度的時候就能夠發現、調整問題，影響範圍可控；
新功能逐步評估性能，穩定性和健康情況，若是出問題影響範圍很小，相對用戶體驗也少；
用戶無感知，平滑過渡。
缺點
自動化要求高
部署過程
從LB摘掉灰度服務器，升級成功後再加入LB；
少許用戶流量到新版本；
若是灰度服務器測試成功，升級剩餘服務器。
灰度發佈是經過切換線上並存版本之間的路由權重，逐步從一個版本切換爲另外一個版本的過程。

7.3 滾動發佈
滾動發佈是指每次只升級一個或多個服務，升級完成後加入生產環境，不斷執行這個過程，直到集羣中的所有舊版本升級新版本。
一文搞懂藍綠髮布、灰度發佈和滾動發佈

紅色：正在更新的實例；
藍色：更新完成並加入集羣的實例；
綠色：正在運行的實例。
特色
用戶無感知，平滑過渡；
節約資源。
缺點
部署時間慢，取決於每階段更新時間；
發佈策略較複雜；
沒法肯定OK的環境，不易回滾。
部署過程
先升級1個副本，主要作部署驗證；
每次升級副本，自動從LB上摘掉，升級成功後自動加入集羣；
事先須要有自動更新策略，分爲若干次，每次數量/百分比可配置；
回滾是發佈的逆過程，先從LB摘掉新版本，再升級老版本，這個過程通常時間比較長；
自動化要求高。
小結
綜上所述，三種方式都可以作到平滑式升級，在升級過程當中服務仍然保持服務的連續性，升級對外界是無感知的。那生產上選擇哪一種部署方法最合適呢？這取決於哪一種方法最適合你的業務和技術需求。若是大家運維自動化能力儲備不夠，確定是越簡單越好，建議藍綠髮布，若是業務對用戶依賴很強，建議灰度發佈。若是是K8S平臺，滾動更新是現成的方案，建議先直接使用。

藍綠髮布：兩套環境交替升級，舊版本保留必定時間便於回滾。

灰度發佈：根據比例將老版本升級，例如80%用戶訪問是老版本，20%用戶訪問是新版本。

滾動發佈：按批次中止老版本實例，啓動新版本實例。
本文轉轉載：http://www.javashuo.com/article/p-zapuurqw-bu.html