歡迎光臨
每天分享高質量文章

應用部署的六種策略

目前有各種各樣的技術來將新應用部署到生產環境,所以權衡對系統和終端用戶的影響降至最少,選擇正確的方式是非常重要的。

本文將著重討論如下部署策略:

  • 重建部署:版本A下線後版本B上線

  • 滾動部署(滾動更新或者增量發佈):版本B緩慢更新並替代版本A

  • 藍綠部署:版本B並行與版本A發佈,然後流量切換到版本B

  • 金絲雀部署:版本B向一部分用戶發佈,然後完全放開

  • A/B部署布:版本B只向特定條件的用戶發佈

  • 影子部署:版本B接受真實的流量請求,但是不產生響應

我們來看一下每個策略最適合哪種用戶使用場景。為了簡化,我們使用Kubernetes,並用Minikube進行例子演示。每個策略的配置例子和詳細步驟都可以在這個Git倉庫[1]上找到。


重建策略

重建策略是一個冗餘的方式,它包含下線版本A,然後部署版本B。這個方式意味著服務的宕機時間依賴於應用下線和啟動耗時。

優點:

  • 便於設置

  • 應用狀態完整更新

缺點:

  • 對用戶影響很大,預期的宕機時間取決於下線時間和應用啟動耗時


滾動部署

滾動部署策略是指通過逐個替換應用的所有實體,來緩慢發佈應用的一個新版本。通常過程如下:在負載調度後有個版本A的應用實體池,一個版本B的實體部署成功,可以響應請求時,該實體被加入到池中。然後版本A的一個實體從池中刪除並下線。

考慮到滾動部署依賴於系統,可以調整如下引數來增加部署時間:

  • 並行數,最大批量執行數:同時發佈實體的數目

  • 最大峰值:考慮到當前實體數,實體可以加入的數目

  • 最大不可用數:在滾動更新過程中不可用的實體數

優點:

  • 便於設置

  • 版本在實體間緩慢發佈

  • 對於能夠處理資料重平衡的有狀態應用非常方便

缺點:

  • 發佈/回滾耗時

  • 支持多個API很困難

  • 無法控制流量

藍綠部署

藍綠部署策略與滾動部署不同,版本B(綠)同等數量的被併排部署在版本A(藍)旁邊。當新版本滿足上線條件的測試後,流量在負載均衡層從版本A切換到版本B。

優點:

  • 實時發佈、回滾

  • 避免版本衝突問題,整個應用狀態統一一次切換

缺點:

  • 比較昂貴因為需要雙倍的資源

  • 在釋放版本到生產環境之前,整個平臺的主流程測試必須執行

  • 處理有狀態的應用很棘手


金絲雀部署

金絲雀部署是指逐漸將生產環境流量從版本A切換到版本B。通常流量是按比例分配的。例如90%的請求流向版本A,10%的流向版本B。

這個技術大多數用於缺少足夠測試,或者缺少可靠測試,或者對新版本的穩定性缺乏信心的情況下。

優點:

  • 版本面向一部分用戶發佈

  • 方便錯誤評估和性能監控

  • 快速回滾

缺點:

  • 發佈緩慢


A/B測試

A/B測試是指在特定條件下將一部分用戶路由到新功能上。它通常用於根據統計來制定商業決策,而不是部署策略。然而,他們是相關的,可以在金絲雀部署方式上添加額外功能來實現,所以我們這裡簡要介紹一下。

這個技術廣泛用於測試特定功能的切換,併發布使用占大部分的版本。

下麵是可以用於在版本間分散流量的條件:

  • 瀏覽器cookie

  • 查詢引數

  • 地理位置

  • 技術支持:瀏覽器版本、屏幕尺寸、操作系統等

  • 語言

優點:

  • 多個版本並行運行

  • 完全控制流量分佈

缺點:

  • 需要智慧負載均衡

  • 對於給定的會話,很難定位問題,分佈式跟蹤是必須的

影子部署

影子部署是指在版本A旁邊發佈版本B,將版本A進來的請求同時分發到版本B,同時對生產環境流量無影響。這是測試新特征在產品負載上表現的很好用的方式。當滿足上線要求後,則觸發發佈新應用。

這個技術配置非常複雜,而且需要特殊條件,尤其是分出請求。例如一個購物車平臺,如果你想影子測試支付服務,你可能最終會是用戶為他們的訂單支付兩次。這種情況下,可以通過創建一個仿真的服務來重覆響應用戶的請求。

優點:

  • 可以使用生產環境流量進行性能測試

  • 對用戶無影響

  • 直到應用的穩定性和性能滿足要求後才發佈

缺點:

  • 雙倍資源,成本昂貴

  • 不是真實用戶測試,可能出現誤導

  • 配置複雜

  • 某種情況下需要模擬服務


總結

部署應用有很多種方法,實際採用哪種方式取決於需求和預算。當發佈到開發或者模擬環境時,重建或者滾動部署是一個好選擇。當發佈到生產環境時,滾動部署或者藍綠部署通常是一個好選擇,但是新平臺的主流程測試是必須的。

藍綠部署和影子部署對預算有更高的要求,因為需要雙倍資源。如果應用缺乏測試或者對軟體的功能和穩定性影響缺乏信心,那麼可以使用金絲雀部署或者AB測試或者影子發佈。如果業務需要根據地理位置、語言、操作系統或者瀏覽器特征等這樣引數來給一些特定的用戶測試,那麼可以採用AB測試技術。

最後但並不是最不重要的,影子發佈很複雜,且需要額外工作來模擬響應分支流量請求,當可變操作(郵件、銀行等)呼叫外部依賴時這是必須的,這個技術在升級新資料庫是非常有用,使用影子流量來監控負載下的系統性能。

下表可以幫助你選擇正確的策略:

取決於雲服務提供商和平臺,如下文件是理解部署的很好開始:

  • Amazon Web Services[2]

  • Docker Swarm[3]

  • Google Cloud[4]

  • Kubernetes[5]

我希望這是有用的,如果有任何問題或者反饋,可以在下麵評論。

相關鏈接:

  1. https://github.com/ContainerSolutions/k8s-deployment-strategies

  2. http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html

  3. https://docs.docker.com/engine/swarm/swarm-tutorial/rolling-update/

  4. https://cloud.google.com/sdk/gcloud/reference/beta/compute/instance-groups/managed/rolling-action/replace

  5. https://kubernetes.io/docs/tutorials/kubernetes-basics/update-intro/

原文鏈接:https://thenewstack.io/deployment-strategies/

基於Kubernetes的容器雲平臺實踐培訓

本次培訓包含:Kubernetes核心概念;Kubernetes集群的安裝配置、運維管理、架構規劃;Kubernetes組件、監控、網絡;針對於Kubernetes API接口的二次開發;DevOps基本理念;Docker的企業級應用與運維等,點擊識別下方二維碼加微信好友瞭解具體培訓內容

點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂