在項目迭代的過程中，不可避免需要”上線“。上線對應着部署，或者重新部署；部署對應着修改；修改則意味着風險。
目前有很多用於部署的技術，有的簡單，有的復雜；有的得停機，有的不需要停機即可完成部署。本文筆者簡單討論一下目前比較流行的幾種部署方案，或者說策略。如有不足之處請指出，如有謬誤，請指正^_^。
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