微服務(wù)中藍(lán)綠部署、紅黑部署、AB測試、灰度發(fā)布、金絲雀發(fā)布、滾動發(fā)布的概念與區(qū)別是什么

本篇文章給大家分享的是有關(guān)微服務(wù)中藍(lán)綠部署、紅黑部署、AB測試、灰度發(fā)布、金絲雀發(fā)布、滾動發(fā)布的概念與區(qū)別是什么，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

在有關(guān)微服務(wù)、DevOps、Cloud-native、系統(tǒng)部署等的討論中，藍(lán)綠部署、A/B 測試、灰度發(fā)布、滾動發(fā)布、紅黑部署等概念經(jīng)常被提到，它們有什么區(qū)別呢？通過搜索相關(guān)資料，做一個(gè)簡單的辨析，如下：
一、藍(lán)綠部署（Blue/Green Deployment）
過去的 10 年里，很多公司都在使用藍(lán)綠部署（發(fā)布）來實(shí)現(xiàn)熱部署，這種部署方式具有安全、可靠的特點(diǎn)。藍(lán)綠部署雖然算不上“ Sliver Bullet”，但確實(shí)很實(shí)用。
藍(lán)綠部署是最常見的一種0 downtime部署的方式，是一種以可預(yù)測的方式發(fā)布應(yīng)用的技術(shù)，目的是減少發(fā)布過程中服務(wù)停止的時(shí)間。藍(lán)綠部署原理上很簡單，就是通過冗余來解決問題。通常生產(chǎn)環(huán)境需要兩組配置（藍(lán)綠配置），一組是active的生產(chǎn)環(huán)境的配置（綠配置），一組是inactive的配置（藍(lán)綠配置）。用戶訪問的時(shí)候，只會讓用戶訪問active的服務(wù)器集群。在綠色環(huán)境（active）運(yùn)行當(dāng)前生產(chǎn)環(huán)境中的應(yīng)用，也就是舊版本應(yīng)用version1。當(dāng)你想要升級到version2 ，在藍(lán)色環(huán)境（inactive）中進(jìn)行操作，即部署新版本應(yīng)用，并進(jìn)行測試。如果測試沒問題，就可以把負(fù)載均衡器／反向代理／路由指向藍(lán)色環(huán)境了。隨后需要監(jiān)測新版本應(yīng)用，也就是version2 是否有故障和異常。如果運(yùn)行良好，就可以刪除version1 使用的資源。如果運(yùn)行出現(xiàn)了問題，可以通過負(fù)載均衡器指向快速回滾到綠色環(huán)境。
藍(lán)綠部署的優(yōu)點(diǎn)：
這種方式的好處在你可以始終很放心的去部署inactive環(huán)境，如果出錯(cuò)并不影響生產(chǎn)環(huán)境的服務(wù)，如果切換后出現(xiàn)問題，也可以在非常短的時(shí)間內(nèi)把再做一次切換，就完成了回滾。而且同時(shí)在線的只有一個(gè)版本。藍(lán)綠部署無需停機(jī)，并且風(fēng)險(xiǎn)較小。
(1) 部署版本1的應(yīng)用（一開始的狀態(tài)），所有外部請求的流量都打到這個(gè)版本上。
(2) 部署版本2的應(yīng)用，版本2的代碼與版本1不同(新功能、Bug修復(fù)等)。
(3) 將流量從版本1切換到版本2。
(4) 如版本2測試正常，就刪除版本1正在使用的資源（例如實(shí)例），從此正式用版本2。
從過程不難發(fā)現(xiàn)，在部署的過程中，應(yīng)用始終在線。并且，新版本上線的過程中，并沒有修改老版本的任何內(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ù)庫后端無法處理，會是一個(gè)比較麻煩的問題。
2、有可能會出現(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ù)庫與應(yīng)用部署同步遷移/回滾的問題。
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)行的開銷。
藍(lán)綠部署適用的場景：
1、不停止老版本，額外搞一套新版本，等測試發(fā)現(xiàn)新版本OK后，刪除老版本。
2、藍(lán)綠發(fā)布是一種用于升級與更新的發(fā)布策略，部署的最小維度是容器，而發(fā)布的最小維度是應(yīng)用。
3、藍(lán)綠發(fā)布對于增量升級有比較好的支持，但是對于涉及數(shù)據(jù)表結(jié)構(gòu)變更等等不可逆轉(zhuǎn)的升級，并不完全合適用藍(lán)綠發(fā)布來實(shí)現(xiàn)，需要結(jié)合一些業(yè)務(wù)的邏輯以及數(shù)據(jù)遷移與回滾的策略才可以完全滿足需求。

A/B 測試（A/B Testing）
A/B 測試跟藍(lán)綠部署完全是兩碼事。A/B 測試是用來測試應(yīng)用功能表現(xiàn)的方法，例如可用性、受歡迎程度、可見性等等。 藍(lán)綠部署的目的是安全穩(wěn)定地發(fā)布新版本應(yīng)用，并在必要時(shí)回滾。
A/B 測試與藍(lán)綠部署的區(qū)別在于， A/B 測試目的在于通過科學(xué)的實(shí)驗(yàn)設(shè)計(jì)、采樣樣本代表性、流量分割與小流量測試等方式來獲得具有代表性的實(shí)驗(yàn)結(jié)論，并確信該結(jié)論在推廣到全部流量可信。
A/B 測試和藍(lán)綠部署可以同時(shí)使用。

灰度發(fā)布／金絲雀發(fā)布
灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式?；叶劝l(fā)布是增量發(fā)布的一種類型，灰度發(fā)布是在原有版本可用的情況下，同時(shí)部署一個(gè)新版本應(yīng)用作為“金絲雀”（金絲雀對瓦斯極敏感，礦井工人攜帶金絲雀，以便及時(shí)發(fā)發(fā)現(xiàn)危險(xiǎn)），測試新版本的性能和表現(xiàn)，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)、調(diào)整問題。
灰度發(fā)布／金絲雀發(fā)布由以下幾個(gè)步驟組成：
1、準(zhǔn)備好部署各個(gè)階段的工件，包括：構(gòu)建工件，測試腳本，配置文件和部署清單文件。
2、從負(fù)載均衡列表中移除掉“金絲雀”服務(wù)器。
3、升級“金絲雀”應(yīng)用（排掉原有流量并進(jìn)行部署）。
4、對應(yīng)用進(jìn)行自動化測試。
5、將“金絲雀”服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）。
6、如果“金絲雀”在線使用測試成功，升級剩余的其他服務(wù)器。（否則就回滾）
灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。
灰度發(fā)布/金絲雀部署適用的場景：
1、不停止老版本，額外搞一套新版本，不同版本應(yīng)用共存。
2、灰度發(fā)布中，常常按照用戶設(shè)置路由權(quán)重，例如90%的用戶維持使用老版本，10%的用戶嘗鮮新版本。
3、經(jīng)常與A/B測試一起使用，用于測試選擇多種方案。AB test就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來。
趣聞 ：
金絲雀部署（同理還有金絲雀測試），“金絲雀”的由來：17世紀(jì)，英國礦井工人發(fā)現(xiàn)，金絲雀對瓦斯這種氣體十分敏感?？諝庵心呐掠袠O其微量的瓦斯，金絲雀也會停止歌唱；而當(dāng)瓦斯含量超過一定限度時(shí)，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發(fā)身亡。當(dāng)時(shí)在采礦設(shè)備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標(biāo)”，以便在危險(xiǎn)狀況下緊急撤離。

滾動發(fā)布（rolling update）
滾動發(fā)布，一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有的實(shí)例都更新成新版本。這種部署方式相對于藍(lán)綠部署，更加節(jié)約資源——它不需要運(yùn)行兩個(gè)集群、兩倍的實(shí)例數(shù)。我們可以部分部署，例如每次只取出集群的20%進(jìn)行升級。
這種方式也有很多缺點(diǎn)，例如：
(1) 沒有一個(gè)確定OK的環(huán)境。使用藍(lán)綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動發(fā)布，我們無法確定。
(2) 修改了現(xiàn)有的環(huán)境。
(3) 如果需要回滾，很困難。舉個(gè)例子，在某一次發(fā)布中，我們需要更新100個(gè)實(shí)例，每次更新10個(gè)實(shí)例，每次部署需要5分鐘。當(dāng)滾動發(fā)布到第80個(gè)實(shí)例時(shí)，發(fā)現(xiàn)了問題，需要回滾。此時(shí)，脾氣不好的程序猿很可能想掀桌子，因?yàn)榛貪L是一個(gè)痛苦，并且漫長的過程。
(4) 有的時(shí)候，我們還可能對系統(tǒng)進(jìn)行動態(tài)伸縮，如果部署期間，系統(tǒng)自動擴(kuò)容/縮容了，我們還需判斷到底哪個(gè)節(jié)點(diǎn)使用的是哪個(gè)代碼。盡管有一些自動化的運(yùn)維工具，但是依然令人心驚膽戰(zhàn)。
并不是說滾動發(fā)布不好，滾動發(fā)布也有它非常合適的場景。

紅黑部署(Red-Black Deployment)
這是Netflix采用的部署手段，Netflix的主要基礎(chǔ)設(shè)施是在AWS上，所以它利用AWS的特性，在部署新的版本時(shí)，通過AutoScaling Group用包含新版本應(yīng)用的AMI的LaunchConfiguration創(chuàng)建新的服務(wù)器。測試不通過，找到問題原因后，直接干掉新生成的服務(wù)器以及Autoscaling Group就可以，測試通過，則將ELB指向新的服務(wù)器集群，然后銷毀掉舊的服務(wù)器集群以及AutoScaling Group。
紅黑部署的好處是服務(wù)始終在線，同時(shí)采用不可變部署的方式，也不像藍(lán)綠部署一樣得保持冗余的服務(wù)始終在線。

以上就是微服務(wù)中藍(lán)綠部署、紅黑部署、AB測試、灰度發(fā)布、金絲雀發(fā)布、滾動發(fā)布的概念與區(qū)別是什么，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。