在項目迭代的過程中，不可避免需要進行項目上線。上線對應(yīng)著部署或者重新部署，部署對應(yīng)著修改，修改則意味著風險。

目前有很多用于部署的技術(shù)，有的簡單，有的復雜，有的得停機，有的不需要停機即可完成部署。本文將對目前常用的部署方案做一個簡單的總結(jié)。

[[225489]]

藍綠發(fā)布（Blue/Green Deployment）

1. 定義

藍綠部署是不停老版本，部署新版本然后進行測試。確認OK后將流量切到新版本，然后老版本同時也升級到新版本。

2. 特點

藍綠部署無需停機，并且風險較小。

3. 部署過程

• 部署版本 1 的應(yīng)用（初始的狀態(tài)）

所有外部請求的流量都打到這個版本上。

• 部署版本 2 的應(yīng)用

版本 2 的代碼與版本 1 不同(新功能、Bug修復等)。

• 將流量從版本 1 切換到版本 2。

如版本 2 測試正常，就刪除版本 1 正在使用的資源（例如實例），從此正式用版本 2。

4. 小結(jié)

從過程不難發(fā)現(xiàn)，在部署的過程中，我們的應(yīng)用始終在線。并且新版本上線的過程中，并沒有修改老版本的任何內(nèi)容，在部署期間，老版本的狀態(tài)不受影響，這樣風險很小。并且只要老版本的資源不被刪除，理論上，我們可以在任何時間回滾到老版本。

5. 藍綠發(fā)布的注意事項

• 當你切換到藍色環(huán)境時，需要妥當處理未完成的業(yè)務(wù)和新的業(yè)務(wù)。如果你的數(shù)據(jù)庫后端無法處理，會是一個比較麻煩的問題。
• 可能會出現(xiàn)需要同時處理微服務(wù)架構(gòu)應(yīng)用和傳統(tǒng)架構(gòu)應(yīng)用的情況，如果在藍綠部署中協(xié)調(diào)不好這兩者，還是有可能會導致服務(wù)停止。
• 需要提前考慮數(shù)據(jù)庫與應(yīng)用部署同步遷移/回滾的問題。
• 藍綠部署需要有基礎(chǔ)設(shè)施支持。
• 在非隔離基礎(chǔ)架構(gòu)（ VM 、 Docker 等）上執(zhí)行藍綠部署，藍色環(huán)境和綠色環(huán)境有被摧毀的風險。

6. 優(yōu)勢和不足

優(yōu)勢

升級切換和回退速度非常快。

不足

切換是全量的，如果 V2 版本有問題，則對用戶體驗有直接影響。

需要兩倍機器資源。

7. 適用場合

對用戶體驗有一定容忍度的場景。

機器資源有富余或者可以按需分配（AWS 云，或自建容器云）。

灰度發(fā)布

1. 定義

灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。AB Test 就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用 A，一部分用戶開始用 B，如果用戶對 B 沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到 B 上面來。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。

灰度發(fā)布結(jié)構(gòu)圖

2. A/B Testing

A/B 測試是用來測試應(yīng)用功能表現(xiàn)的方法，例如可用性、受歡迎程度、可見性等等。 A/B 測試通常用在應(yīng)用的前端上，不過當然需要后端來支持。

A/B 測試與藍綠部署的區(qū)別在于， A/B 測試目的在于通過科學的實驗設(shè)計、采樣樣本代表性、流量分割與小流量測試等方式來獲得具有代表性的實驗結(jié)論，并確信該結(jié)論在推廣到全部流量可信；藍綠部署的目的是安全穩(wěn)定地發(fā)布新版本應(yīng)用，并在必要時回滾。

3. 金絲雀發(fā)布

我們平常所說的金絲雀部署也是灰度發(fā)布的一種方式，在原有版本可用的情況下，同時部署一個新版本應(yīng)用作為「金絲雀」服務(wù)器來測試新版本的性能和表現(xiàn)，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)、調(diào)整問題。

礦井中的金絲雀：17 世紀，英國礦井工人發(fā)現(xiàn)，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發(fā)身亡。當時在采礦設(shè)備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為瓦斯檢測指標，以便在危險狀況下緊急撤離。

灰度發(fā)布／金絲雀發(fā)布由以下幾個步驟組成：

• 準備好部署各個階段的工件，包括：構(gòu)建工件，測試腳本，配置文件和部署清單文件。
• 從負載均衡列表中移除掉「金絲雀」服務(wù)器。
• 升級「金絲雀」應(yīng)用（排掉原有流量并進行部署）。
• 對應(yīng)用進行自動化測試。
• 將「金絲雀」服務(wù)器重新添加到負載均衡列表中（連通性和健康檢查）。
• 如果「金絲雀」在線使用測試成功，升級剩余的其他服務(wù)器（否則就回滾）。

除此之外灰度發(fā)布還可以設(shè)置路由權(quán)重，動態(tài)調(diào)整不同的權(quán)重來進行新老版本的驗證。

4. 優(yōu)勢和不足

• 優(yōu)勢

用戶體驗影響小，灰度發(fā)布過程出現(xiàn)問題只影響少量用戶。

• 不足

發(fā)布自動化程度不夠，發(fā)布期間可引發(fā)服務(wù)中斷。

滾動發(fā)布（Rolling Update Deployment）

在金絲雀發(fā)布基礎(chǔ)上的進一步優(yōu)化改進，是一種自動化程度較高的發(fā)布方式，用戶體驗比較平滑，是目前成熟型技術(shù)組織所采用的主流發(fā)布方式。

1. 定義

滾動發(fā)布：一般是取出一個或者多個服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。

2. 特點

這種部署方式相對于藍綠部署，更加節(jié)約資源——它不需要運行兩個集群、兩倍的實例數(shù)。我們可以部分部署，例如每次只取出集群的 20% 進行升級。

3. 部署過程

• 滾動式發(fā)布一般先發(fā) 1 臺，或者一個小比例，如 2% 服務(wù)器，主要做流量驗證用，類似金絲雀 (Canary) 測試。
• 滾動式發(fā)布需要比較復雜的發(fā)布工具和智能 LB，支持平滑的版本替換和流量拉入拉出。
• 每次發(fā)布時，先將老版本 V1 流量從 LB 上摘除，然后清除老版本，發(fā)新版本 V2，再將 LB 流量接入新版本。這樣可以盡量保證用戶體驗不受影響。
• 一次滾動式發(fā)布一般由若干個發(fā)布批次組成，每批的數(shù)量一般是可以配置的（可以通過發(fā)布模板定義）。例如***批 1 臺（金絲雀），第二批 10%，第三批 50%，第四批 100%。每個批次之間留觀察間隔，通過手工驗證或監(jiān)控反饋確保沒有問題再發(fā)下一批次，所以總體上滾動式發(fā)布過程是比較緩慢的 (其中金絲雀的時間一般會比后續(xù)批次更長，比如金絲雀 10 分鐘，后續(xù)間隔 2 分鐘)。
• 回退是發(fā)布的逆過程，將新版本流量從 LB 上摘除，清除新版本，發(fā)老版本，再將 LB 流量接入老版本。和發(fā)布過程一樣，回退過程一般也比較慢的。

4. 優(yōu)勢和不足

• 優(yōu)勢

用戶體驗影響小，體驗較平滑。

• 不足

發(fā)布和回退時間比較緩慢。

發(fā)布工具比較復雜，LB 需要平滑的流量摘除和拉入能力。

其它發(fā)布方式

上述都是偏傳統(tǒng)的發(fā)布方式，能覆蓋大部分應(yīng)用發(fā)布場景。針對一些關(guān)鍵新功能的上線發(fā)布，或者一些特定的場景，還有一些特殊的發(fā)布方式。

功能開關(guān)發(fā)布

利用代碼中的功能開關(guān)（Feature Flag/Toggle/Switch）來控制發(fā)布邏輯，一般不需要復雜的發(fā)布工具和智能 LB 配合，是一種相對比較低成本和簡單的發(fā)布方式。這種方式也是支持現(xiàn)代 DevOps 理念，研發(fā)人員可以靈活定制和自助完成的發(fā)布方式。功能開關(guān)的原理如下圖所示：

1. 部署過程

• 功能開關(guān)發(fā)布需要一個配置中心或者開關(guān)中心這樣的服務(wù)支持，例如攜程的 Apollo 配置中心或者開源的 FF4J，這些都支持開關(guān)發(fā)布。業(yè)界還有專門的功能開關(guān) SaaS 服務(wù)，例如 LaunchDarkly。通過配置中心，運維或研發(fā)人員可以在運行期動態(tài)配置功能開關(guān)的值。當然，功能開關(guān)發(fā)布只是配置中心的一種使用場景，配置中心還能支持其它很多動態(tài)配置場景。
• 功能開關(guān)服務(wù)一般提供客戶端 SDK，方便開發(fā)人員集成。在運行期，客戶端 SDK 會同步***的開關(guān)值，技術(shù)實現(xiàn)有推方式 (push)，也有拉方式 (pull)，或者推拉結(jié)合方式。
• 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中，新功能隱藏在開關(guān)后面，如果開關(guān)沒有打開，則走老代碼邏輯，如果開關(guān)打開，則走新代碼邏輯。技術(shù)實現(xiàn)上可以理解為一個簡單的 if/else 邏輯。
• 應(yīng)用上線后，開關(guān)先不打開，然后運維或研發(fā)人員通過開關(guān)中心打開新功能，經(jīng)過流量驗證新功能沒有問題，則發(fā)布完成；如果有問題，則隨時可以通過開關(guān)中心切回老功能邏輯。

2. 優(yōu)勢和不足

• 優(yōu)勢

升級切換和回退速度非常快。

相對于復雜的發(fā)布工具，實施比較簡單，成本相對低廉。

研發(fā)能夠靈活定制發(fā)布邏輯，支持 DevOps 自助發(fā)布。

• 不足

切換是全量的，如果 V2 版本有問題，則對用戶體驗有直接影響。

對代碼有侵入，代碼邏輯會變復雜，需要定期清理老版本邏輯，維護成本變高。

影子測試

對于一些涉及核心業(yè)務(wù)的遺留系統(tǒng)的升級改造，為了確保萬無一失，有一種稱為影子測試的大招，采用比較復雜的流量復制、回放和比對技術(shù)實現(xiàn)。下面是影子測試的一個樣例架構(gòu)圖：

1. 部署過程

影子測試一般適用于遺留系統(tǒng)的等價重構(gòu)遷移，例如 .net 轉(zhuǎn) Java，或者 SQLServer 數(shù)據(jù)庫升級為 MySQL 數(shù)據(jù)庫，且外部依賴不能太多，否則需要開發(fā)很多 mock，測試部署成本會很高，且比對測試更加復雜和不穩(wěn)定。

• 目標實現(xiàn)老的 legacy 服務(wù)遷移升級到新的 experimental 服務(wù)。
• 測試開始前，需要在測試環(huán)境部署一份 legacy 服務(wù)和 experimental 服務(wù)，同時將生產(chǎn)數(shù)據(jù)庫復制兩份到測試環(huán)境。同時需要將生產(chǎn)請求日志收集起來，一般可以通過 kafka 隊列收集，然后通過類似 goreplay 這樣的工具，消費 kafka 里頭的請求日志，復制回放，將請求分發(fā)到 legacy 服務(wù)和 experimental 服務(wù)，收到響應(yīng)后進行比對，如果所有響應(yīng)比對成功，則可以認為 legacy 服務(wù)和 experimental 服務(wù)在功能邏輯上是等價的；如果有響應(yīng)比對失敗，則認為兩者在功能邏輯上不等價，需要修復 experimental 并重新進行影子測試，直到全部比對成功。根據(jù)系統(tǒng)復雜度和關(guān)鍵性不同，比對測試時間短的可能需要幾周，長的可達半年之久。
• 影子測試因為旁路在獨立測試環(huán)境中進行，可以對生產(chǎn)流量完全無影響。

2. 優(yōu)勢和不足

• 優(yōu)勢

對生產(chǎn)用戶體驗完全無影響。

可以使用生產(chǎn)真實流量進行測試（復制比對）。

• 不足

搭建復雜度很高，技術(shù)門檻高，數(shù)據(jù)庫的導出復制是難點。

外部依賴不能太多，否則測試部署成本很高，且比對測試更加復雜和不穩(wěn)定。