藍綠髮布、滾動發佈、灰度發佈等部署方案對比與總結

在項目迭代的過程當中，不可避免須要進行項目上線。

上線對應着部署或者從新部署，部署對應着修改，修改則意味着風險。

目前有不少用於部署的技術，有的簡單，有的複雜，有的得停機，有的不須要停機便可完成部署。

本文將對目前經常使用的部署方案作一個簡單的總結。

藍綠髮布（Blue/Green Deployment）

1. 定義

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

2. 特色

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

3. 部署過程

• 部署版本 1 的應用（初始的狀態）

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

• 部署版本 2 的應用

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

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

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

4. 小結

      從過程不難發現，在部署的過程當中，咱們的應用始終在線。而且新版本上線的過程當中，並無修改老版本的任何內容，在部署期間，老版本的狀態不受影響，這樣風險很小。而且只要老版本的資源不被刪除，理論上，咱們能夠在任什麼時候間回滾到老版本。

5. 藍綠髮布的注意事項

       當你切換到藍色環境時，須要穩當處理未完成的業務和新的業務。若是你的數據庫後端沒法處理，會是一個比較麻煩的問題。

• 可能會出現須要同時處理微服務架構應用和傳統架構應用的狀況，若是在藍綠部署中協調很差這二者，仍是有可能會致使服務中止。

• 須要提早考慮數據庫與應用部署同步遷移/回滾的問題。

• 藍綠部署須要有基礎設施支持。

• 在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。

6. 優點和不足

• 優點： 升級切換和回退速度很是快。

• 不足： 切換是全量的，若是 V2 版本有問題，則對用戶體驗有直接影響。

                  須要兩倍機器資源。

7. 適用場合

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

• 機器資源有富餘或者能夠按需分配（AWS 雲，或自建容器雲）。

• 
  

灰度發佈

1. 定義

灰度發佈是指在黑與白之間，可以平滑過渡的一種發佈方式。AB Test 就是一種灰度發佈方式，讓一部分用戶繼續用 A，一部分用戶開始用 B，若是用戶對 B 沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到 B 上面來。灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，以保證其影響度。

灰度發佈結構圖

2. A/B Testing

A/B 測試是用來測試應用功能表現的方法，例如可用性、受歡迎程度、可見性等等。 A/B 測試一般用在應用的前端上，不過固然須要後端來支持。

A/B 測試與藍綠部署的區別在於， A/B 測試目的在於經過科學的實驗設計、採樣樣本表明性、流量分割與小流量測試等方式來得到具備表明性的實驗結論，並確信該結論在推廣到所有流量可信；藍綠部署的目的是安全穩定地發佈新版本應用，並在必要時回滾。

3. 金絲雀發佈

咱們日常所說的金絲雀部署也是灰度發佈的一種方式，在原有版本可用的狀況下，同時部署一個新版本應用做爲「金絲雀」服務器來測試新版本的性能和表現，以保障總體系統穩定的狀況下，儘早發現、調整問題。

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

灰度發佈／金絲雀發佈由如下幾個步驟組成：

• 準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。

• 從負載均衡列表中 移除掉「金絲雀」服務器。

• 升級「金絲雀」應用（排掉原有流量並進行部署）。

• 對「金絲雀」應用進行自動化測試。

• 將「金絲雀」服務器從新添加到負載均衡列表中（連通性和健康檢查）。

• 若是「金絲雀」在線使用測試成功，升級剩餘的其餘服務器（不然就回滾）。

       除此以外灰度發佈還能夠設置路由權重，動態調整不一樣的權重來進行新老版本的驗證。

4. 優點和不足

• 優點：用戶體驗影響小，灰度發佈過程出現問題隻影響少許用戶。

• 不足：發佈自動化程度不夠，發佈期間可引起服務中斷。

滾動發佈（Rolling Update Deployment）

在金絲雀發佈基礎上的進一步優化改進，是一種自動化程度較高的發佈方式，用戶體驗比較平滑，是目前成熟型技術組織所採用的主流發佈方式。

1. 定義

滾動發佈：通常是取出一個或者多個服務器中止服務，執行更新，並從新將其投入使用。周而復始，直到集羣中全部的實例都更新成新版本。

2. 特色

這種部署方式相對於藍綠部署，更加節約資源——它不須要運行兩個集羣、兩倍的實例數。咱們能夠部分部署，例如每次只取出集羣的 20% 進行升級。

3. 部署過程

• 滾動式發佈通常先發 1 臺，或者一個小比例，如 2% 服務器，主要作流量驗證用，相似金絲雀 (Canary) 測試。

• 滾動式發佈須要比較複雜的發佈工具和智能 LB，支持平滑的版本替換和流量拉入拉出。

• 每次發佈時，先將老版本 V1 流量從 LB 上摘除，而後清除老版本，發新版本 V2，再將 LB 流量接入新版本。這樣能夠儘可能保證用戶體驗不受影響。

• 一次滾動式發佈通常由若干個發佈批次組成，每批的數量通常是能夠配置的（能夠經過發佈模板定義）。例如第一批 1 臺（金絲雀），第二批 10%，第三批 50%，第四批 100%。每一個批次之間留觀察間隔，經過手工驗證或監控反饋確保沒有問題再發下一批次，因此整體上滾動式發佈過程是比較緩慢的 (其中金絲雀的時間通常會比後續批次更長，好比金絲雀 10 分鐘，後續間隔 2 分鐘)。

• 回退是發佈的逆過程，將新版本流量從 LB 上摘除，清除新版本，發老版本，再將 LB 流量接入老版本。和發佈過程同樣，回退過程通常也比較慢的。

4. 優點和不足

• 優點：用戶體驗影響小，體驗較平滑。

• 不足：發佈和回退時間比較緩慢。

發佈工具比較複雜，LB 須要平滑的流量摘除和拉入能力。

其它發佈方式

上述都是偏傳統的發佈方式，能覆蓋大部分應用發佈場景。針對一些關鍵新功能的上線發佈，或者一些特定的場景，還有一些特殊的發佈方式。

功能開關發佈

利用代碼中的功能開關（Feature Flag/Toggle/Switch）來控制發佈邏輯，通常不須要複雜的發佈工具和智能 LB 配合，是一種相對比較低成本和簡單的發佈方式。

這種方式也是支持現代 DevOps 理念，研發人員能夠靈活定製和自助完成的發佈方式。

功能開關的原理以下圖所示：

1. 部署過程

• 功能開關發佈須要一個配置中心或者開關中心這樣的服務支持，例如攜程的 Apollo 配置中心或者開源的 FF4J，這些都支持開關發佈。業界還有專門的功能開關 SaaS 服務，例如 LaunchDarkly。經過配置中心，運維或研發人員能夠在運行期動態配置功能開關的值。固然，功能開關發佈只是配置中心的一種使用場景，配置中心還能支持其它不少動態配置場景。

• 功能開關服務通常提供客戶端 SDK，方便開發人員集成。在運行期，客戶端 SDK 會同步最新的開關值，技術實現有推方式 (push)，也有拉方式 (pull)，或者推拉結合方式。

• 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中，新功能隱藏在開關後面，若是開關沒有打開，則走老代碼邏輯，若是開關打開，則走新代碼邏輯。

• 技術實現上能夠理解爲一個簡單的 if/else 邏輯。

• 應用上線後，開關先不打開，而後運維或研發人員經過開關中心打開新功能，通過流量驗證新功能沒有問題，則發佈完成；若是有問題，則隨時能夠經過開關中心切回老功能邏輯。

2. 優點和不足

• 優點：升級切換和回退速度很是快。

                 相對於複雜的發佈工具，實施比較簡單，成本相對低廉。
                 研發可以靈活定製發佈邏輯，支持 DevOps 自助發佈。

• 不足：切換是全量的，若是 V2 版本有問題，則對用戶體驗有直接影響。

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

影子測試

對於一些涉及核心業務的遺留系統的升級改造，爲了確保萬無一失，有一種稱爲影子測試的大招，採用比較複雜的流量複製、回放和比對技術實現。

下面是影子測試的一個樣例架構圖：

1. 部署過程

      影子測試通常適用於遺留系統的等價重構遷移，例如 .net 轉 Java，或者 SQLServer 數據庫升級爲 MySQL 數據庫，且外部依賴不能太多，不然須要開發不少 mock，測試部署成本會很高，且比對測試更加複雜和不穩定。

• 目標實現老的 legacy 服務遷移升級到新的 experimental 服務。

• 測試開始前，須要在測試環境部署一份 legacy 服務和 experimental 服務，同時將生產數據庫複製兩份到測試環境。同時須要將生產請求日誌收集起來，通常能夠經過 kafka 隊列收集，而後經過相似 goreplay 這樣的工具，消費 kafka 裏頭的請求日誌，複製回放，將請求分發到 legacy 服務和 experimental 服務，收到響應後進行比對，若是全部響應比對成功，則能夠認爲 legacy 服務和 experimental 服務在功能邏輯上是等價的；若是有響應比對失敗，則認爲二者在功能邏輯上不等價，須要修復 experimental 並從新進行影子測試，直到所有比對成功。根據系統複雜度和關鍵性不一樣，比對測試時間短的可能須要幾周，長的可達半年之久。

• 影子測試由於旁路在獨立測試環境中進行，能夠對生產流量徹底無影響。

2. 優點和不足

• 優點：對生產用戶體驗徹底無影響。

                 可使用生產真實流量進行測試（複製比對）。

• 不足：搭建複雜度很高，技術門檻高，數據庫的導出複製是難點。

                 外部依賴不能太多，不然測試部署成本很高，且比對測試更加複雜和不穩定。