點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

在項目迭代的過程中，不可避免需要”上線“。上線對應著部署，或者重新部署；部署對應著修改；修改則意味著風險。目前有很多部署發(fā)布的技術, 這兒將常見的做一個總結。

上面所說難免有些抽象, 舉一個情景例子, 加入你是微博項目負責人員, 現(xiàn)在新版本較原來的老版本有很大的改變, 這設計到服務架構、前端UI等等, 經(jīng)過測試功能沒有障礙, 那么這時候如何讓用戶切換到新的版本呢?

顯而易見, 第一次發(fā)布的應用是沒有所謂的這個問題的, 這種如何發(fā)布的思考只會出現(xiàn)在后面的版本迭代中。

-? ? ?藍綠發(fā)布? ? -

藍綠部署中，一共有兩套系統(tǒng)：一套是正在提供服務系統(tǒng)(也就是上面說的舊版)，標記為“綠色”；另一套是準備發(fā)布的系統(tǒng)，標記為“藍色”。兩套系統(tǒng)都是功能完善的，并且正在運行的系統(tǒng)，只是系統(tǒng)版本和對外服務情況不同。正在對外提供服務的老系統(tǒng)是綠色系統(tǒng)，新部署的系統(tǒng)是藍色系統(tǒng)。

藍色系統(tǒng)不對外提供服務，用來做啥？

用來做發(fā)布前測試，測試過程中發(fā)現(xiàn)任何問題，可以直接在藍色系統(tǒng)上修改，不干擾用戶正在使用的系統(tǒng)。

藍色系統(tǒng)經(jīng)過反復的測試、修改、驗證，確定達到上線標準之后，直接將用戶切換到藍色系統(tǒng), 切換后的一段時間內(nèi)，依舊是藍綠兩套系統(tǒng)并存，但是用戶訪問的已經(jīng)是藍色系統(tǒng)。這段時間內(nèi)觀察藍色系統(tǒng)（新系統(tǒng)）工作狀態(tài)，如果出現(xiàn)問題，直接切換回綠色系統(tǒng)。

當確信對外提供服務的藍色系統(tǒng)工作正常，不對外提供服務的綠色系統(tǒng)已經(jīng)不再需要的時候，藍色系統(tǒng)正式成為對外提供服務系統(tǒng)，成為新的綠色系統(tǒng)。原先的綠色系統(tǒng)可以銷毀，將資源釋放出來，用于[部署下一個藍色系統(tǒng)。

-? ? ?藍綠發(fā)布特點? ? -

藍綠部署的目的是減少發(fā)布時的中斷時間、能夠快速撤回發(fā)布。

兩套系統(tǒng)沒有耦合的時候才能百分百保證不干擾

-? ? ?藍綠發(fā)布注意事項? ? -

藍綠部署只是[上線策略中的一種，它不是可以應對所有情況的萬能方案。藍綠部署能夠簡單快捷實施的前提假設是目標系統(tǒng)是非常內(nèi)聚的，如果目標系統(tǒng)相當復雜，那么如何切換、兩套系統(tǒng)的數(shù)據(jù)是否需要以及如何同步等，都需要仔細考慮。

當你切換到藍色環(huán)境時，需要妥當處理未完成的業(yè)務和新的業(yè)務。如果你的數(shù)據(jù)庫后端無法處理，會是一個比較麻煩的問題。

• 可能會出現(xiàn)需要同時處理“微服務架構應用”和“傳統(tǒng)架構應用”的情況，如果在藍綠[部署中協(xié)調(diào)不好這兩者，還是有可能會導致服務停止。

• 需要提前考慮數(shù)據(jù)庫與應用部署同步遷移 /回滾的問題。

• 藍綠部署需要有基礎設施支持。

• 在非隔離基礎架構（ VM 、 Docker 等）上執(zhí)行藍綠[部署，藍色環(huán)境和綠色環(huán)境有被摧毀的風險。

-? ? ?滾動發(fā)布? ? -

一般是取出一個或者多個服務器停止服務，執(zhí)行更新，并重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。

發(fā)布流程:

相對于藍綠發(fā)布需要一套完備的機器不同, 滾動發(fā)布只需要一臺機器(這兒這是為了理解, 實際可能是多臺), 我們只需要將部分功能部署在這臺機器上, 然后去替換正在運行的機器, 如上圖, 將更新后的功能部署在Server1 上, 然后Server1去替換正在運行的Server, 替換下來的物理機又可以繼續(xù)部署Server2的新版本, 然后去替換正在工作的Server2 , 以此類推, 直到替換完所有的服務器, 至此 ,服務更新完成。

-? ? ?滾動發(fā)布特點? ? -

這種部署方式相對于藍綠部署，更加節(jié)約資源——它不需要運行兩個集群、兩倍的實例數(shù)。我們可以部分部署，例如每次只取出集群的20%進行升級。

回滾困難

-? ? ?滾動發(fā)布注意事項? ? -

滾動發(fā)布沒有一個確定可行的環(huán)境。使用藍綠[部署，我們能夠清晰地知道老版本是可行的，而使用滾動發(fā)布，我們無法確定。

修改了現(xiàn)有的環(huán)境。

回滾困難。舉個例子，在某一次發(fā)布中，我們需要更新100個實例，每次更新10個實例，每次部署需要5分鐘。當滾動發(fā)布到第80個實例時，發(fā)現(xiàn)了問題，需要回滾，這個回滾卻是一個痛苦，并且漫長的過程。

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

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

-? ? ?灰度發(fā)布? ? -

灰度發(fā)布, 也叫金絲雀發(fā)布。是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。AB test就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。

灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度，而我們平常所說的金絲雀[部署也就是灰度發(fā)布的一種方式。

具體到服務器上, 實際操作中還可以做更多控制，譬如說，給最初更新的10臺服務器設置較低的權重、控制發(fā)送給這10臺服務器的請求數(shù)，然后逐漸提高權重、增加請求數(shù)。一種平滑過渡的思路, 這個控制叫做“流量切分”。

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

過程:

準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。

將“金絲雀”服務器部署進服務器中, 測試。

從負載均衡列表中移除掉“金絲雀”服務器。

升級“金絲雀”應用（排掉原有流量并進行[部署）。

對應用進行自動化測試。

將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。

如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）

-? ? ?A/B 測試? ? -

A/B測試和藍綠發(fā)布、滾動發(fā)布以及金絲雀發(fā)布，完全是兩回事。

藍綠發(fā)布、滾動發(fā)布和金絲雀是發(fā)布策略，目標是確保新上線的系統(tǒng)穩(wěn)定，關注的是新系統(tǒng)的BUG、隱患。

A/B測試是效果測試，同一時間有多個版本的服務對外服務，這些服務都是經(jīng)過足夠測試，達到了[上線標準的服務，有差異但是沒有新舊之分（它們[上線時可能采用了藍綠部署的方式）。

A/B測試關注的是不同版本的服務的實際效果，譬如說轉(zhuǎn)化率、訂單情況等。

A/B測試時，線上同時運行多個版本的服務，這些服務通常會有一些體驗上的差異，譬如說頁面樣式、顏色、操作流程不同。相關人員通過分析各個版本服務的實際效果，選出效果最好的版本。

作者：等不到的口琴

來源：

https://www.cnblogs.com/Courage129/p/14498788.html

想知道更多？掃描下面的二維碼關注我后臺回復"技術"，加入技術群 后臺回復“k8s”，可領取k8s資料【精彩推薦】

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數(shù)據(jù)？

• 架構之道：分離業(yè)務邏輯和技術細節(jié)

• 星巴克不使用兩階段提交

• 面試官：Redis新版本開始引入多線程，談談你的看法？

• 喜馬拉雅自研網(wǎng)關架構演進過程

• 收藏：存儲知識全面總結

• 微博千萬級規(guī)模高性能高并發(fā)的網(wǎng)絡架構設計

總結

以上是生活随笔為你收集整理的蓝绿发布、滚动发布、灰度发布，有什么区别？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。