微服務部署：藍綠部署、滾動部署、灰度發佈

在項目迭代的過程當中，不可避免須要」上線「。上線對應着部署，或者從新部署；部署對應着修改；修改則意味着風險。

目前有不少用於部署的技術，有的簡單，有的複雜；有的得停機，有的不須要停機便可完成部署。本文筆者簡單討論一下目前比較流行的幾種部署方案，或者說策略。若有不足之處請指出，若有謬誤，請指正^_^。

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

(7) 《藍綠髮布的整個部署過程》：http://www.tuicool.com/articles/2Iji2ue