在一般情況下，公升級伺服器端應用，需要將應用原始碼或程式包上傳到伺服器，然後停止掉老版本服務，再啟動新版本。但是這種簡單的發布方式存在兩個問題，一方面，在新版本公升級過程中，服務是暫時中斷的，另一方面，如果新版本有bug，公升級失敗，回滾起來也非常麻煩，容易造成更長時間的服務不可用。
為了解決這些問題，人們研究出了多種發布策略，下面我們一一介紹。
所謂藍綠部署，是指同時執行兩個版本的應用，如上圖所示，藍綠部署的時候，並不停止掉老版本，而是直接部署一套新版本，等新版本執行起來後，再將流量切換到新版本上。但是藍綠部署要求在公升級過程中，同時執行兩套程式，對硬體的要求就是日常所需的二倍，比如日常執行時，需要10臺伺服器支撐業務，那麼使用藍綠部署，你就需要購置二十臺伺服器。
滾動發布能夠解決掉藍綠部署時對硬體要求增倍的問題。
所謂滾動公升級，就是在公升級過程中，並不一下子啟動所有新版本，是先啟動一台新版本，再停止一台老版本，然後再啟動一台新版本，再停止一台老版本，直到公升級完成，這樣的話，如果日常需要10臺伺服器，那麼公升級過程中也就只需要11臺就行了。
但是滾動公升級有乙個問題，在開始滾動公升級後，流量會直接流向已經啟動起來的新版本，但是這個時候，新版本是不一定可用的，比如需要進一步的測試才能確認。那麼在滾動公升級期間，整個系統就處於非常不穩定的狀態，如果發現了問題，也比較難以確定是新版本還是老版本造成的問題。
為了解決這個問題，我們需要為滾動公升級實現流量控制能力。
灰度發布也叫金絲雀發布，起源是，礦井工人發現，金絲雀對瓦斯氣體很敏感，礦工會在下井之前，先放乙隻金絲雀到井中，如果金絲雀不叫了，就代表瓦斯濃度高。
在灰度發布開始後，先啟動乙個新版本應用，但是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啟動的這個新版本應用，就是我們的金絲雀。如果沒有問題，那麼可以將少量的使用者流量匯入到新版本上，然後再對新版本做執行狀態觀察，收集各種執行時資料，如果此時對新舊版本做各種資料對比，就是所謂的a/b測試。
當確認新版本執行良好後，再逐步將更多的流量匯入到新版本上，在此期間，還可以不斷地調整新舊兩個版本的執行的伺服器副本數量，以使得新版本能夠承受越來越大的流量壓力。直到將100%的流量都切換到新版本上，最後關閉剩下的老版本服務，完成灰度發布。
如果在灰度發布過程中（灰度期）發現了新版本有問題，就應該立即將流量切回老版本上，這樣，就會將負面影響控制在最小範圍內。
藍綠發布 灰度發布和滾動發布
2.灰度發布 3.滾動發布 4.小結 應用程式公升級面臨最大挑戰是新舊業務切換，將軟體從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務 長期以來，業務公升級漸漸形成了幾個發布策略 藍綠發布 灰度發布和滾動發布 這些發布方案目的是盡可能避免因發布導致的流量丟失或服務不可用問題。1.1 發布流...
藍綠發布 灰度發布和滾動發布
應用程式公升級面臨最大挑戰是新舊業務切換，將軟體從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務。長期以來，業務公升級漸漸形成了幾個發布策略 藍綠發布 灰度發布和滾動發布，目的是盡可能避免因發布導致的流量丟失或服務不可用問題。專案邏輯上分為ab組，在專案系統時，首先把a組從負載均衡中摘除，...
藍綠部署 滾動部署 灰度發布 金絲雀發布
在專案迭代的過程中，不可避免需要 上線 上線對應著部署，或者重新部署 部署對應著修改 修改則意味著風險。目前有很多用於部署的技術，有的簡單，有的複雜 有的得停機，有的不需要停機即可完成部署。本文的目的就是將目前常用的佈署方案做乙個總結。一 藍綠佈署 blue green deployment 藍綠部...