重建部署 (Recreate)滾動部署 (Ramped / Rolling-update)藍綠部署 (Blue / Green)金絲雀部署 (Canary)A / B 測試 (A / B Testing)
重建部署 (Recreate)
- 成本偏沈重
- 將舊版本完全下線後才開始上線新版
優點：
- 便於設定。
- 線上只會同時運行一種版本。
- 部署過程中不會造成主機額外負擔。
- 對使用者影響大，預期的停機時間取決於下線時間和啟動服務的耗時。
缺點：
- 對使用者影響大，預期的停機時間取決於下線時間和啟動服務的耗時。
滾動部署 (Ramped / Rolling-update)
- 容器會如同水漸漸地往傾斜的地方, 聚集一樣的更新版本
- 能緩慢平和的釋出新版本，速度可以調整
- 最大執行數：可以同時釋出的服務數目。
- 最大峰值：升級過程中最多可以比原先設定所多出的服務數量。
- 最大不可用數：最多可以有幾個服務處在無法服務的狀態。
優點：
- 相較於藍綠部署更加節省資源。
- 便於設定，服務不中斷。
缺點：
- 釋出與回滾耗時，想想當我們有 100 個服務，每次需要花五分鐘更新其中 10 個，當更新到第 80 個時發現錯誤需要緊急回滾的情況？
- 部署期間新舊兩版服務都會同時在線上運作，無法控制流量且噴錯時除錯困難高。
藍綠部署 (Blue / Green)
- 先將新版本的服務完整的開啟
- 新版本滿足上線條件的測試後，才將流量在負載均衡層從舊版本切換到新版本
優點：
- 實時釋出、回滾。
- 避免新舊版本衝突，整個過程同時只會有一個版本存在。
- 服務不中斷。
缺點：
- 部署完成前需要雙倍的資源要求所增加的開銷及成本。有時新版本通過不了測試時，舊版本將持續運行到新版本通過為止。
- 當切換到新版本的瞬間，如果有未處理完成的業務將會是比較麻煩的問題。
金絲雀部署 (Canary)
先推廣到一小部分的使用者，驗證沒有問題後才完成部署
優點：
- 方便除錯以及監控。
- 只向一小部分使用者釋出。
- 快速回滾、快速迭代。
缺點：
- 完整釋出期漫長。
- 只能適用於相容迭代的方式，如果是大版本不相容就沒辦法使用這種方式了。
