############

根據 2017 年的 DevOps 發展報告，高效能組織和低效能組織在軟體交付的效率上有數量級上的差異。技術組織的軟體交付能力是一種綜合能力，涉及眾多環節，其中釋出是尤為重要的環節。

作為技術人員，大家可能聽說過“滾動釋出”和“藍綠髮布”等術語，但是很多人並不清楚這些術語背後的原理。本文試圖總結當前主流的釋出策略，每個的優劣，適用性，讓開發人員特別是架構師對現代釋出技術有
一個更為清晰全面的認識，讓大家能夠根據自己的企業上下文，對釋出策略做出正確的選型和實踐。

一、單伺服器釋出

先解釋下單伺服器組的概念，早先我們機器資源比較緊張，不像現在雲端計算和虛擬化（包括容器技術）這麼發達，所以應用機器基本是預先靜態分配好的（一般由運維負責分配），原來應用 A 住在這 n 臺機器上，
那麼下次升級釋出的應用 A 也住在這 n 臺機器上，所以稱為單伺服器組釋出方式。

1.1蠻力釋出(單伺服器組) -蠻力釋出會引入服務中斷時間

如下圖所示，這種釋出方式比較簡單粗暴，有點像我們傳統的軟體升級方式，主要靠手工完成，先將老版本 V1 全部下掉，再將新版本發到機器上去。這種方式會引入服務中斷（停機），在開發測試環境是可行的，
但對於生產環境釋出，其會直接影響使用者的使用體驗，這種方式一般是不建議的。
                                               釋出前

                                          釋出後

1）優勢和不足
   優勢：
      簡單成本低
   不足：
      服務中斷使用者受影響，出了問題回退也慢

2）適用場合：
   a).開發測試環境
   b).非關鍵應用（使用者影響面小）
   c)初創公司什麼都缺，找夜深人靜使用者訪問量小的時間幹

3）流量模式

1.2金絲雀釋出(單伺服器組)【國內常稱灰度測試】 -少量金絲雀先接受流量，再全量釋出

在蠻力釋出基礎上的一種簡單改進發布方式，目前仍然是不少成長型技術組織的主流釋出方式。單伺服器組下的金絲雀釋出的簡化步驟如下圖所示：
釋出前

先發布一臺金絲雀(也可以先發布兩臺，可以設定允許多少流量先進入金絲雀釋出服務)

剩下服務全部發完

1）實踐要點
   金絲雀釋出一般先發 1 臺，或者一個小比例，例如 2% 的伺服器，主要做流量驗證用，也稱為金絲雀 (Canary) 測試（國內常稱灰度測試）。以前曠工開礦下礦洞前，先會放一隻金絲雀進去探是否有有毒
氣體，看金絲雀能否活下來，金絲雀釋出由此得名。簡單的金絲雀測試一般通過手工測試驗證，複雜的金絲雀測試需要比較完善的監控基礎設施配合，通過監控指標反饋，觀察金絲雀的健康狀況，作為後續釋出或
回退的依據。
   如果金絲測試通過，則把剩餘的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗，則直接回退金絲雀，釋出失敗。

2）優勢和不足
   優勢：
      使用者體驗影響小，金絲雀釋出過程出現問題隻影響少量使用者
   不足：
      釋出自動化程度不夠，釋出期間可引發服務中斷


3）適用場合：
   a).對新版本功能或效能缺乏足夠信心
   b).使用者體驗要求較高的網站業務場景
   c).缺乏足夠的自動化釋出工具研發能力

4）流量模式

1.3滾動式釋出(單伺服器組) -滾動式釋出，流量平滑過渡

在金絲雀釋出基礎上的進一步優化改進，是一種自動化程度較高的釋出方式，使用者體驗比較平滑，是目前成熟型技術組織所採用的主流釋出方式。單伺服器組下的滾動釋出的簡化步驟如下圖所示：

                                           釋出前

               釋出中，先發一臺金絲雀

釋出中，再發若干臺

直到全部發完

1）實踐要點
   a).滾動式釋出一般先發 1 臺，或者一個小比例，如 2% 伺服器，主要做流量驗證用，類似金絲雀 (Canary) 測試。
   b).滾動式釋出需要比較複雜的釋出工具和智慧 LB，支援平滑的版本替換和流量拉入拉出。
   c).每次釋出時，先將老版本 V1 流量從 LB 上摘除，然後清除老版本，發新版本 V2，再將 LB 流量接入新版本。這樣可以儘量保證使用者體驗不受影響。
   d).一次滾動式釋出一般由若干個釋出批次組成，每批的數量一般是可以配置的（可以通過釋出模板定義）。例如第一批 1 臺（金絲雀），第二批 10%，第三批 50%，第四批 100%。每個批次之間留觀察
      間隔，通過手工驗證或監控反饋確保沒有問題再發下一批次，所以總體上滾動式釋出過程是比較緩慢的 (其中金絲雀的時間一般會比後續批次更長，比如金絲雀 10 分鐘，後續間隔 2 分鐘)。
   e).回退是釋出的逆過程，將新版本流量從 LB 上摘除，清除新版本，發老版本，再將 LB 流量接入老版本。和釋出過程一樣，回退過程一般也比較慢的。
   f).滾動式釋出國外術語通常叫 Rolling Update Deployment。

2）優勢和不足
   優勢：
      使用者體驗影響小，體驗較平滑
   不足：
      釋出和回退時間比較緩慢
      釋出工具比較複雜，LB 需要平滑的流量摘除和拉入能力

3）適用場合：
   a).使用者體驗不能中斷的網站業務場景
   b).有一定的複雜釋出工具研發能力；

4）流量模式

二、雙伺服器組釋出

隨著雲端計算和虛擬化技術的成熟，特別是容器等輕量級虛擬化技術的引入，計算資源受限和申請緩慢問題已經逐步解決，可以做到彈性按需分配。為一次釋出分配兩組伺服器，一組執行現有的 V1 老版本，一組
執行待上線的 V2 新版本，再通過 LB 切換流量方式完成釋出，這就是所謂的雙伺服器組釋出方式。

2.1藍綠髮布(雙伺服器組) -藍綠髮布一次完成流程切換

藍綠髮布僅適用於雙伺服器組釋出，可以認為是對蠻力釋出的一種簡單優化釋出方式。簡化過程如下圖所示：

1）實踐要點
   V1 版本稱為藍組，V2 版本稱為綠組，釋出時通過 LB 一次性將流量從藍組直接切換到綠組，不經過金絲雀和滾動釋出，藍綠髮布由此得名；
   出現問題回退也很直接，通過 LB 直接將流量切回藍組。
   釋出初步成功後，藍組機器一般不直接回收，而是留一個待觀察期，視具體情況觀察期的時間可長可短，觀察期過後確認釋出無問題，則可以回收藍組機器。

2）優勢和不足
   優勢：
      升級切換和回退速度非常快
   不足：
      切換是全量的，如果 V2 版本有問題，則對使用者體驗有直接影響；
      需要兩倍機器資源；

3）適用場合：
   對使用者體驗有一定容忍度的場景
   機器資源有富餘或者可以按需分配（AWS 雲，或自建容器雲）
   暫不具備複雜滾動釋出工具研發能力；

4）流量模式

2.2金絲雀釋出(雙伺服器組)

對藍綠部署的一種簡單優化，釋出時先從綠組拉入 1 臺金絲雀，待金絲雀驗證通過再發全量。對比藍綠髮布，該釋出方式的優勢是有一個生產流量的金絲雀驗證過程，可以減輕 V2 可能有問題的風險和影響面。
簡化釋出過程如下圖所示：

2.3滾動式釋出(雙伺服器組) -滾動式釋出，流量平滑過渡

滾動式釋出是對上面的藍綠和金絲雀釋出的進一步優化，按批次增量滾動釋出，提供更平滑的使用者體驗。

1）實踐要點
   a).釋出前先申請一批新伺服器，數量一般和 V1 版本相同，將 V2 版本應用釋出到新伺服器上。例如如果在 AWS 雲上，則可以直接呼叫 API 申請一批新 VM，如果用容器雲 Kubernetes，則可以直接啟
     動一批新容器（使用 V2 版本容器映象）。
   b).一般會先通過 LB 拉入 1 臺 V2 版本的機器，這臺機器也相當於金絲雀，用於流量驗證。
   c).逐步按批次完成釋出，每批只需要通過 LB 拉入 V2 版本，再拉出對應數量的 V1 版本。批次之間留有觀察間隔，通過手工或監控反饋確保沒有問題再繼續釋出。
   d).釋出有問題回退很快，直接通過 LB 將流量切回 V1 即可。
   e).完成釋出後，一般 V1 版本要保留觀察以備萬一，比如留 1 天，1 天后沒有問題則回收 V1 機器資源。

2）優勢和不足
   優勢：
      使用者體驗影響小；
      升級切換和回退（rollback）速度比單伺服器組滾動釋出要快，LB 切流量即可；
   不足：
      需要兩倍機器資源；
      釋出工具比較複雜，LB 需要流量切換能力

3）適用場合：
   使用者體驗不能中斷的網站業務場景
   機器資源有富餘或者可以按需分配（AWS 雲，或自建容器雲）
   有一定的釋出工具研發能力；

4）流量模式

原文地址：http://www.54php.cn/default/224.html?source=cnblogs

############