應用部署的六種策略

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

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

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

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

缺點：

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

缺點：

藍綠部署

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

缺點：

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

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

缺點：

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

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

優點：

缺點：

影子部署

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

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

優點：

缺點：

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

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

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

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

取決於雲服務提供商和平臺，如下檔案是理解部署的很好開始：

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

相關連結：

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/