微服務部署：藍綠部署、滾動部署、灰階釋出等部署方案對比與總結

轉載自：https://my.oschina.net/eacdy/blog/835980

作者：EACDY

在項目疊代的過程中，不可避免需要”上線“。上線對應着部署，或者重新部署；部署對應着修改；修改則意味着風險。

目前有很多用于部署的技術，有的簡單，有的複雜；有的得停機，有的不需要停機即可完成部署。本文筆者簡單讨論一下目前比較流行的幾種部署方案，或者說政策。如有不足之處請指出，如有謬誤，請指正^_^。

Blue/Green Deployment（藍綠部署）

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

(1) 部署版本1的應用（一開始的狀态）

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

(2) 部署版本2的應用

版本2的代碼與版本1不同(新功能、Bug修複等)。

(3) 将流量從版本1切換到版本2。

(4) 如版本2測試正常，就删除版本1正在使用的資源（例如執行個體），從此正式用版本2。

從過程不難發現，在部署的過程中，我們的應用始終線上。并且，新版本上線的過程中，并沒有修改老版本的任何内容，在部署期間，老版本的狀态不受影響。這樣風險很小，并且，隻要老版本的資源不被删除，理論上，我們可以在任何時間復原到老版本。

rolling update（滾動釋出）

滾動釋出，一般是取出一個或者多個伺服器停止服務，執行更新，并重新将其投入使用。周而複始，直到叢集中所有的執行個體都更新成新版本。

這種部署方式相對于藍綠部署，更加節約資源——它不需要運作兩個叢集、兩倍的執行個體數。我們可以部分部署，例如每次隻取出叢集的20%進行更新。

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

(1) 沒有一個确定OK的環境。使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動釋出，我們無法确定。

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

(3) 如果需要復原，很困難。舉個例子，在某一次釋出中，我們需要更新100個執行個體，每次更新10個執行個體，每次部署需要5分鐘。當滾動釋出到第80個執行個體時，發現了問題，需要復原。此時，脾氣不好的程式猿很可能想掀桌子，因為復原是一個痛苦，并且漫長的過程。

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

并不是說滾動釋出不好，滾動釋出也有它非常合适的場景。

灰階釋出/金絲雀部署

先貼個百度百科：

灰階釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。AB test就是一種灰階釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐漸擴大範圍，把所有使用者都遷移到B上面來。灰階釋出可以保證整體系統的穩定，在初始灰階的時候就可以發現、調整問題，以保證其影響度。

很多人把灰階釋出與藍綠部署混為一談，筆者認為，與灰階釋出最類似的應該是金絲雀部署。

“金絲雀部署”是增量釋出的一種類型，它的執行方式是在原有軟體生産版本可用的情況下，同時部署一個新的版本。同時運作同一個軟體産品的多個版本需要軟體針對配置和完美自動化部署進行特别設計。

我們來看一下金絲雀部署的步驟：

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

(2) 從負載均衡清單中移除掉“金絲雀”伺服器。

(3) 更新“金絲雀”應用（排掉原有流量并進行部署）。

(4) 對應用進行自動化測試。

(5) 将“金絲雀”伺服器重新添加到負載均衡清單中（連通性和健康檢查）。

(6) 如果“金絲雀”線上使用測試成功，更新剩餘的其他伺服器。（否則就復原）

灰階釋出中，常常按照使用者設定路由權重，例如90%的使用者維持使用老版本，10%的使用者嘗鮮新版本。不同版本應用共存，經常與A/B測試一起使用，用于測試選擇多種方案。灰階釋出比較典型的例子，是阿裡雲那個“新版本”，點選“進入新版本”，我們就成了金絲雀。

趣聞 ：金絲雀部署（同理還有金絲雀測試），“金絲雀”的由來：17世紀，英國礦井勞工發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在采礦裝置相對簡陋的條件下，勞工們每次下井都會帶上一隻金絲雀作為“瓦斯檢測名額”，以便在危險狀況下緊急撤離。

總結

(1) 藍綠部署：不停止老版本，額外搞一套新版本，等測試發現新版本OK後，删除老版本。

(2) 滾動釋出：按批次停止老版本執行個體，啟動新版本執行個體。

(3) 灰階釋出/金絲雀部署：不停止老版本，額外搞一套新版本，常常按照使用者設定路由權重，例如90%的使用者維持使用老版本，10%的使用者嘗鮮新版本。不同版本應用共存，經常與A/B測試一起使用，用于測試選擇多種方案。

參考文檔

(1) 《Blue-green Deployments, A/B Testing, and Canary Releases》（有圖文說明，必看）：http://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/

(2) Martin Fowler《BlueGreenDeployment》（必看）：https://martinfowler.com/bliki/BlueGreenDeployment.html

(3) 《在生産中使用金絲雀部署來進行測試》：http://www.infoq.com/cn/news/2013/03/canary-release-improve-quality

(4) 《Using Blue-Green Deployment to Reduce Downtime and Risk（使用爛藍綠部署降降低停機時間與風險，基于CloudFoundry）》：http://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html

(5) 《marathon：Blue-Green Deployment》：https://mesosphere.github.io/marathon/docs/blue-green-deploy.html ，譯文：http://blog.csdn.net/zhuchuangang/article/details/51064974 。

(6) 《微服務不是免費的午餐》：http://blog.csdn.net/phodal/article/details/27098005