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

Big Bang Deploy

定義

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

原理

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

適用場景

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

復(fù)雜的數(shù)據(jù)庫升級：如果數(shù)據(jù)庫需要進(jìn)行復(fù)雜的業(yè)務(wù)升級，已經(jīng)到了不得不使用全量部署策略。

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

Rolling Deploy

定義

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

原理

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

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

適用場景

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

Blue-Green Deploy

定義

Blue-Green Deployment，中文翻譯為：藍(lán)綠部署，它允許在生產(chǎn)環(huán)境中同時維護(hù)兩個相同的系統(tǒng)版本：一個為當(dāng)前生產(chǎn)版本（藍(lán)色），另一個為新版本（綠色）。

原理

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

如下圖：Blue為老服務(wù)，提供正常服務(wù)；Green為新環(huán)境，部署新的服務(wù)，不對實(shí)際用戶提供服務(wù)，因此，QA 團(tuán)隊(duì)可以在 Green環(huán)境中測試新版本，發(fā)現(xiàn)任何錯誤或問題都可以快速修復(fù)它們。

如果 Green環(huán)境驗(yàn)證OK，準(zhǔn)備就緒，就可以把 Blue環(huán)境的流量慢慢切到 Green環(huán)境，假如 Green環(huán)境出現(xiàn)任何異常，又可以快速回滾到 Blue環(huán)境，如下圖：

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

優(yōu)點(diǎn)

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

缺點(diǎn)

• 環(huán)境資源需求：藍(lán)綠部署需要同時維護(hù)兩個環(huán)境（藍(lán)色和綠色），這可能會增加資源成本和管理復(fù)雜性。
• 配置同步：在進(jìn)行版本切換時，確保兩個環(huán)境的配置和數(shù)據(jù)同步可能需要額外的努力和策略。
• 需要自動化：為了實(shí)現(xiàn)藍(lán)綠部署的優(yōu)勢，需要有自動化的部署和回滾機(jī)制，否則可能增加人工錯誤的風(fēng)險。

適用環(huán)境

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

Canary Deploy

定義

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

原理

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

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

優(yōu)點(diǎn)

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

缺點(diǎn)

• 部署復(fù)雜性：相比于傳統(tǒng)的藍(lán)綠部署，Canary Deployment 需要更復(fù)雜的監(jiān)控和管理措施，以確保升級過程的穩(wěn)定性。
• 需要實(shí)時監(jiān)控：為了及時發(fā)現(xiàn)問題，需要實(shí)時監(jiān)控金絲雀群體的性能和用戶反饋，這可能需要額外的資源和工具支持。
• 不適用于所有場景：Canary Deployment 適用于大規(guī)模系統(tǒng)或復(fù)雜系統(tǒng)，但對于較小規(guī)?；蚝唵蔚捻?xiàng)目，可能過于繁瑣。

適用環(huán)境

Canary Deployment 特別適用于大型和復(fù)雜的系統(tǒng)，它可以幫助團(tuán)隊(duì)在更新時最小化風(fēng)險，并及時發(fā)現(xiàn)和解決潛在問題，提供更好的用戶體驗(yàn)和服務(wù)質(zhì)量。但它也需要較高的部署復(fù)雜性和實(shí)時監(jiān)控要求。

在實(shí)際生產(chǎn)中，Canary Deployment 通常不是一個獨(dú)立的策略，它通常與Rolling deploy相結(jié)合，以創(chuàng)建一種將兩全其美的方法結(jié)合在一起的方法。

Feature Toggle

定義

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

原理

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

如下圖：在服務(wù)部署的代碼中設(shè)置開關(guān)，控制真實(shí)的邏輯

優(yōu)點(diǎn)

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

缺點(diǎn)

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

適用環(huán)境

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

總結(jié)

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

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

當(dāng)然，實(shí)際生產(chǎn)中的部署可能會更復(fù)雜，但萬變不離其宗，有這 5種策略的加持，可以幫助我們更好地適應(yīng)更復(fù)雜的部署。