本文介绍 Azure Spring Apps 上的应用程序的高可用性蓝/绿部署解决方案。
蓝/绿部署模式指的是在将现有版本的应用程序保持活动状态（称为蓝色版本）的情况下推出新版本的应用程序部署（称为绿色版本）。 这种部署允许独立重启、预热和测试新的应用程序版本。 应用程序的新版本运行后，可以切换到新版本，并将新传入流量重定向到该版本。 对于应用程序的用户而言，在部署新版本期间根本察觉不到发生了停机。 如果新部署无法按预期工作，则蓝/绿部署可以轻松放弃新版本，且不会影响当前版本。
体系结构
下图描绘了此方法的体系结构：
下载此体系结构的 Visio 文件。
组件
此解决方案使用以下组件：
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 应用服务过渡槽作为替代方案。 槽包含应用程序的新版本，在完成槽交换之前可以重新加载、预热和测试该版本。 槽交换会将新版本投入生产。 此过程已内置于服务中，因此设置非常简单。
作为另一种替代方案，可将托管 Web 终结点的任何 Azure 服务放在负载均衡解决方案之后。 如果使用此方法，可以运转 Azure 服务的另一个实例，在其中可以部署应用程序的新版本。 接下来，你可以通过将负载均衡解决方案中的流量切换到包含新版应用的 Azure 服务来实现无停机时间的部署。 请记住，这种蓝/绿部署方法会产生较高的管理开销。
方案详细信息
对于某些云应用程序而言，保持尽可能高的运行时间至关重要。 一种解决方案是使用高可用性配置，但这样做会使成本翻倍。 另一种解决方案是使用灾难恢复计划，在发生服务中断后，它可以在另一个区域中恢复应用程序。 后者的成本可能更低，但使整个应用程序再次联机需要一段时间。
本文将介绍在部署应用程序新版本期间确保高可用性的过程。 在传统配置中，应用程序的新片段将部署到托管该应用程序的服务中。 此配置通常会导致重新加载和重启应用程序。 在此过程中，应用程序将不可用。
此解决方案使用 Azure Spring Apps 实现蓝/绿部署，可以满足将应用程序部署自动化的需求。
可能的用例
任何需要高可用性的组织都可受益于此解决方案。 该解决方案特别适合用于电子商务和游戏等行业，在这些行业，停机可能会导致业务和收入损失。
可以通过实现零停机部署来进一步提高可用性。 有关详细信息，请参阅本文的替代方案部分。
注意事项
下面的解决方案注意事项实现 Azure 架构良好的框架的支柱。 该框架是一组指导原则，可用于提升工作负载的质量。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可用性
此解决方案可帮助你在部署新版本期间保持应用程序的可用性。 它不会提高 Azure Spring Apps 提供的整体 SLA。 平台上发生服务故障仍可能会影响你的应用。
如果你希望通过某种解决方案来提高配置的整体 SLA，请考虑在多个区域中设置高可用性 Azure Spring Apps 服务。 在此方法中，你在该配置的前面部署全局负载均衡解决方案。
可伸缩性
此解决方案基于应用程序工作，因此非常适合微服务应用程序。 它还使应用程序团队能够独立于其他应用程序团队工作，而不会影响整个解决方案的运行时间。
此解决方案在基于应用程序工作时还能保持最佳的效果，其中每个应用程序具有自身的蓝/绿部署工作流。 如果在同一个工作流中组合应用程序，此配置很快就会变得复杂，因此我们不建议采用这种做法。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
除了设置存储库权限外，请考虑在包含要部署到 Azure Spring Apps 的代码的 Git 存储库中实施以下安全措施：
分支保护。 防止将更改直接推送到代表应用程序生产状态的分支。 要求将每个更改建议作为拉取请求 (PR) 提交。 使用 PR 执行自动检查。 这些检查可能会生成所有代码，并针对 PR 创建或修改的代码运行单元测试。
PR 评审。 为了实施四眼原则，请要求 PR 至少由一名评审者评审。 还可以使用 GitHub 代码所有者功能来定义负责查看存储库中特定文件的个人或团队。
不可变历史记录。 仅允许在现有更改之上进行新的提交。 不可变的历史记录对于审核目的尤其重要。
进一步的安全措施。 要求 GitHub 用户激活多重身份验证。 此外，仅允许已签名的提交，以后无法更改提交。
我们还建议你仅部署到一个 Azure Spring Apps 服务。 在生产设置中，应该先在其他环境中测试代码，然后再将其部署到生产环境。 生产环境最好与开发和测试环境分开。
有关进一步提高 Azure Spring Apps 服务安全性的信息，请参阅在虚拟网络中部署 Azure Spring Apps。 如果实现建议的部署，则不能使用 GitHub 托管的运行器。 需要为部署工作流使用你自己的运行器。
DevOps
通过 GitHub Actions 工作流自动化此设置可以提高 DevOps 的工作效率。 最有用的功能之一是能够快速还原存在意外行为的更改。 仅拒绝新部署。
团队经常为同一个应用程序管理多个环境。 将应用程序的多个版本部署到不同 Azure Spring Apps 服务的做法很常见。 Git 存储库是单一可信源，它显示当前部署到群集的应用程序版本。
成本优化
成本优化工作是设法减少不必要的费用以及提高运营效率。 有关详细信息，请参阅成本优化支柱概述。
使用 Azure 定价计算器估算成本。
Azure Spring Apps 具有基本层和标准层。 有关详细信息，请参阅 Azure Spring Apps 定价。 使用蓝/绿部署策略时，只需为运行部署时短时间使用的虚拟 SPU 支付额外的费用。
GitHub 提供免费服务。 不过，若要使用高级安全性相关的功能（例如代码所有者或所需的评审者），则需要团队计划。 有关详细信息，请参阅 GitHub 定价页。
方案部署
有关此配置的示例，请参阅 Azure Spring Apps 应用程序的自动化蓝/绿部署 GitHub 存储库。 该存储库还包含使用 Bicep 模板设置 Azure Spring Apps 服务的步骤。
作者
Microsoft 会维护此内容。 以下参与者参与了对原始内容的开发。
主要作者：
- Gitte Vermeiren | FastTrack for Azure 工程师
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
- 使用分步指南实现此体系结构
- Azure Spring Apps 中的蓝绿部署策略
- 快速入门 - 生成应用并将其部署到 Azure Spring Apps
- 在 Azure Spring Apps 中设置过渡环境
- GitHub：了解 GitHub Actions
- GitHub：使用环境进行部署
- GitHub：重用工作流