在有關(guān)微服務(wù)、DevOps、Cloud-native、系統(tǒng)部署等的討論中，藍(lán)綠部署、A/B 測(cè)試、灰度發(fā)布、滾動(dòng)發(fā)布、紅黑部署等概念經(jīng)常被提到，它們有什么區(qū)別呢？通過(guò)搜索相關(guān)資料，做一個(gè)簡(jiǎn)單的辨析，如下：
一、藍(lán)綠部署（Blue/Green Deployment）
過(guò)去的 10 年里，很多公司都在使用藍(lán)綠部署（發(fā)布）來(lái)實(shí)現(xiàn)熱部署，這種部署方式具有安全、可靠的特點(diǎn)。藍(lán)綠部署雖然算不上“ Sliver Bullet”，但確實(shí)很實(shí)用。
藍(lán)綠部署是最常見(jiàn)的一種0 downtime部署的方式，是一種以可預(yù)測(cè)的方式發(fā)布應(yīng)用的技術(shù)，目的是減少發(fā)布過(guò)程中服務(wù)停止的時(shí)間。藍(lán)綠部署原理上很簡(jiǎn)單，就是通過(guò)冗余來(lái)解決問(wèn)題。通常生產(chǎn)環(huán)境需要兩組配置（藍(lán)綠配置），一組是active的生產(chǎn)環(huán)境的配置（綠配置），一組是inactive的配置（藍(lán)綠配置）。用戶訪問(wèn)的時(shí)候，只會(huì)讓用戶訪問(wèn)active的服務(wù)器集群。在綠色環(huán)境（active）運(yùn)行當(dāng)前生產(chǎn)環(huán)境中的應(yīng)用，也就是舊版本應(yīng)用version1。當(dāng)你想要升級(jí)到version2 ，在藍(lán)色環(huán)境（inactive）中進(jìn)行操作，即部署新版本應(yīng)用，并進(jìn)行測(cè)試。如果測(cè)試沒(méi)問(wèn)題，就可以把負(fù)載均衡器／反向代理／路由指向藍(lán)色環(huán)境了。隨后需要監(jiān)測(cè)新版本應(yīng)用，也就是version2 是否有故障和異常。如果運(yùn)行良好，就可以刪除version1 使用的資源。如果運(yùn)行出現(xiàn)了問(wèn)題，可以通過(guò)負(fù)載均衡器指向快速回滾到綠色環(huán)境。
藍(lán)綠部署的優(yōu)點(diǎn)：
這種方式的好處在你可以始終很放心的去部署inactive環(huán)境，如果出錯(cuò)并不影響生產(chǎn)環(huán)境的服務(wù)，如果切換后出現(xiàn)問(wèn)題，也可以在非常短的時(shí)間內(nèi)把再做一次切換，就完成了回滾。而且同時(shí)在線的只有一個(gè)版本。藍(lán)綠部署無(wú)需停機(jī)，并且風(fēng)險(xiǎn)較小。
(1) 部署版本1的應(yīng)用（一開(kāi)始的狀態(tài)），所有外部請(qǐng)求的流量都打到這個(gè)版本上。
(2) 部署版本2的應(yīng)用，版本2的代碼與版本1不同(新功能、Bug修復(fù)等)。
(3) 將流量從版本1切換到版本2。
(4) 如版本2測(cè)試正常，就刪除版本1正在使用的資源（例如實(shí)例），從此正式用版本2。
從過(guò)程不難發(fā)現(xiàn)，在部署的過(guò)程中，應(yīng)用始終在線。并且，新版本上線的過(guò)程中，并沒(méi)有修改老版本的任何內(nèi)容，在部署期間，老版本的狀態(tài)不受影響。這樣風(fēng)險(xiǎn)很小，并且，只要老版本的資源不被刪除，理論上，可以在任何時(shí)間回滾到老版本。
藍(lán)綠部署的弱點(diǎn)：
使用藍(lán)綠部署需要注意的一些細(xì)節(jié)包括：
1、當(dāng)切換到藍(lán)色環(huán)境時(shí)，需要妥當(dāng)處理未完成的業(yè)務(wù)和新的業(yè)務(wù)。如果數(shù)據(jù)庫(kù)后端無(wú)法處理，會(huì)是一個(gè)比較麻煩的問(wèn)題。
2、有可能會(huì)出現(xiàn)需要同時(shí)處理“微服務(wù)架構(gòu)應(yīng)用”和“傳統(tǒng)架構(gòu)應(yīng)用”的情況，如果在藍(lán)綠部署中協(xié)調(diào)不好這兩者，還是有可能導(dǎo)致服務(wù)停止；
3、需要提前考慮數(shù)據(jù)庫(kù)與應(yīng)用部署同步遷移/回滾的問(wèn)題。
4、藍(lán)綠部署需要有基礎(chǔ)設(shè)施支持。
5、在非隔離基礎(chǔ)架構(gòu)（ VM 、 Docker 等）上執(zhí)行藍(lán)綠部署，藍(lán)色環(huán)境和綠色環(huán)境有被摧毀的風(fēng)險(xiǎn)。
6、另外，這種方式不好的地方還在于冗余產(chǎn)生的額外維護(hù)、配置的成本，以及服務(wù)器本身運(yùn)行的開(kāi)銷。
藍(lán)綠部署適用的場(chǎng)景：
1、不停止老版本，額外搞一套新版本，等測(cè)試發(fā)現(xiàn)新版本OK后，刪除老版本。
2、藍(lán)綠發(fā)布是一種用于升級(jí)與更新的發(fā)布策略，部署的最小維度是容器，而發(fā)布的最小維度是應(yīng)用。
3、藍(lán)綠發(fā)布對(duì)于增量升級(jí)有比較好的支持，但是對(duì)于涉及數(shù)據(jù)表結(jié)構(gòu)變更等等不可逆轉(zhuǎn)的升級(jí)，并不完全合適用藍(lán)綠發(fā)布來(lái)實(shí)現(xiàn)，需要結(jié)合一些業(yè)務(wù)的邏輯以及數(shù)據(jù)遷移與回滾的策略才可以完全滿足需求。
A/B 測(cè)試（A/B Testing）
A/B 測(cè)試跟藍(lán)綠部署完全是兩碼事。A/B 測(cè)試是用來(lái)測(cè)試應(yīng)用功能表現(xiàn)的方法，例如可用性、受歡迎程度、可見(jiàn)性等等。 藍(lán)綠部署的目的是安全穩(wěn)定地發(fā)布新版本應(yīng)用，并在必要時(shí)回滾。
A/B 測(cè)試與藍(lán)綠部署的區(qū)別在于， A/B 測(cè)試目的在于通過(guò)科學(xué)的實(shí)驗(yàn)設(shè)計(jì)、采樣樣本代表性、流量分割與小流量測(cè)試等方式來(lái)獲得具有代表性的實(shí)驗(yàn)結(jié)論，并確信該結(jié)論在推廣到全部流量可信。
A/B 測(cè)試和藍(lán)綠部署可以同時(shí)使用。
灰度發(fā)布／金絲雀發(fā)布
灰度發(fā)布是指在黑與白之間，能夠平滑過(guò)渡的一種發(fā)布方式?；叶劝l(fā)布是增量發(fā)布的一種類型，灰度發(fā)布是在原有版本可用的情況下，同時(shí)部署一個(gè)新版本應(yīng)用作為“金絲雀”（金絲雀對(duì)瓦斯極敏感，礦井工人攜帶金絲雀，以便及時(shí)發(fā)發(fā)現(xiàn)危險(xiǎn)），測(cè)試新版本的性能和表現(xiàn)，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)、調(diào)整問(wèn)題。
灰度發(fā)布／金絲雀發(fā)布由以下幾個(gè)步驟組成：
1、準(zhǔn)備好部署各個(gè)階段的工件，包括：構(gòu)建工件，測(cè)試腳本，配置文件和部署清單文件。
2、從負(fù)載均衡列表中移除掉“金絲雀”服務(wù)器。
3、升級(jí)“金絲雀”應(yīng)用（排掉原有流量并進(jìn)行部署）。
4、對(duì)應(yīng)用進(jìn)行自動(dòng)化測(cè)試。
5、將“金絲雀”服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）。
6、如果“金絲雀”在線使用測(cè)試成功，升級(jí)剩余的其他服務(wù)器。（否則就回滾）
灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問(wèn)題，以保證其影響度。
灰度發(fā)布/金絲雀部署適用的場(chǎng)景：
1、不停止老版本，額外搞一套新版本，不同版本應(yīng)用共存。
2、灰度發(fā)布中，常常按照用戶設(shè)置路由權(quán)重，例如90%的用戶維持使用老版本，10%的用戶嘗鮮新版本。
3、經(jīng)常與A/B測(cè)試一起使用，用于測(cè)試選擇多種方案。AB test就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開(kāi)始用B，如果用戶對(duì)B沒(méi)有什么反對(duì)意見(jiàn)，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來(lái)。
趣聞 ：
金絲雀部署（同理還有金絲雀測(cè)試），“金絲雀”的由來(lái)：17世紀(jì)，英國(guó)礦井工人發(fā)現(xiàn)，金絲雀對(duì)瓦斯這種氣體十分敏感?？諝庵心呐掠袠O其微量的瓦斯，金絲雀也會(huì)停止歌唱；而當(dāng)瓦斯含量超過(guò)一定限度時(shí)，雖然魯鈍的人類毫無(wú)察覺(jué)，金絲雀卻早已毒發(fā)身亡。當(dāng)時(shí)在采礦設(shè)備相對(duì)簡(jiǎn)陋的條件下，工人們每次下井都會(huì)帶上一只金絲雀作為“瓦斯檢測(cè)指標(biāo)”，以便在危險(xiǎn)狀況下緊急撤離。
滾動(dòng)發(fā)布（rolling update）
滾動(dòng)發(fā)布，一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有的實(shí)例都更新成新版本。這種部署方式相對(duì)于藍(lán)綠部署，更加節(jié)約資源——它不需要運(yùn)行兩個(gè)集群、兩倍的實(shí)例數(shù)。我們可以部分部署，例如每次只取出集群的20%進(jìn)行升級(jí)。
這種方式也有很多缺點(diǎn)，例如：
(1) 沒(méi)有一個(gè)確定OK的環(huán)境。使用藍(lán)綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動(dòng)發(fā)布，我們無(wú)法確定。
(2) 修改了現(xiàn)有的環(huán)境。
(3) 如果需要回滾，很困難。舉個(gè)例子，在某一次發(fā)布中，我們需要更新100個(gè)實(shí)例，每次更新10個(gè)實(shí)例，每次部署需要5分鐘。當(dāng)滾動(dòng)發(fā)布到第80個(gè)實(shí)例時(shí)，發(fā)現(xiàn)了問(wèn)題，需要回滾。此時(shí)，脾氣不好的程序猿很可能想掀桌子，因?yàn)榛貪L是一個(gè)痛苦，并且漫長(zhǎng)的過(guò)程。
(4) 有的時(shí)候，我們還可能對(duì)系統(tǒng)進(jìn)行動(dòng)態(tài)伸縮，如果部署期間，系統(tǒng)自動(dòng)擴(kuò)容/縮容了，我們還需判斷到底哪個(gè)節(jié)點(diǎn)使用的是哪個(gè)代碼。盡管有一些自動(dòng)化的運(yùn)維工具，但是依然令人心驚膽戰(zhàn)。
并不是說(shuō)滾動(dòng)發(fā)布不好，滾動(dòng)發(fā)布也有它非常合適的場(chǎng)景。
紅黑部署(Red-Black Deployment)
這是Netflix采用的部署手段，Netflix的主要基礎(chǔ)設(shè)施是在AWS上，所以它利用AWS的特性，在部署新的版本時(shí)，通過(guò)AutoScaling Group用包含新版本應(yīng)用的AMI的LaunchConfiguration創(chuàng)建新的服務(wù)器。測(cè)試不通過(guò)，找到問(wèn)題原因后，直接干掉新生成的服務(wù)器以及Autoscaling Group就可以，測(cè)試通過(guò)，則將ELB指向新的服務(wù)器集群，然后銷毀掉舊的服務(wù)器集群以及AutoScaling Group。
紅黑部署的好處是服務(wù)始終在線，同時(shí)采用不可變部署的方式，也不像藍(lán)綠部署一樣得保持冗余的服務(wù)始終在線。
