近些年，“DevOps”非常熱門，最近，我們團隊討論了部署最佳實踐、熱部署、回滾等，當提到藍綠部署時，大家表現出濃烈的興趣。

藍綠部署已經在像亞馬遜這樣的地方實踐了 10 多年。它們是一種安全、經過驗證的方法。現在，藍綠部署不是靈丹妙藥，但它們有一定的用處。

其實還有A/B 測試，甚至 Canary 測試，在所有微服務、DevOps和云原生交流中，有很多關于它們的討論，因此，我簡單歸納了它們的區別。

藍綠部署

Blue Green Deployments的詳細介紹請參閱Martin Fowler 關于藍綠部署的鏈接（http://martinfowler.com/bliki/BlueGreenDeployment.html）。它給出了總體要點。

它基本上是一種以可預測的方式發布應用程序的技術，目的是減少與發布相關的任何停機時間。這是在發布前為您的應用做好準備的一種快速方式，如果您發現問題，也可以快速回滾。

簡單地說，您有兩個相同的環境（基礎架構），其中“綠色”環境托管當前的生產應用程序（例如 app1 version1、app2 version1、app3 version1）：

圖片

現在，當您準備對 app2 進行更改并將其升級到 v2 時，您將在“藍色環境”中進行。在該環境中，您部署應用程序的新版本、運行冒煙測試和任何其他測試（包括那些用于運行/啟動操作系統、緩存、CPU 等的測試）。當事情看起來不錯時，您將負載均衡器/反向代理/路由器更改為指向藍色環境：

圖片

您監視由于發布而導致的任何故障或異常。如果一切看起來不錯，您最終可以關閉綠色環境并使用它來發布任何新版本。如果沒有，您可以通過將負載均衡器指向回快速回滾到綠色環境。

理論上聽起來不錯。但是有一些事情需要注意。

? 在綠色環境中長期運行的交易。當您切換到藍色時，您必須優雅地處理那些未完成的交易以及新的交易。如果您的數據庫后端無法處理此問題，這也會變得很麻煩（見下文）；

? 企業部署通常不適合“微服務”風格的部署——也就是說，你可能有微服務風格的應用程序和一些傳統的、難以更改的應用程序一起工作的混合體。為藍綠部署在兩者之間進行協調仍然可能導致停機；

? 數據庫遷移可能會變得非常棘手，并且必須與應用程序部署一起遷移/回滾。有很好的工具和技術可以做到這一點，但在傳統 RDBMS、NoSQL 和文件系統支持的數據庫的環境中，這些事情確實需要提前考慮；盲目地說你在做藍綠部署沒有任何幫助——實際上可能會造成傷害。

? 你需要有基礎設施來做到這一點；

? 如果您嘗試在非隔離的基礎架構（VM、Docker 等）上執行此操作，您將面臨破壞藍色和綠色環境的風險；

正如我所說，有一些很好的技術可以克服這些挑戰并使這種部署方式非常有效，包括插入到持續部署管道中，但不要輕易跳入其中。

A/B測試

A/B 測試不是藍綠部署，有些人會混淆這一點。A/B 測試是一種出于各種原因（例如可用性、流行度、引人注目度等）以及這些因素如何影響底線而測試應用程序功能的方法。它通常與應用程序的 UI 部分相關聯，但當然需要后端服務才能執行此操作。您可以使用應用程序級開關（即知道何時顯示某些 UI 控件的智能邏輯）、靜態開關（在應用程序中）以及使用 Canary 版本（如下所述）來實現這一點。

圖片

藍綠部署和 A/B 測試之間的區別在于 A/B 測試用于測量應用程序中的功能。藍綠部署是關于安全地發布新軟件并按預期回滾。您顯然可以將它們結合起來：使用藍綠部署在可用于 A/B 測試的應用程序中部署新功能。

云雀發布

最后，Canary發布是一種將您的應用程序的新版本發送到生產環境的方式，它扮演“云雀”的角色，以了解它將如何執行（與其他應用程序、CPU、內存、磁盤使用情況等集成） ）。這是另一種發布策略，可以緩解以下事實：無論您在較低環境中進行的測試級別如何，您仍然會在生產中遇到一些錯誤。云雀版本讓您在完全釋放扳機之前先試水。

圖片

您獲得的反饋越快，部署失敗或謹慎進行的速度就越快。出于與藍綠部署相同的一些原因，請注意上述事項；即，數據庫更改仍然會絆倒您。

概括

無論您是否使用特定的云技術，都可以實施所有這些策略。但正如您想象的那樣，Docker和Kubernetes等技術對實施這些策略非常有幫助（如果甚至沒有內置規定）。例如，OpenShift和Fabric8通過提供使用這些技術所需的工具而無需擔心底層細節，從而大大簡化了使用 Docker 和 Kubernetes。

原文鏈接：https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/