本文說明 Azure Spring Apps 上應用程式的高可用性 藍/綠 部署解決方案。
藍/綠部署模式牽涉到將現有版本的應用程式保持為即時（稱為 藍色 版本），而新版本的應用程式會部署（稱為 綠色 版本）。 此部署可讓您獨立重新啟動、準備及測試新的應用程式版本。 執行新版本的應用程式之後，您可以切換至該應用程式，並將任何新的連入流量重新導向至該應用程式。 針對應用程式的使用者，新版本的部署不會有任何可見的停機時間。 藍色/綠色部署可讓您輕鬆地放棄新版本，而不會影響新部署是否如預期般運作。
架構
下圖描述此方法的架構：
元件
此解決方案會使用下列元件：
Azure Spring Apps 是執行 Java Spring Boot 和 Steeltoe .NET Core 應用程式的新式微服務平臺。 此服務可排除執行微服務的未定案程序代碼，並協助您在雲端中快速開發強固的應用程式。 您也可以使用 Azure Spring Apps，根據每個應用程式部署程式碼。
GitHub 是一個程式代碼裝載平臺，可提供版本控制和共同作業。 GitHub 提供 Git 分散式版本控制、原始程式碼管理及其他功能。
GitHub Actions 可協助您從存放庫內自動執行軟體開發和部署工作流程。 您可以使用平臺來建立完全自動化的持續整合和持續傳遞 （CI/CD） 設定。 您也可以使用 GitHub Actions 來建立環境，以便設定規則，例如需要檢閱者。
工作流程
解決方案架構會實作下列工作流程：
開發人員對應用程式進行變更。 GitHub 存放庫會保存需要部署到 Azure Spring Apps 的應用程式程序代碼。 應用程式程式代碼的每個變更都會在原始檔控制下進行。 GitHub 會完成下列工作：
請確定已檢閱變更。
防止意外或未經授權的變更。
確定品質檢查已完成。
GitHub 存放庫也會保存 GitHub Actions 工作流程，以建置程式代碼變更並完成必要的質量檢查。 編譯程式代碼之後，GitHub Actions 工作流程會將最新版本的應用程式程式代碼部署到 Azure Spring Apps。 GitHub Actions 工作流程包含下列步驟：
判斷目前的使用中生產環境。
將程式代碼部署到非生產環境。 如果非生產環境不存在，請建立環境。
此時在部署中，生產部署中舊版（藍色）的應用程式會繼續接收所有生產流量。
等候新應用程式的部署檢閱和核准。
此步驟提供新部署的應用程式 （綠色版本） 開始和熱身的時間。
核准之前，您可以使用應用程式的非生產URL來驗證新版本，並確定它已就緒。
核准之後，切換生產部署和非生產環境部署。
所有生產流量現在都會路由傳送至新版本的應用程式。
注意
如果您拒絕新的部署，GitHub 不會切換環境。 舊版會繼續接收生產流量。
核准和流量切換之後，請刪除舊的生產部署。
此清除步驟會產生更具成本效益的設定。
替代項目
此解決方案會使用 GitHub Actions 將部署自動化。 您也可以使用 Azure Pipelines 或任何其他 CI/CD 自動化系統作為替代方案。 案例部署一節中提供的範例會盡可能使用 Azure CLI 語句，因此您可以輕鬆地將此設定轉譯為另一個自動化工具。 使用 CI/CD 工具來設定環境，並在其上建立核准流程。
此架構使用 Azure Spring Apps 搭配部署作為目標服務。 您可以使用 Azure App 服務 預備位置做為替代方案。 位置包含新版本的應用程式，可在位置交換完成之前重載、熱身和測試。 位置交換會將新版本置於生產環境中。 此程式內建於服務中，因此設定很簡單。
另一個替代方案是，您可以將裝載Web端點的任何 Azure 服務放在負載平衡解決方案後面。 如果您使用此方法，您可以啟動 Azure 服務的第二個實例，您可以在其中部署新版本的應用程式。 在下一個步驟中，您可以將負載平衡解決方案的流量切換至保留新版應用程式的 Azure 服務，以建立零停機部署。 請記住，這個藍/綠部署的方法需要大量的管理額外負荷。
案例詳細資料
對於某些雲端應用程式，盡可能讓運行時間保持在最高狀態非常重要。 其中一個解決方案是使用高可用性設定，這可讓成本加倍。 另一個解決方案是災害復原方案，會在中斷後於另一個區域中再次顯示應用程式。 後者的成本可能較低，但讓整個應用程式重新上線需要時間。
本文說明在部署新版本應用程式期間確保高可用性的程式。 在傳統組態中，應用程式的新位會部署到裝載應用程序的服務。 這個設定通常會導致應用程式的重載和重新啟動。 在該程式中，應用程式無法使用。
此解決方案會使用 Azure Spring Apps 來實作藍色/綠色部署，並解決應用程式部署的自動化問題。
潛在的使用案例
此解決方案可讓任何需要高可用性的組織受益。 此解決方案特別適用於電子商務和遊戲等產業，其中停機時間可能會導致業務和營收損失。
您可以藉由實作零停機時間部署來進一步改善可用性。 如需詳細資訊，請參閱 本文的<替代 專案>一節。
考量
下列解決方案考慮會實作 Azure Well-Architected Framework 的支柱。 此架構是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。
可用性
此解決方案可協助您在部署新版本期間維護應用程式的可用性。 它不會增加 Azure Spring Apps 提供的整體 SLA。 平臺上的服務失敗仍會影響您的應用程式。
如果您想要讓解決方案增加設定的整體 SLA，請查看在多個區域上設定高可用性 Azure Spring Apps 服務。 在此方法中，您會使用全域負載平衡解決方案來前端設定。
延展性
此解決方案會以個別應用程式為基礎運作，因此非常適合微服務應用程式。 它也可讓應用程式小組與其他應用程式小組獨立運作，而不會影響整體解決方案的運作時間。
此解決方案也最適合每個應用程式，其中每個應用程式都有自己的藍色/綠色部署工作流程。 如果您在相同的工作流程中結合應用程式，此組態會很快變得複雜，因此不建議使用該方法。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性要素概觀。
除了設定存放庫許可權之外，請考慮在 Git 存放庫中實作下列安全性措施，以保存您想要部署至 Azure Spring Apps 的程式代碼：
分支保護。 保護代表應用程式生產狀態的分支，使其無法直接推送變更。 要求將每個變更提案提交為提取要求（PR）。 使用 PR 執行自動檢查。 檢查可能包括在 PR 建立或修改的程式代碼上建置所有程式代碼和執行單元測試。
PR 檢閱。 若要強制執行四眼原則，要求PR至少有一個檢閱者。 您也可以使用 GitHub 程式代碼擁有者 功能來定義負責檢閱存放庫中特定檔案的個人或小組。
不可變的歷程記錄。 只允許現有變更上的新認可。 不可變的歷程記錄對於稽核目的特別重要。
進一步的安全性措施。 要求您的 GitHub 使用者啟用 多重要素驗證。 此外，只允許已簽署的認可，稍後無法加以變更。
我們也建議您只部署至一個 Azure Spring Apps 服務。 在生產設定中，您應該先在其他環境測試程序代碼，再將程式代碼部署到生產環境。 您的生產環境最好位於與開發和測試環境不同的環境中。
如需 Azure Spring Apps 服務額外安全性的相關信息，請參閱 在虛擬網路中部署 Azure Spring Apps。 如果您實作建議的部署，就無法使用 GitHub 裝載的執行器。 您必須針對部署工作流程使用自己的執行器。
DevOps
透過 GitHub Actions 工作流程進行此設定的自動化可提升 DevOps 生產力。 其中一項最有用的功能是能夠快速還原非預期運作的變更。 只要拒絕新的部署即可。
Teams 通常會管理相同應用程式的多個環境。 通常會有數個版本的應用程式部署到不同的 Azure Spring Apps 服務。 Git 存放庫是單一事實來源，會顯示目前部署至叢集的應用程式版本。
成本最佳化
成本優化牽涉到尋找減少不必要的費用並提升營運效率的方法。 如需詳細資訊，請參閱 成本優化要素概觀。
使用 Azure 定價計算機來預估成本。
Azure Spring Apps 具有基本層和標準層。 如需詳細資訊，請參閱 Azure Spring Apps 定價。 當您使用藍色/綠色部署策略時，只需在部署執行時，只需支付額外的虛擬 SPU 費用。
GitHub 提供免費服務。 不過，若要使用進階安全性相關功能，例如程式代碼擁有者或必要的檢閱者，您需要Team方案。 如需詳細資訊，請參閱 GitHub 定價頁面。
案例部署
如需此設定的範例，請參閱 Azure Spring Apps 應用程式的 自動化藍/綠部署 GitHub 存放庫。 存放庫也包含使用 Bicep 範本設定 Azure Spring Apps 服務的步驟。
參與者
Microsoft 會維護此內容。 下列參與者開發了原始內容。
主體作者：
- Gitte Vermeiren |適用於 Azure 工程師的 FastTrack
若要查看非公用LinkedIn配置檔，請登入LinkedIn。
下一步
- 使用逐步指南實作此架構
- Azure Spring Apps 中的藍色/綠色部署策略
- 快速入門：建置應用程式並將其部署至 Azure Spring Apps
- 在 Azure Spring Apps 中設定預備環境
- GitHub：瞭解 GitHub Actions
- GitHub：使用環境進行部署
- GitHub：重複使用工作流程