藍綠部署、紅黑部署、AB測試、灰度發佈、金絲雀發佈、滾動發佈的概念與區別

在有關微服務、DevOps、Cloud-native、系統部署等的討論中，藍綠部署、A/B 測試、灰度發佈、滾動發佈、紅黑部署等概念常常被提到，它們有什麼區別呢？經過搜索相關資料，作一個簡單的辨析，以下：
1、藍綠部署（Blue/Green Deployment）
過去的 10 年裏，不少公司都在使用藍綠部署（發佈）來實現熱部署，這種部署方式具備安全、可靠的特色。藍綠部署雖然算不上「 Sliver Bullet」，但確實很實用。
藍綠部署是最多見的一種0 downtime部署的方式，是一種以可預測的方式發佈應用的技術，目的是減小發布過程當中服務中止的時間。藍綠部署原理上很簡單，就是經過冗餘來解決問題。一般生產環境須要兩組配置（藍綠配置），一組是active的生產環境的配置（綠配置），一組是inactive的配置（藍綠配置）。用戶訪問的時候，只會讓用戶訪問active的服務器集羣。在綠色環境（active）運行當前生產環境中的應用，也就是舊版本應用version1。當你想要升級到version2 ，在藍色環境（inactive）中進行操做，即部署新版本應用，並進行測試。若是測試沒問題，就能夠把負載均衡器／反向代理／路由指向藍色環境了。隨後須要監測新版本應用，也就是version2 是否有故障和異常。若是運行良好，就能夠刪除version1 使用的資源。若是運行出現了問題，能夠經過負載均衡器指向快速回滾到綠色環境。
藍綠部署的優勢：
這種方式的好處在你能夠始終很放心的去部署inactive環境，若是出錯並不影響生產環境的服務，若是切換後出現問題，也能夠在很是短的時間內把再作一次切換，就完成了回滾。並且同時在線的只有一個版本。藍綠部署無需停機，而且風險較小。
(1) 部署版本1的應用（一開始的狀態），全部外部請求的流量都打到這個版本上。
(2) 部署版本2的應用，版本2的代碼與版本1不一樣(新功能、Bug修復等)。
(3) 將流量從版本1切換到版本2。
(4) 如版本2測試正常，就刪除版本1正在使用的資源（例如實例），今後正式用版本2。
從過程不難發現，在部署的過程當中，應用始終在線。而且，新版本上線的過程當中，並無修改老版本的任何內容，在部署期間，老版本的狀態不受影響。這樣風險很小，而且，只要老版本的資源不被刪除，理論上，能夠在任什麼時候間回滾到老版本。
藍綠部署的弱點：
使用藍綠部署須要注意的一些細節包括：
一、當切換到藍色環境時，須要穩當處理未完成的業務和新的業務。若是數據庫後端沒法處理，會是一個比較麻煩的問題。
二、有可能會出現須要同時處理「微服務架構應用」和「傳統架構應用」的狀況，若是在藍綠部署中協調很差這二者，仍是有可能致使服務中止；
三、須要提早考慮數據庫與應用部署同步遷移/回滾的問題。
四、藍綠部署須要有基礎設施支持。
五、在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。
六、另外，這種方式很差的地方還在於冗餘產生的額外維護、配置的成本，以及服務器自己運行的開銷。
藍綠部署適用的場景：
一、不中止老版本，額外搞一套新版本，等測試發現新版本OK後，刪除老版本。
二、藍綠髮布是一種用於升級與更新的發佈策略，部署的最小維度是容器，而發佈的最小維度是應用。
三、藍綠髮布對於增量升級有比較好的支持，可是對於涉及數據表結構變動等等不可逆轉的升級，並不徹底合適用藍綠髮布來實現，須要結合一些業務的邏輯以及數據遷移與回滾的策略才能夠徹底知足需求。

A/B 測試（A/B Testing）
A/B 測試跟藍綠部署徹底是兩碼事。A/B 測試是用來測試應用功能表現的方法，例如可用性、受歡迎程度、可見性等等。 藍綠部署的目的是安全穩定地發佈新版本應用，並在必要時回滾。
A/B 測試與藍綠部署的區別在於， A/B 測試目的在於經過科學的實驗設計、採樣樣本表明性、流量分割與小流量測試等方式來得到具備表明性的實驗結論，並確信該結論在推廣到所有流量可信。
A/B 測試和藍綠部署能夠同時使用。

灰度發佈／金絲雀發佈
灰度發佈是指在黑與白之間，可以平滑過渡的一種發佈方式。灰度發佈是增量發佈的一種類型，灰度發佈是在原有版本可用的狀況下，同時部署一個新版本應用做爲「金絲雀」（金絲雀對瓦斯極敏感，礦井工人攜帶金絲雀，以便及時發發現危險），測試新版本的性能和表現，以保障總體系統穩定的狀況下，儘早發現、調整問題。
灰度發佈／金絲雀發佈由如下幾個步驟組成：
一、準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
二、從負載均衡列表中移除掉「金絲雀」服務器。
三、升級「金絲雀」應用（排掉原有流量並進行部署）。
四、對應用進行自動化測試。
五、將「金絲雀」服務器從新添加到負載均衡列表中（連通性和健康檢查）。
六、若是「金絲雀」在線使用測試成功，升級剩餘的其餘服務器。（不然就回滾）
灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，以保證其影響度。
灰度發佈/金絲雀部署適用的場景：
一、不中止老版本，額外搞一套新版本，不一樣版本應用共存。
二、灰度發佈中，經常按照用戶設置路由權重，例如90%的用戶維持使用老版本，10%的用戶嚐鮮新版本。
三、常常與A/B測試一塊兒使用，用於測試選擇多種方案。AB test就是一種灰度發佈方式，讓一部分用戶繼續用A，一部分用戶開始用B，若是用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到B上面來。
趣聞 ：
金絲雀部署（同理還有金絲雀測試），「金絲雀」的由來：17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會中止歌唱；而當瓦斯含量超過必定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在採礦設備相對簡陋的條件下，工人們每次下井都會帶上一隻金絲雀做爲「瓦斯檢測指標」，以便在危險情況下緊急撤離。

滾動發佈（rolling update）
滾動發佈，通常是取出一個或者多個服務器中止服務，執行更新，並從新將其投入使用。周而復始，直到集羣中全部的實例都更新成新版本。這種部署方式相對於藍綠部署，更加節約資源——它不須要運行兩個集羣、兩倍的實例數。咱們能夠部分部署，例如每次只取出集羣的20%進行升級。
這種方式也有不少缺點，例如：
(1) 沒有一個肯定OK的環境。使用藍綠部署，咱們可以清晰地知道老版本是OK的，而使用滾動發佈，咱們沒法肯定。
(2) 修改了現有的環境。
(3) 若是須要回滾，很困難。舉個例子，在某一次發佈中，咱們須要更新100個實例，每次更新10個實例，每次部署須要5分鐘。當滾動發佈到第80個實例時，發現了問題，須要回滾。此時，脾氣很差的程序猿極可能想掀桌子，由於回滾是一個痛苦，而且漫長的過程。
(4) 有的時候，咱們還可能對系統進行動態伸縮，若是部署期間，系統自動擴容/縮容了，咱們還需判斷到底哪一個節點使用的是哪一個代碼。儘管有一些自動化的運維工具，可是依然使人心驚膽戰。
並非說滾動發佈很差，滾動發佈也有它很是合適的場景。

紅黑部署(Red-Black Deployment)
這是Netflix採用的部署手段，Netflix的主要基礎設施是在AWS上，因此它利用AWS的特性，在部署新的版本時，經過AutoScaling Group用包含新版本應用的AMI的LaunchConfiguration建立新的服務器。測試不經過，找到問題緣由後，直接幹掉新生成的服務器以及Autoscaling Group就能夠，測試經過，則將ELB指向新的服務器集羣，而後銷燬掉舊的服務器集羣以及AutoScaling Group。
紅黑部署的好處是服務始終在線，同時採用不可變部署的方式，也不像藍綠部署同樣得保持冗餘的服務始終在線。