微服務 | 推薦幾種最佳「發布」實踐方式

• 2020 年 3 月 13 日
• 筆記

在項目研發迭代的過程中，不可避免需要對「應用服務部署上線」。而對於應用程式升級面臨最大挑戰是新舊業務切換的同時還要保證系統不間斷提供服務。特別是微服務盛行的今天，對服務發布的粒度、發布策略控制更佳尤為重要。

最近幾年，市面上流行了很多與顏色相關的部署、發布方法，常見的比如有：藍綠部署、紅黑部署、灰度發布（金絲雀發布）、滾動發布等。接下來，就和大家聊一聊這幾種帶「色」的發布方法以及他們之間的區別和優缺點。

從部署到發布的幾個階段

部署、發布、上線這幾個名詞，其實區分不太明顯，我們平時在討論服務部署上線時，也經常會混用。在這裡，先給大家明確區分一下這幾個階段。

• 部署（deploy），指的是我們把一個程式碼包拷貝到伺服器上運行，但並不把它暴露給用戶，也就是並不給用戶提供服務。這個階段比較耗時，但因為還沒有面向用戶，所以風險很小。
• 發布（release），是把部署好的服務暴露給用戶的過程，也就是開始真正上線服務用戶了。這個過程可以通過負載均衡的切換很快實現，但風險很大，一旦出現問題損失就會比較大。
• 發布後（post-release），指的是服務完全上線以後的階段。因為產品已經完全上線，我們的主要工作不再是預防，而是變成了監控和降低損失。

幾種帶「色」的部署方式定義

我們再來看看藍綠部署（Blue-green Deployment）、紅黑部署（Red-black Deployment）和灰度發布（Gray Release ，或 Dark Launch）、滾動發布（Rolling Update）的定義和流程。

1、藍綠部署

藍綠部署，是採用兩個分開的集群對軟體版本進行升級的一種方式。它的部署模型中包括一個藍色集群 A 和一個綠色集群 B，在沒有新版本上線的情況下，兩個集群上運行的版本是一致的，同時對外提供服務。

系統升級時，藍綠部署的流程是：

• 首先，從負載均衡器列表中刪除集群 A，讓集群 B 單獨提供服務。
• 然後，在集群 A 上部署新版本。

• 接下來，集群 A 升級完畢後，把負載均衡列表全部指向 A，並刪除集群 B，由 A 單獨提供服務。

• 在集群 B 上部署完新版本後，再把它添加回負載均衡列表中。

這樣，我們就完成了兩個集群上所有機器的版本升級。

細心的讀者，從上述的部署流程中，也能發現，藍綠部署它的優點在於發布策略簡單、對於用戶來說無感知，可以實現升級平滑過渡。但它的缺點也很明顯：需要準備正常業務使用資源的兩倍以上伺服器，需要投入較大的資源成本。當然對於不差錢、追求服務穩定性的公司而言，較為推薦這種部署模式。

2、紅黑部署

紅黑部署是Netflix採用的部署手段，Netflix的主要基礎設施是在AWS上，它與藍綠部署類似，紅黑部署也是通過兩個集群完成軟體版本的升級。

當前提供服務的所有機器都運行在紅色集群 A 中，當需要發布新版本的時候，具體流程是這樣的：

• 先在雲上申請一個黑色集群 B，在 B 上部署新版本的服務；
• 等到 B 升級完成後，我們一次性地把負載均衡全部指向 B；
• 把 A 集群從負載均衡列表中刪除，並釋放集群 A 中所有機器。

這樣就完成了一個版本的升級。

可以看到，與藍綠部署相比，紅黑部署只不過是充分利用了雲計算的彈性伸縮優勢，從而獲得了兩個收益：一是，簡化了流程；二是，避免了在升級的過程中，由於只有一半的伺服器提供服務，而可能導致的系統過載問題。

3、灰度發布

灰度發布，也被叫作金絲雀發布。與藍綠部署、紅黑部署不同的是，灰度發布屬於增量發布方法。也就是說，服務升級的過程中，新舊版本會同時為用戶提供服務。

灰度發布的具體流程是這樣的：在集群的一小部分機器上部署新版本，給一部分用戶使用，以測試新版本的功能和性能；確認沒有問題之後，再對整個集群進行升級。簡單地說，灰度發布就是把部署好的服務分批次、逐步暴露給越來越多的用戶，直到最終完全上線。

之所以叫作灰度發布，是因為它介於黑與白之間，並不是版本之間的直接切換，而是一個平滑過渡的過程。

AB Test就是一種灰度發布方式，讓一部分用戶繼續用A，一部分用戶開始用B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發布的一種方式。

之所以又被叫作金絲雀發布，是因為金絲雀對瓦斯極其敏感，17 世紀時英國礦井工人會攜帶金絲雀下井，以便及時發現危險。這就與灰色發布過程中，先發布給一部分用戶來測試相似，因而得名。

對於灰度發布來說，它的優點在於如果前期出問題影響範圍很小，相對用戶體驗也少；可以做到及時發現、及時調整問題，影響範圍可控。但是採取這種模式對自動化以及運維監控能力的要求非常高。

4、滾動發布

滾動發布是指每次只升級一個或多個服務，升級完成後加入生產環境，不斷執行這個過程，直到集群中的全部舊版本升級新版本。

• 紅色：正在更新的實例
• 藍色：更新完成並加入集群的實例
• 綠色：正在運行的實例

這種部署方式相對於藍綠部署，更加節約資源——它不需要運行兩個集群、兩倍的實例數。我們可以部分部署，例如每次只取出集群的20%進行升級，比較節約資源，但同時缺點也很明顯：採用滾動發布方式部署時，沒有一個確定OK的環境。如果使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動發布，我們無法確定。並且一旦發布過程出現問題，需要回滾，回滾過程非常困難。

在實際工作當中，升級過程中需要保持服務的連續性、穩定，對外界無感知是幾個基本的要求。在生產上選擇哪種部署方法最合適？這取決於哪種方法最適合你的業務和技術需求。

如果你們運維自動化能力儲備不夠，肯定是越簡單越好，建議藍綠髮布，如果業務對用戶依賴很強，建議灰度發布。如果是K8S平台，滾動更新是現成的方案，建議先直接使用。

好了，以上就是當前市面常見的幾種有顏色的部署發布方式。

希望這篇文章能幫到你！如果喜歡，麻煩幫忙點一下好看或轉發朋友圈，更多實用乾貨文章請關注我們。

聲明：封面或正文部分圖片來源於網路，如有侵權，請聯繫刪除。

END