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

Big Bang Deploy

定義

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

原理

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

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

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

缺點(diǎn)

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

適用場(chǎng)景

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

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

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

Rolling Deploy

定義

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

原理

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

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

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

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

缺點(diǎn)

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

適用場(chǎng)景

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

Blue-Green Deploy

定義

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

原理

• 初始狀態(tài)：在初始狀態(tài)下，藍(lán)色環(huán)境是活動(dòng)的，承載著當(dāng)前的生產(chǎn)版本應(yīng)用程序，而綠色環(huán)境是非活動(dòng)的，不對(duì)用戶提供服務(wù)。
• 部署新版本：在進(jìn)行新版本的部署前，將新的應(yīng)用程序部署到綠色環(huán)境中，但并不啟動(dòng)它。
• 測(cè)試和驗(yàn)證：在部署新版本之后，在綠色環(huán)境中進(jìn)行全面測(cè)試和驗(yàn)證，以確保新版本的功能和性能正常。
• 切換流量：一旦新版本經(jīng)過(guò)驗(yàn)證沒有問題，可以將流量從藍(lán)色環(huán)境逐漸切換到綠色環(huán)境。這樣，一部分用戶或請(qǐng)求將被導(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ù)，不對(duì)實(shí)際用戶提供服務(wù)，因此，QA 團(tuán)隊(duì)可以在 Green環(huán)境中測(cè)試新版本，發(fā)現(xiàn)任何錯(cuò)誤或問題都可以快速修復(fù)它們。

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

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

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

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

缺點(diǎn)

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

適用環(huán)境

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

Canary Deploy

定義

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

原理

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

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

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

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

缺點(diǎn)

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

適用環(huán)境

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

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

Feature Toggle

定義

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

原理

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

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

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

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

缺點(diǎn)

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

適用環(huán)境

Feature Toggle 適用于代碼存在多套邏輯的場(chǎng)景，可以幫助團(tuán)隊(duì)更靈活地開發(fā)和部署功能，減少部署風(fēng)險(xiǎn)，支持逐步發(fā)布和A/B測(cè)試。然而，使用Feature Toggle 需要慎重考慮，確保在長(zhǎng)期維護(hù)過(guò)程中不會(huì)導(dǎo)致過(guò)多的技術(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é)名看起來(lái)很高深，似乎都沒有聽過(guò)，但很多都在日常一直使用的。下面我通過(guò)一家電商公司的發(fā)展歷程來(lái)描述這幾種部署策略：

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

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