作為一名 Java程序員，部署生產環境的服務器是一項基本能力要求，那么，如何部署才能做到業務無感？選擇什么樣的部署策略，才能將生產事故降到最低？今天我們就來一起聊聊5種常用的部署策略。

Big Bang Deploy

定義

Big Bang Deployment，中文翻譯為：大爆炸部署，也就是我們通常說的全量部署。它是指在一個較短的時間內將新系統或新版本全部部署并替換舊系統，使其立即對所有用戶生效。

原理

Big Bang Deployment的原理很簡單，如下圖，只需要把服務器全量部署，部署前為服務V1.0，服務部署后就全量變成了V2.0。

優點

• 快速部署： Big Bang Deployment可以在較短的時間內完成整個系統的部署，從而迅速推出新功能或更新。這種快速部署有助于滿足緊迫的業務需求，讓用戶盡快獲得新功能的好處。
• 突破點： 將新系統一次性部署可以帶來一個重大的突破點。一旦部署成功，所有用戶都能立即使用新系統，從而為企業帶來顯著的商業價值和競爭優勢。
• 零停機時間： 由于所有用戶都在同一時間切換到新系統，舊系統可以在部署后立即停用，從而減少了整個過程中的停機時間。
• 簡化維護： 在部署后，維護人員只需關注新系統的運行和維護，而無需再維護舊系統，這簡化了維護流程和資源投入。

缺點

• 高風險： Big Bang Deployment 由于一次性全量部署，風險相對較高。如果在部署過程中發生嚴重錯誤或問題，整個系統可能會出現故障甚至是癱瘓，影響所有用戶。
• 回滾復雜： 由于一次性部署，如果在新系統中出現嚴重問題，需要回滾到舊系統可能會非常復雜和耗時，尤其是如果數據已經在新系統中被修改，回滾可能會導致數據丟失或一致性問題。
• 用戶接受度： 用戶可能對突然的系統變化感到困惑和不適應，尤其是如果新系統的用戶界面和功能與舊系統有較大差異。這可能會導致用戶體驗下降，甚至流失用戶。
• 測試挑戰： 在短時間內完成全面的測試和驗證是一項挑戰，可能導致某些問題未被發現，從而在部署后才被用戶發現，增加修復的成本和復雜性。

適用場景

只有一臺服務器：有些使用量比較小的業務，為了成本，只需要部署一臺服務器，因此，當需要部署新功能時，就可以采用該策略。

復雜的數據庫升級：如果數據庫需要進行復雜的業務升級，已經到了不得不使用全量部署策略。

總體而言，Big Bang Deployment是一種迅速推出新系統的方法，適用于緊急的業務需求，但風險較高。在實施前需要充分的計劃、測試和備份策略，以減輕潛在的風險。對于一些重要業務功能，采用漸進式的部署策略可能更為保守和安全。

Rolling Deploy

定義

Rolling Deployment，中文翻譯為：滾動部署。與 Big Bang Deployment 相對，它指的是在部署新系統或新版本時，逐步將新版本部署到一部分用戶或服務器上，然后再逐步擴大范圍，直至所有用戶或服務器都更新到新版本。

原理

• 準備新版本：在進行滾動部署之前，團隊需要準備好新版本的應用程序代碼、配置和資源。
• 劃分批次：團隊將服務器分成多個批次（通常是一組服務器），每個批次都將逐步進行更新。
• 停止舊版本：從第一個批次開始，停止舊版本的服務器，使其不再提供服務。
• 部署新版本：在停止的舊版本服務器上部署新版本的應用程序代碼，并啟動新版本。
• 驗證新版本：確保新版本的服務器正常運行，并在沒有問題的情況下繼續進行下一批次的部署。
• 逐步推進：逐步重復步驟 3~5，依次更新下一個批次的服務器，直到所有服務器都部署了新版本。
• 完成部署：一旦所有服務器都成功部署了新版本，滾動部署就完成了。

如下圖：在所有的服務器中，我們將 2臺部署成新服務V2.0，當用戶的請求到達新服務上得不到響應時，可以快速回滾到V1.0，這樣就可以快速止損。當用戶請求到達新服務V2.0能收到預期響應，可以繼續下一批服務的發布。

優點

• 降低風險：滾動部署通過逐步部署新版本，降低了整個系統的風險。如果在部署過程中發現問題，可以及時停止部署，從而減少對整個系統的影響。
• 易于回滾：由于部署是逐步進行的，如果在新版本中發現問題，可以快速回滾到上一個穩定的版本。這減少了回滾所需的復雜性和風險。
• 逐步學習：滾動部署允許一部分用戶或服務器先使用新版本，有助于逐步了解新功能和系統的表現，從而及時收集用戶反饋和修復潛在問題。
• 資源控制：滾動部署允許在部署過程中逐步增加資源，例如服務器數量或網絡帶寬，以確保整個部署過程的穩定性和性能。

缺點

• 部署時間較長：相對于Big Bang Deployment，滾動部署需要更長的時間才能將新版本完全部署到所有用戶或服務器上。這可能導致新功能的推出相對較慢，無法立即滿足所有用戶的需求。
• 復雜性：滾動部署需要更多的規劃和管理，因為需要確保新版本與舊版本之間的兼容性，并在部署過程中及時檢測和解決問題。
• 版本管理：在滾動部署中，可能需要同時維護多個版本的系統，這增加了版本管理和維護的復雜性。
• 用戶分流：在部署過程中，用戶可能會分流在不同版本的系統中，這可能導致數據和用戶體驗方面的一些問題，例如數據不一致或功能差異。

適用場景

Rolling deploy是一種較為穩健和逐步的部署策略，適用于對風險敏感且需要更好控制部署過程的情況。它可以減少系統故障的風險，但需要更多的時間和資源來確保順利完成部署，并在整個過程中維持系統的穩定性和用戶體驗。

Blue-Green Deploy

定義

Blue-Green Deployment，中文翻譯為：藍綠部署，它允許在生產環境中同時維護兩個相同的系統版本：一個為當前生產版本（藍色），另一個為新版本（綠色）。

原理

• 初始狀態：在初始狀態下，藍色環境是活動的，承載著當前的生產版本應用程序，而綠色環境是非活動的，不對用戶提供服務。
• 部署新版本：在進行新版本的部署前，將新的應用程序部署到綠色環境中，但并不啟動它。
• 測試和驗證：在部署新版本之后，在綠色環境中進行全面測試和驗證，以確保新版本的功能和性能正常。
• 切換流量：一旦新版本經過驗證沒有問題，可以將流量從藍色環境逐漸切換到綠色環境。這樣，一部分用戶或請求將被導向綠色環境，而其他用戶仍然繼續使用藍色環境。
• 監控和回滾：持續監控綠色環境的性能和穩定性。如果出現問題，可以迅速回滾到藍色環境，保證服務連續性。
• 完成切換：一旦綠色環境被驗證為正常運行，并且滿足預期的要求，可以繼續將所有流量切換到綠色環境，從而完成藍綠部署。

如下圖：Blue為老服務，提供正常服務；Green為新環境，部署新的服務，不對實際用戶提供服務，因此，QA 團隊可以在 Green環境中測試新版本，發現任何錯誤或問題都可以快速修復它們。

如果 Green環境驗證OK，準備就緒，就可以把 Blue環境的流量慢慢切到 Green環境，假如 Green環境出現任何異常，又可以快速回滾到 Blue環境，如下圖：

總的來說，Blue-Green Deployment 的原理是通過在兩個相同的環境中進行部署，逐步切換流量，實現零宕機和無縫切換新版本應用程序的目標。這種部署策略通常用于大規模應用程序或關鍵系統，以確保在部署過程中用戶不會受到影響，同時提供快速回滾機制以應對可能出現的問題。

優點

• 零宕機部署：藍綠部署允許在切換到新版本時實現零宕機（Zero Downtime）部署。新版本可以在獨立的環境中進行測試，確保其穩定性和功能正常后，再切換用戶流量到新版本，而不會中斷服務。
• 風險控制：由于藍綠部署可以隨時回滾到藍色版本，即使新版本存在問題，也可以快速切換回舊版本，降低了部署風險。
• 灰度發布：藍綠部署可以實現灰度發布，逐步將用戶流量從藍色版本轉移到綠色版本，以便逐步測試新版本并收集用戶反饋，確保穩定性。
• 迭代更新：藍綠部署適合頻繁發布和迭代更新，幫助團隊快速交付新功能和修復問題。

缺點

• 環境資源需求：藍綠部署需要同時維護兩個環境（藍色和綠色），這可能會增加資源成本和管理復雜性。
• 配置同步：在進行版本切換時，確保兩個環境的配置和數據同步可能需要額外的努力和策略。
• 需要自動化：為了實現藍綠部署的優勢，需要有自動化的部署和回滾機制，否則可能增加人工錯誤的風險。

適用環境

Blue-Green 部署策略通常用于大規模應用程序或關鍵系統，以確保在部署過程中用戶不會受到影響，同時提供快速回滾機制以應對可能出現的問題。

Canary Deploy

定義

Canary Deployment，中文翻譯為：金絲雀部署，其實就是灰度發布。它允許在生產環境中逐步將新版本應用程序推送給一小部分用戶或服務器，然后根據實時性能和用戶反饋逐步增加新版本的比例，直到最終將所有用戶或服務器都切換到新版本。這種部署方法得名于金絲雀鳥（Canary），它是用來檢測氣體中有毒物質的早期指示器。

原理

• 小規模發布：首先，只將新版本應用程序部署到生產環境中的一小部分服務器或一小部分用戶。這些被選中的服務器或用戶組成了“金絲雀群體”。
• 監控和比較：通過監控金絲雀群體的性能、穩定性和用戶反饋，與之前的版本進行比較。如果新版本表現良好且沒有問題，可以逐步增加新版本的部署比例。
• 逐步升級：根據監控數據，逐漸將新版本應用程序推送給更多的服務器或用戶，直到最終完成全部升級。在這個過程中，可以根據需要靈活地調整部署比例。
• 回滾機制：如果在升級過程中出現問題，可以立即回滾到舊版本，保證用戶和系統的穩定性。

如下圖：首先會部署出一個新版本的小集群，然后將小部分真實用戶切換到小集群上，如果在小集群上驗證業務OK，則可以服務全部部署成V2.0，如果小集群上出現任何問題，只需要把用戶切換到V1集群上，然后對小集群進行修復。

優點

• 風險控制：Canary Deployment 允許逐步發布新版本，即使在部署初期出現問題，也只會影響一小部分用戶或服務器，降低了整體風險。
• 及時發現問題：通過監控金絲雀群體的性能和用戶反饋，可以及時發現潛在的問題，避免大規模部署后才發現嚴重錯誤。
• 零宕機：在金絲雀部署的過程中，新版本和舊版本共存，因此可以實現零宕機部署，確保服務連續性。
• 灰度發布：Canary Deployment 可以實現灰度發布，逐步測試和推出新功能，從而提供更好的用戶體驗和逐步迭代更新。

缺點

• 部署復雜性：相比于傳統的藍綠部署，Canary Deployment 需要更復雜的監控和管理措施，以確保升級過程的穩定性。
• 需要實時監控：為了及時發現問題，需要實時監控金絲雀群體的性能和用戶反饋，這可能需要額外的資源和工具支持。
• 不適用于所有場景：Canary Deployment 適用于大規模系統或復雜系統，但對于較小規模或簡單的項目，可能過于繁瑣。

適用環境

Canary Deployment 特別適用于大型和復雜的系統，它可以幫助團隊在更新時最小化風險，并及時發現和解決潛在問題，提供更好的用戶體驗和服務質量。但它也需要較高的部署復雜性和實時監控要求。

在實際生產中，Canary Deployment 通常不是一個獨立的策略，它通常與Rolling deploy相結合，以創建一種將兩全其美的方法結合在一起的方法。

Feature Toggle

定義

Feature Toggle，中文翻譯為：功能開關，它允許開發團隊在運行時控制應用程序的功能可見性，即通過開關來啟用或禁用特定功能。這種技術的核心原理是將特定功能的開啟狀態從代碼中解耦出來，使得在不修改代碼的情況下，可以在運行時靈活地切換功能的開啟狀態。

原理

• 利用條件判斷：在代碼中通過設置條件判斷，以決定是否執行特定功能代碼塊。
• 外部配置：將功能的開啟狀態配置化，通常存儲在外部配置文件或數據庫中。
• 運行時開關：通過修改配置，可以在運行時控制特定功能的開啟或禁用狀態。
• 動態刷新：為了使更改立即生效，通常需要支持動態刷新配置，而不必重新啟動應用程序。

如下圖：在服務部署的代碼中設置開關，控制真實的邏輯

優點

• 逐步發布：Feature Toggle 允許逐步發布新功能，即使功能已經合并到代碼庫中，也可以通過關閉功能開關來保持其不可見，直到準備好發布。
• 容錯性：如果新功能導致問題或出現bug，可以立即關閉功能開關，回退到舊功能狀態，從而快速修復問題。
• 并行開發：多個團隊可以并行開發不同的功能，通過Feature Toggle 在運行時決定哪些功能被啟用，而不會相互干擾。
• A/B 測試：Feature Toggle 可用于A/B測試，通過在不同用戶群體中啟用或禁用特定功能，來評估功能的效果和用戶反饋。

缺點

• 復雜性：Feature Toggle 引入了額外的代碼邏輯和配置，可能會增加代碼復雜性，特別是當有大量功能需要開關時。
• 維護難度：隨著功能的增加和團隊的變動，維護多個Feature Toggle 可能會變得復雜，需要良好的文檔和規范來管理。
• 安全性：Feature Toggle 需要仔細考慮安全性，確保敏感功能在未授權的情況下不會被啟用。
• 技術債務：如果Feature Toggle 沒有及時清理，可能會導致代碼中存在過多的未使用功能開關，增加技術債務。

適用環境

Feature Toggle 適用于代碼存在多套邏輯的場景，可以幫助團隊更靈活地開發和部署功能，減少部署風險，支持逐步發布和A/B測試。然而，使用Feature Toggle 需要慎重考慮，確保在長期維護過程中不會導致過多的技術債務和復雜性增加。

總結

本文分別講解了 Bing Bang deploy，Rolling Deploy，Blue-Green Deploy，Canary Deploy，Feature Toggle 5種策略的原理和優缺點，學名看起來很高深，似乎都沒有聽過，但很多都在日常一直使用的。下面我通過一家電商公司的發展歷程來描述這幾種部署策略：

• 初創時期，沒有真實用戶，只需要部署一臺服務器，每次新功能的迭代可以采取 Bing Bang deploy 這種全量部署策略 。
• 隨著業務的發展，產品已經積累了少部分用戶，需要部署兩臺服務器，每次新功能的迭代，我們可以采用 Rolling Deploy部署策略，先部署一臺，驗證OK了，再部署剩余的一臺。
• 業務摸索中，發現網頁需要整體改版，因此可以采用 Blue-Green Deploy策略，部署一套全新的UI 和后端環境，等驗收 OK后，再把原服務（Blue環境）切換到新的服務（Green環境）。
• 再隨著業務的發展，服務集群已經發展到 30臺機器，用戶群體也已經上千萬，為了考慮更多的用戶體驗，我們就需要采用 Canary Deploy策略，每次新功能迭代都會先讓小部分用戶使用，如果出現問題可以及時回滾。
• 電商領域，搜索商品是高頻操作，顯然 MySQL不太適合，因此，需要引入Elastic Search 來做全文檢索，這時可以采用 Feature Toggle策略，保留 Mysql 和 Es兩套環境，通過開關來靈活切換流量走哪一種方式。

當然，實際生產中的部署可能會更復雜，但萬變不離其宗，有這 5種策略的加持，可以幫助我們更好地適應更復雜的部署。