應用程式公升級面臨最大挑戰是新舊業務切換，將軟體從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務。
長期以來，業務公升級漸漸形成了幾個發布策略：藍綠發布、灰度發布和滾動發布，目的是盡可能避免因發布導致的流量丟失或服務不可用問題。
專案邏輯上分為ab組，在專案系統時，首先把a組從負載均衡中摘除，進行新版本的部署。b組仍然繼續提供服務。
當a組公升級完畢，負載均衡重新接入a組，再把b組從負載列表中摘除，進行新版本的部署。a組重新提供服務。
最後，b組也公升級完成，負載均衡重新接入b組，此時，ab組版本都已經公升級完成，並且都對外提供服務。
如果出問題，影響範圍較大；
發布策略簡單；
使用者無感知，平滑過渡；
公升級/回滾速度快。
需要準備正常業務使用資源的兩倍以上伺服器，防止公升級期間單組無法承載業務突發；
短時間內浪費一定資源成本；
基礎設施無改動，增大公升級穩定性。
藍綠發布在早期物理伺服器時代，還是比較昂貴的，由於雲計算普及，成本也大大降低。
灰度發布只公升級部分服務，即讓一部分使用者繼續用老版本，一部分使用者開始用新版本，如果使用者對新版本沒什麼意見，那麼逐步擴大範圍，把所有使用者都遷移到新版本上面來。
保證整體系統穩定性，在初始灰度的時候就可以發現、調整問題，影響範圍可控；
新功能逐步評估效能，穩定性和健康狀況，如果出問題影響範圍很小，相對使用者體驗也少；
使用者無感知，平滑過渡。
自動化要求高
從lb摘掉灰度伺服器，公升級成功後再加入lb；
少量使用者流量到新版本；
如果灰度伺服器測試成功，公升級剩餘伺服器。
灰度發布是通過切換線上並存版本之間的路由權重，逐步從乙個版本切換為另乙個版本的過程。
滾動發布是指每次只公升級乙個或多個服務，公升級完成後加入生產環境，不斷執行這個過程，直到集群中的全部舊版本公升級新版本。
紅色：正在更新的例項
藍色：更新完成並加入集群的例項
綠色：正在執行的例項
使用者無感知，平滑過渡；
節約資源。
部署時間慢，取決於每階段更新時間；
發布策略較複雜；
無法確定ok的環境，不易回滾。
先公升級1個副本，主要做部署驗證；
每次公升級副本，自動從lb上摘掉，公升級成功後自動加入集群；
事先需要有自動更新策略，分為若干次，每次數量/百分比可配置；
回滾是發布的逆過程，先從lb摘掉新版本，再公升級老版本，這個過程一般時間比較長；
自動化要求高。
綜上所述，三種方式均可以做到平滑式公升級，在公升級過程中服務仍然保持服務的連續性，公升級對外界是無感知的。那生產上選擇哪種部署方法最合適呢？這取決於哪種方法最適合你的業務和技術需求。如果你們運維自動化能力儲備不夠，肯定是越簡單越好，建議藍綠發布，如果業務對使用者依賴很強，建議灰度發布。如果是k8s平台，滾動更新是現成的方案，建議先直接使用。
藍綠發布：兩套環境交替公升級，舊版本保留一定時間便於回滾。
灰度發布：根據比例將老版本公升級，例如80%使用者訪問是老版本，20%使用者訪問是新版本。
滾動發布：按批次停止老版本例項，啟動新版本例項。
一文搞懂藍綠發布、灰度發布和滾動發布
藍綠發布 灰度發布和滾動發布
2.灰度發布 3.滾動發布 4.小結 應用程式公升級面臨最大挑戰是新舊業務切換，將軟體從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務 長期以來，業務公升級漸漸形成了幾個發布策略 藍綠發布 灰度發布和滾動發布 這些發布方案目的是盡可能避免因發布導致的流量丟失或服務不可用問題。1.1 發布流...
藍綠發布 灰度發布和滾動發布
應用程式公升級面臨最大挑戰是新舊業務切換，將軟體從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務。長期以來，業務公升級漸漸形成了幾個發布策略 藍綠發布 灰度發布和滾動發布，目的是盡可能避免因發布導致的流量丟失或服務不可用問題。專案邏輯上分為ab組，在專案系統時，首先把a組從負載均衡中摘除，...
什麼是藍綠部署 滾動發布 灰度發布？
在一般情況下，公升級伺服器端應用，需要將應用原始碼或程式包上傳到伺服器，然後停止掉老版本服務，再啟動新版本。但是這種簡單的發布方式存在兩個問題，一方面，在新版本公升級過程中，服務是暫時中斷的，另一方面，如果新版本有bug，公升級失敗，回滾起來也非常麻煩，容易造成更長時間的服務不可用。為了解決這些問題...