項目邏輯上分爲AB組,在項目系統時,首先把A組從負載均衡中摘除,進行新版本的部署。B組仍然繼續提供服務。
當A組升級完畢,負載均衡從新接入A組,再把B組從負載列表中摘除,進行新版本的部署。A組從新提供服務。
最後,B組也升級完成,負載均衡從新接入B組,此時,AB組版本都已經升級完成,而且都對外提供服務。
若是出問題,影響範圍較大; 發佈策略簡單; 用戶無感知,平滑過渡; 升級/回滾速度快。
須要準備正常業務使用資源的兩倍以上服務器,防止升級期間單組沒法承載業務突發; 短期內浪費必定資源成本; 基礎設施無改動,增大升級穩定性。 藍綠髮布在早期物理服務器時代,仍是比較昂貴的,因爲雲計算普及,成本也大大下降。
灰度發佈只升級部分服務,即讓一部分用戶繼續用老版本,一部分用戶開始用新版本,若是用戶對新版本沒什麼意見,那麼逐步擴大範圍,把全部用戶都遷移到新版本上面來。
服務器
保證總體系統穩定性,在初始灰度的時候就能夠發現、調整問題,影響範圍可控; 新功能逐步評估性能,穩定性和健康情況,若是出問題影響範圍很小,相對用戶體驗也少; 用戶無感知,平滑過渡。
自動化要求高 部署過程 從LB摘掉灰度服務器,升級成功後再加入LB; 少許用戶流量到新版本; 若是灰度服務器測試成功,升級剩餘服務器。 灰度發佈是經過切換線上並存版本之間的路由權重,逐步從一個版本切換爲另外一個版本的過程。
滾動發佈是指每次只升級一個或多個服務,升級完成後加入生產環境,不斷執行這個過程,直到集羣中的所有舊版本升級新版本。
負載均衡
紅色:正在更新的實例; 藍色:更新完成並加入集羣的實例; 綠色:正在運行的實例。
用戶無感知,平滑過渡; 節約資源。
部署時間慢,取決於每階段更新時間; 發佈策略較複雜; 沒法肯定OK的環境,不易回滾。 部署過程 先升級1個副本,主要作部署驗證; 每次升級副本,自動從LB上摘掉,升級成功後自動加入集羣; 事先須要有自動更新策略,分爲若干次,每次數量/百分比可配置; 回滾是發佈的逆過程,先從LB摘掉新版本,再升級老版本,這個過程通常時間比較長; 自動化要求高。
綜上所述,三種方式都可以作到平滑式升級,在升級過程當中服務仍然保持服務的連續性,升級對外界是無感知的。那生產上選擇哪一種部署方法最合適呢?這取決於哪一種方法最適合你的業務和技術需求。若是大家運維自動化能力儲備不夠,確定是越簡單越好,建議藍綠髮布,若是業務對用戶依賴很強,建議灰度發佈。若是是K8S平臺,滾動更新是現成的方案,建議先直接使用。運維
藍綠髮布:兩套環境交替升級,舊版本保留必定時間便於回滾。 灰度發佈:根據比例將老版本升級,例如80%用戶訪問是老版本,20%用戶訪問是新版本。 滾動發佈:按批次中止老版本實例,啓動新版本實例。