在項(xiàng)目迭代的過程中，不可避免需要上線。上線對(duì)應(yīng)著部署，或者重新部署；部署對(duì)應(yīng)著修改,修改則意味著風(fēng)險(xiǎn)。
1.藍(lán)綠發(fā)布(Blue/Green Deployment)
①定義
藍(lán)綠部署是不停老版本，部署新版本然后進(jìn)行測(cè)試。確認(rèn)OK后將流量切到新版本，然后老版本同時(shí)也升級(jí)到新版本。
②特點(diǎn)
藍(lán)綠部署無需停機(jī)，并且風(fēng)險(xiǎn)較小。
③部署過程
部署版本V1的應(yīng)用（初始的狀態(tài)）
所有外部請(qǐng)求的流量都打到這個(gè)版本上。
部署版本V2的應(yīng)用
版本V2的代碼與版本V1不同(新功能、Bug修復(fù)等)。-
將流量從版本1 切換到版本2
image.png -
如版本V2測(cè)試正常，就刪除版本V1正在使用的資源（例如實(shí)例），從此正式用版本V2。
image.png
④小結(jié)
從過程不難發(fā)現(xiàn)，在部署的過程中，我們的應(yīng)用始終在線。并且新版本上線的過程中，并沒有修改老版本的任何內(nèi)容，在部署期間，老版本的狀態(tài)不受影響，這樣風(fēng)險(xiǎn)很小。并且只要老版本的資源不被刪除，理論上，我們可以在任何時(shí)間回滾到老版本。
⑤藍(lán)綠發(fā)布的注意事項(xiàng)
當(dāng)你切換到藍(lán)色環(huán)境時(shí)，需要妥當(dāng)處理未完成的業(yè)務(wù)和新的業(yè)務(wù)。如果你的數(shù)據(jù)庫后端無法處理，會(huì)是一個(gè)比較麻煩的問題。
可能會(huì)出現(xiàn)需要同時(shí)處理微服務(wù)架構(gòu)應(yīng)用和傳統(tǒng)架構(gòu)應(yīng)用的情況，如果在藍(lán)綠部署中協(xié)調(diào)不好這兩者，還是有可能會(huì)導(dǎo)致服務(wù)停止。
需要提前考慮數(shù)據(jù)庫與應(yīng)用部署同步遷移/回滾的問題。
藍(lán)綠部署需要有基礎(chǔ)設(shè)施支持。
在非隔離基礎(chǔ)架構(gòu)（ VM 、 Docker 等）上執(zhí)行藍(lán)綠部署，藍(lán)色環(huán)境和綠色環(huán)境有被摧毀的風(fēng)險(xiǎn)。
⑥優(yōu)勢(shì)和不足
- 優(yōu)勢(shì)
升級(jí)切換和回退速度非?？?。 - 不足
切換是全量的，如果V2版本有問題，則對(duì)用戶體驗(yàn)有直接影響。需要兩倍機(jī)器資源。
⑦適用場(chǎng)合
對(duì)用戶體驗(yàn)有一定容忍度的場(chǎng)景。
機(jī)器資源有富余或者可以按需分配（AWS 云，或自建容器云）。
2.灰度發(fā)布
①灰度發(fā)布定義
灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。AB Test 就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對(duì)B沒有什么反對(duì)意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來?；叶劝l(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。
灰度發(fā)布結(jié)構(gòu)圖
②A/B Testing
A/B測(cè)試是用來測(cè)試應(yīng)用功能表現(xiàn)的方法，例如可用性、受歡迎程度、可見性等等。 A/B測(cè)試通常用在應(yīng)用的前端上，不過當(dāng)然需要后端來支持。
A/B 測(cè)試與藍(lán)綠發(fā)布的區(qū)別在于， A/B 測(cè)試目的在于通過科學(xué)的實(shí)驗(yàn)設(shè)計(jì)、采樣樣本代表性、流量分割與小流量測(cè)試等方式來獲得具有代表性的實(shí)驗(yàn)結(jié)論，并確信該結(jié)論在推廣到全部流量可信；藍(lán)綠發(fā)布的目的是安全穩(wěn)定地發(fā)布新版本應(yīng)用，并在必要時(shí)回滾。
藍(lán)綠發(fā)布和金絲雀是發(fā)布策略，目標(biāo)是確保新上線的系統(tǒng)穩(wěn)定，關(guān)注的是新系統(tǒng)的BUG、隱患。
A/B測(cè)試是效果測(cè)試，同一時(shí)間有多個(gè)版本的服務(wù)對(duì)外服務(wù)，這些服務(wù)都是經(jīng)過足夠測(cè)試，達(dá)到了上線標(biāo)準(zhǔn)的服務(wù)，有差異但是沒有新舊之分（它們上線時(shí)可能采用了藍(lán)綠發(fā)布的方式）。
③金絲雀發(fā)布（Canary Deployment）
我們平常所說的金絲雀部署也是灰度發(fā)布的一種方式，在原有版本可用的情況下，同時(shí)部署一個(gè)新版本應(yīng)用作為「金絲雀」服務(wù)器來測(cè)試新版本的性能和表現(xiàn)，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)、調(diào)整問題。
礦井中的金絲雀：17 世紀(jì)，英國(guó)礦井工人發(fā)現(xiàn)，金絲雀對(duì)瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會(huì)停止歌唱；當(dāng)瓦斯含量超過一定限度時(shí)，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發(fā)身亡。當(dāng)時(shí)在采礦設(shè)備相對(duì)簡(jiǎn)陋的條件下，工人們每次下井都會(huì)帶上一只金絲雀作為瓦斯檢測(cè)指標(biāo)，以便在危險(xiǎn)狀況下緊急撤離。
灰度發(fā)布／金絲雀發(fā)布由以下幾個(gè)步驟組成：
- 準(zhǔn)備好部署各個(gè)階段的工件，包括：構(gòu)建工件，測(cè)試腳本，配置文件和部署清單文件。
- 從負(fù)載均衡列表中移除掉「金絲雀」服務(wù)器。
- 升級(jí)「金絲雀」應(yīng)用（排掉原有流量并進(jìn)行部署）。
- 對(duì)應(yīng)用進(jìn)行自動(dòng)化測(cè)試。
- 將「金絲雀」服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）。
- 如果「金絲雀」在線使用測(cè)試成功，升級(jí)剩余的其他服務(wù)器（否則就回滾）。
除此之外灰度發(fā)布還可以設(shè)置路由權(quán)重，動(dòng)態(tài)調(diào)整不同的權(quán)重來進(jìn)行新老版本的驗(yàn)證，例如Istio中就可以實(shí)現(xiàn)權(quán)重來進(jìn)行新老版本的驗(yàn)證發(fā)布。
④優(yōu)勢(shì)和不足
- 優(yōu)勢(shì)
用戶體驗(yàn)影響小，灰度發(fā)布過程出現(xiàn)問題只影響少量用戶。 - 不足
發(fā)布自動(dòng)化程度不夠，發(fā)布期間可引發(fā)服務(wù)中斷。
3.滾動(dòng)發(fā)布(Rolling Update Deployment)
在金絲雀發(fā)布基礎(chǔ)上的進(jìn)一步優(yōu)化改進(jìn)，是一種自動(dòng)化程度較高的發(fā)布方式，用戶體驗(yàn)比較平滑，是目前成熟型技術(shù)組織所采用的主流發(fā)布方式。
①定義
滾動(dòng)發(fā)布：一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有的實(shí)例都更新成新版本。
②特點(diǎn)
這種部署方式相對(duì)于藍(lán)綠部署，更加節(jié)約資源——它不需要運(yùn)行兩個(gè)集群、兩倍的實(shí)例數(shù)。我們可以部分部署，例如每次只取出集群的 20% 進(jìn)行升級(jí)。
③部署過程
- 滾動(dòng)式發(fā)布一般先發(fā)1臺(tái)，或者一個(gè)小比例，如2% 服務(wù)器，主要做流量驗(yàn)證用，類似金絲雀 (Canary) 測(cè)試。
- 滾動(dòng)式發(fā)布需要比較復(fù)雜的發(fā)布工具和智能 LB，支持平滑的版本替換和流量拉入拉出。
- 每次發(fā)布時(shí)，先將老版本V1流量從LB上摘除，然后清除老版本，發(fā)新版本V2，再將LB流量接入新版本。這樣可以盡量保證用戶體驗(yàn)不受影響。
- 一次滾動(dòng)式發(fā)布一般由若干個(gè)發(fā)布批次組成，每批的數(shù)量一般是可以配置的（可以通過發(fā)布模板定義）。例如第一批 1 臺(tái)（金絲雀），第二批 10%，第三批 50%，第四批 100%。每個(gè)批次之間留觀察間隔，通過手工驗(yàn)證或監(jiān)控反饋確保沒有問題再發(fā)下一批次，所以總體上滾動(dòng)式發(fā)布過程是比較緩慢的 (其中金絲雀的時(shí)間一般會(huì)比后續(xù)批次更長(zhǎng)，比如金絲雀 10 分鐘，后續(xù)間隔 2 分鐘)。
- 回退是發(fā)布的逆過程，將新版本流量從 LB 上摘除，清除新版本，發(fā)老版本，再將 LB 流量接入老版本。和發(fā)布過程一樣，回退過程一般也比較慢的。
④優(yōu)勢(shì)和不足
- 優(yōu)勢(shì)
用戶體驗(yàn)影響小，體驗(yàn)較平滑。 - 不足
-- 發(fā)布和回退時(shí)間比較緩慢。
-- 發(fā)布工具比較復(fù)雜，LB 需要平滑的流量摘除和拉入能力。
4.功能開關(guān)發(fā)布
利用代碼中的功能開關(guān)（Feature Flag/Toggle/Switch）來控制發(fā)布邏輯，一般不需要復(fù)雜的發(fā)布工具和智能 LB 配合，是一種相對(duì)比較低成本和簡(jiǎn)單的發(fā)布方式。這種方式也是支持現(xiàn)代 DevOps 理念，研發(fā)人員可以靈活定制和自助完成的發(fā)布方式。功能開關(guān)的原理如下圖所示：
①部署過程
- 功能開關(guān)發(fā)布需要一個(gè)配置中心或者開關(guān)中心這樣的服務(wù)支持，例如攜程的 Apollo配置中心或者開源的FF4J，這些都支持開關(guān)發(fā)布。業(yè)界還有專門的功能開關(guān) SaaS 服務(wù)，例如 LaunchDarkly。通過配置中心，運(yùn)維或研發(fā)人員可以在運(yùn)行期動(dòng)態(tài)配置功能開關(guān)的值。當(dāng)然，功能開關(guān)發(fā)布只是配置中心的一種使用場(chǎng)景，配置中心還能支持其它很多動(dòng)態(tài)配置場(chǎng)景。
- 功能開關(guān)服務(wù)一般提供客戶端 SDK，方便開發(fā)人員集成。在運(yùn)行期，客戶端 SDK 會(huì)同步最新的開關(guān)值，技術(shù)實(shí)現(xiàn)有推方式 (push)，也有拉方式 (pull)，或者推拉結(jié)合方式。
- 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中，新功能隱藏在開關(guān)后面，如果開關(guān)沒有打開，則走老代碼邏輯，如果開關(guān)打開，則走新代碼邏輯。技術(shù)實(shí)現(xiàn)上可以理解為一個(gè)簡(jiǎn)單的 if/else 邏輯。
- 應(yīng)用上線后，開關(guān)先不打開，然后運(yùn)維或研發(fā)人員通過開關(guān)中心打開新功能，經(jīng)過流量驗(yàn)證新功能沒有問題，則發(fā)布完成；如果有問題，則隨時(shí)可以通過開關(guān)中心切回老功能邏輯。
②優(yōu)勢(shì)和不足
- 優(yōu)勢(shì)
升級(jí)切換和回退速度非常快。
相對(duì)于復(fù)雜的發(fā)布工具，實(shí)施比較簡(jiǎn)單，成本相對(duì)低廉。
研發(fā)能夠靈活定制發(fā)布邏輯，支持 DevOps 自助發(fā)布。 - 不足
切換是全量的，如果 V2 版本有問題，則對(duì)用戶體驗(yàn)有直接影響。
對(duì)代碼有侵入，代碼邏輯會(huì)變復(fù)雜，需要定期清理老版本邏輯，維護(hù)成本變高。
轉(zhuǎn)載自：https://www.pingface.com/2020/05/deploymentstrategy.html
