作為一名 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ò)誤或問(wèn)題，整個(gè)系統(tǒng)可能會(huì)出現(xiàn)故障甚至是癱瘓，影響所有用戶。
-
回滾復(fù)雜：由于一次性部署，如果在新系統(tǒng)中出現(xiàn)嚴(yán)重問(wèn)題，需要回滾到舊系統(tǒng)可能會(huì)非常復(fù)雜和耗時(shí)，尤其是如果數(shù)據(jù)已經(jīng)在新系統(tǒng)中被修改，回滾可能會(huì)導(dǎo)致數(shù)據(jù)丟失或一致性問(wèn)題。
-
用戶接受度：用戶可能對(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)致某些問(wèn)題未被發(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è)批次開(kāi)始，停止舊版本的服務(wù)器，使其不再提供服務(wù)。
-
部署新版本：在停止的舊版本服務(wù)器上部署新版本的應(yīng)用程序代碼，并啟動(dòng)新版本。
-
驗(yàn)證新版本：確保新版本的服務(wù)器正常運(yùn)行，并在沒(méi)有問(wè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)問(wèn)題，可以及時(shí)停止部署，從而減少對(duì)整個(gè)系統(tǒng)的影響。
-
易于回滾：由于部署是逐步進(jìn)行的，如果在新版本中發(fā)現(xiàn)問(wèn)題，可以快速回滾到上一個(gè)穩(wěn)定的版本。這減少了回滾所需的復(fù)雜性和風(fēng)險(xiǎn)。
-
逐步學(xué)習(xí)：滾動(dòng)部署允許一部分用戶或服務(wù)器先使用新版本，有助于逐步了解新功能和系統(tǒng)的表現(xiàn)，從而及時(shí)收集用戶反饋和修復(fù)潛在問(wèn)題。
-
資源控制：滾動(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è)和解決問(wèn)題。
-
版本管理：在滾動(dòng)部署中，可能需要同時(shí)維護(hù)多個(gè)版本的系統(tǒng)，這增加了版本管理和維護(hù)的復(fù)雜性。
-
用戶分流：在部署過(guò)程中，用戶可能會(huì)分流在不同版本的系統(tǒng)中，這可能導(dǎo)致數(shù)據(jù)和用戶體驗(yàn)方面的一些問(wè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)證沒(méi)有問(wè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)問(wèn)題，可以迅速回滾到藍(lán)色環(huán)境，保證服務(wù)連續(xù)性。
-
完成切換：一旦綠色環(huán)境被驗(yàn)證為正常運(yùn)行，并且滿足預(yù)期的要求，可以繼續(xù)將所有流量切換到綠色環(huán)境，從而完成藍(lán)綠部署。
如下圖：Blue為老環(huán)境，提供正常服務(wù)；Green為新環(huán)境，部署新的服務(wù)，不對(duì)實(shí)際用戶提供服務(wù)，因此，QA 團(tuán)隊(duì)可以在 Green環(huán)境中測(cè)試新版本，如果發(fā)現(xiàn)任何錯(cuò)誤或問(wèn)題都可以快速修復(fù)它們。
如果 Green環(huán)境驗(yàn)證OK，達(dá)到上線條件，就可以把 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)。
優(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)色版本，即使新版本存在問(wè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ù)問(wèn)題。
缺點(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)的問(wèn)題。
四、Canary Deploy
定義
Canary Deployment，中文翻譯為：金絲雀部署，其實(shí)就是灰度發(fā)布。它允許在生產(chǎn)環(huán)境中逐步將新版本應(yīng)用程序推送給一小部分用戶或服務(wù)器，然后根據(jù)實(shí)時(shí)性能和用戶反饋逐步增加新版本的比例，直到最終將所有用戶或服務(wù)器都切換到新版本。這種部署方法得名于金絲雀鳥(niǎo)（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)良好且沒(méi)有問(wèn)題，可以逐步增加新版本的部署比例。
-
逐步升級(jí)：根據(jù)監(jiān)控?cái)?shù)據(jù)，逐漸將新版本應(yīng)用程序推送給更多的服務(wù)器或用戶，直到最終完成全部升級(jí)。在這個(gè)過(guò)程中，可以根據(jù)需要靈活地調(diào)整部署比例。
-
回滾機(jī)制：如果在升級(jí)過(guò)程中出現(xiàn)問(wèn)題，可以立即回滾到舊版本，保證用戶和系統(tǒng)的穩(wěn)定性。
如下圖：首先會(huì)部署出一個(gè)新版本的小集群，然后將小部分真實(shí)用戶切換到小集群上，如果在小集群上驗(yàn)證業(yè)務(wù)OK，則可以服務(wù)全部部署成V2.0，如果小集群上出現(xiàn)任何問(wèn)題，只需要把用戶切換到V1集群上，然后對(duì)小集群進(jìn)行修復(fù)。
優(yōu)點(diǎn)
-
風(fēng)險(xiǎn)控制：Canary Deployment 允許逐步發(fā)布新版本，即使在部署初期出現(xiàn)問(wèn)題，也只會(huì)影響一小部分用戶或服務(wù)器，降低了整體風(fēng)險(xiǎn)。
-
及時(shí)發(fā)現(xiàn)問(wèn)題：通過(guò)監(jiān)控金絲雀群體的性能和用戶反饋，可以及時(shí)發(fā)現(xiàn)潛在的問(wè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)問(wè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)和解決潛在問(wè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，中文翻譯為：功能開(kāi)關(guān)，它允許開(kāi)發(fā)團(tuán)隊(duì)在運(yùn)行時(shí)控制應(yīng)用程序的功能可見(jiàn)性，即通過(guò)開(kāi)關(guān)來(lái)啟用或禁用特定功能。這種技術(shù)的核心原理是將特定功能的開(kāi)啟狀態(tài)從代碼中解耦出來(lái)，使得在不修改代碼的情況下，可以在運(yùn)行時(shí)靈活地切換功能的開(kāi)啟狀態(tài)。
原理
-
利用條件判斷：在代碼中通過(guò)設(shè)置條件判斷，以決定是否執(zhí)行特定功能代碼塊。
-
外部配置：將功能的開(kāi)啟狀態(tài)配置化，通常存儲(chǔ)在外部配置文件或數(shù)據(jù)庫(kù)中。
-
運(yùn)行時(shí)開(kāi)關(guān)：通過(guò)修改配置，可以在運(yùn)行時(shí)控制特定功能的開(kāi)啟或禁用狀態(tài)。
-
動(dòng)態(tài)刷新：為了使更改立即生效，通常需要支持動(dòng)態(tài)刷新配置，而不必重新啟動(dòng)應(yīng)用程序。
如下圖：在服務(wù)部署的代碼中設(shè)置開(kāi)關(guān)，控制真實(shí)的邏輯
優(yōu)點(diǎn)
-
逐步發(fā)布：Feature Toggle 允許逐步發(fā)布新功能，即使功能已經(jīng)合并到代碼庫(kù)中，也可以通過(guò)關(guān)閉功能開(kāi)關(guān)來(lái)保持其不可見(jiàn)，直到準(zhǔn)備好發(fā)布。
-
容錯(cuò)性：如果新功能導(dǎo)致問(wèn)題或出現(xiàn)bug，可以立即關(guān)閉功能開(kāi)關(guān)，回退到舊功能狀態(tài)，從而快速修復(fù)問(wèn)題。
-
并行開(kāi)發(fā)：多個(gè)團(tuán)隊(duì)可以并行開(kāi)發(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)有大量功能需要開(kāi)關(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 沒(méi)有及時(shí)清理，可能會(huì)導(dǎo)致代碼中存在過(guò)多的未使用功能開(kāi)關(guān)，增加技術(shù)債務(wù)。
適用環(huán)境
Feature Toggle 適用于代碼存在多套邏輯的場(chǎng)景，可以幫助團(tuán)隊(duì)更靈活地開(kāi)發(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)，適用場(chǎng)景。名字看起來(lái)很高深，似乎都沒(méi)有聽(tīng)過(guò)，但仔細(xì)了解一下都是日常部署常用的方法。下面再通過(guò)一家電商公司的發(fā)展歷程來(lái)總結(jié)描述這幾種部署策略：
初創(chuàng)時(shí)期，快速搭建產(chǎn)品，沒(méi)有真實(shí)用戶，只需要部署一臺(tái)服務(wù)器，每次新功能的迭代可以采取 Bing Bang deploy 這種全量部署策略 。
隨著業(yè)務(wù)的發(fā)展，產(chǎn)品已經(jīng)積累了少部分用戶，需要部署多臺(tái)服務(wù)器，每次新功能的迭代，我們可以采用 Rolling Deploy部署策略，先部署一臺(tái)，驗(yàn)證OK了，再以此類推部署剩余的服務(wù)。
因?yàn)闃I(yè)務(wù)摸索過(guò)程，難免有web端需要整體改版，因此可以采用 Blue-Green Deploy策略，部署一套全新環(huán)境（UI 和后端，測(cè)試等等），等驗(yàn)收 OK后，再把原服務(wù)（Blue環(huán)境）切換到新的服務(wù)（Green環(huán)境）。
再隨著業(yè)務(wù)的發(fā)展，服務(wù)集群已經(jīng)發(fā)展到 幾十臺(tái)機(jī)器，用戶群體也已經(jīng)上千萬(wàn)，為了考慮更多的用戶體驗(yàn)，我們就需要采用 Canary Deploy策略，每次新功能迭代都會(huì)先讓小部分用戶使用，如果出現(xiàn)問(wèn)題可以及時(shí)回滾。
電商領(lǐng)域，商品搜索是用戶高頻操作，顯然 MySQL不太適合，因此，需要引入Elastic Search 來(lái)做全文檢索，這時(shí)可以采用 Feature Toggle策略，服務(wù)代碼中存在 Mysql 和 Es兩套環(huán)境，通過(guò)開(kāi)關(guān)來(lái)靈活切換流量走哪一種方式。
當(dāng)然，實(shí)際生產(chǎn)中的部署可能會(huì)更復(fù)雜，但萬(wàn)變不離其宗，有這 5種策略的加持，可以幫助我們更好地適應(yīng)更復(fù)雜的環(huán)境部署。
