藍綠部署 滾動部署 灰度發布 金絲雀發布

在專案迭代的過程中，不可避免需要」上線「。上線對應著部署，或者重新部署；部署對應著修改；修改則意味著風險。

一、藍綠佈署

藍綠部署是不停老版本，部署新版本然後進行測試，確認ok，將流量切到新版本，然後老版本同時也公升級到新版本。

1、特點

藍綠部署無需停機，並且風險較小。

2、佈署過程

第一步、部署版本1的應用（一開始的狀態）

所有外部請求的流量都打到這個版本上。

第二步、部署版本2的應用

版本2的**與版本1不同(新功能、bug修復等)。

第三步、將流量從版本1切換到版本2。

第四步、如版本2測試正常，就刪除版本1正在使用的資源（例如例項），從此正式用版本2。

3、小結

4、藍綠發布的注意事項

當你切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果你的資料庫後端無法處理，會是乙個比較麻煩的問題；

二、rolling update（滾動發布）

滾動發布：一般是取出乙個或者多個伺服器停止服務，執行更新，並重新將其投入使用。周而復始，直到集群中所有的例項都更新成新版本。

2、特點

這種部署方式相對於藍綠部署，更加節約資源——它不需要執行兩個集群、兩倍的例項數。我們可以部分部署，例如每次只取出集群的20%進行公升級。

這種方式也有很多缺點，例如：

(1) 沒有乙個確定ok的環境。使用藍綠部署，我們能夠清晰地知道老版本是ok的，而使用滾動發布，我們無法確定。

(2) 修改了現有的環境。

(3) 如果需要回滾，很困難。舉個例子，在某一次發布中，我們需要更新100個例項，每次更新10個例項，每次部署需要5分鐘。當滾動發布到第80個例項時，發現了問題，需要回滾，這個回滾卻是乙個痛苦，並且漫長的過程。

(4) 有的時候，我們還可能對系統進行動態伸縮，如果部署期間，系統自動擴容/縮容了，我們還需判斷到底哪個節點使用的是哪個**。儘管有一些自動化的運維工具，但是依然令人心驚膽戰。

(5) 因為是逐步更新，那麼我們在上線**的時候，就會短暫出現新老版本不一致的情況，如果對上線要求較高的場景，那麼就需要考慮如何做好相容的問題。

三、灰度發布/金絲雀部署

灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。ab test就是一種灰度發布方式，讓一部分使用者繼續用a，一部分使用者開始用b，如果使用者對b沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到b上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發布的一種方式。

注釋：礦井中的金絲雀

17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在採礦裝置相對簡陋的條件下，工人們每次下井都會帶上乙隻金絲雀作為「瓦斯檢測指標」，以便在危險狀況下緊急撤離。

image.png

2、灰度發布／金絲雀發布由以下幾個步驟組成：

除此之外灰度發布還可以設定路由權重，動態調整不同的權重來進行新老版本的驗證。

參考文章

一文明白藍綠部署 滾動部署 灰度發布 金絲雀發布

說明 藍綠部署 a b測試 金絲雀發布，以及灰度發布 流量切分等，經常被混為一談，影響溝通效率。根本原因是這些名詞經常出現，人們耳熟能詳能夠熟練地談起，對這些術語的理解卻沒有達成一致。下面是從blue green deployments,a b testing,and canary releases...

部署策略對比 藍綠部署 金絲雀發布及其他

目前，軟體開發最大的變化是部署頻率。產品團隊更早 更頻繁 的將產品發布到生產環境。數月或者數年的發布週期變得越來越短 對那些構建純軟體產品的人來說更是如此。現在，使用面向服務的架構和微服務方式，開發者可以設計模組化的 庫。這允許他們同時在 庫中不同的地方編寫和部署代變更。縮短部署週期的業務優勢狠明顯...

部署策略對比 藍綠部署 金絲雀發布及其他

目前，軟體開發最大的變化是部署頻率。產品團隊更早 更頻繁 的將產品發布到生產環境。數月或者數年的發布週期變得越來越短 對那些構建純軟體產品的人來說更是如此。現在，使用面向服務的架構和微服務方式，開發者可以設計模組化的 庫。這允許他們同時在 庫中不同的地方編寫和部署代變更。縮短部署週期的業務優勢狠明顯...