通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 上任务关键型工作负荷的部署和测试

  • 项目

失败的部署和错误发布是应用程序中断的常见原因。 部署和测试的方法在任务关键型应用程序的整体可靠性中起着关键作用。

部署和测试应构成所有应用程序和基础结构操作的基础，以确保任务关键型工作负荷的结果一致。 准备好每周、每天或更频繁地部署。 设计持续集成和持续部署（CI/CD）管道以支持这些目标。

策略应实现：

  • 严格的预发布测试。 更新不应引入可能危及应用程序运行状况的缺陷、漏洞或其他因素。

  • 透明部署。 应随时推出更新，而不会影响用户。 用户应能够继续与应用程序交互，而不会中断。

  • 高可用性操作。 部署和测试过程和工具必须高度可用，以支持整体应用程序可靠性。

  • 一致的部署过程。 应使用相同的应用程序项目和进程跨不同的环境部署基础结构和应用程序代码。 端到端自动化是必需的。 必须避免手动干预，因为它们可能会带来可靠性风险。

此设计区域提供了有关如何优化部署和测试过程的建议，目的是最大程度地减少停机时间并维护应用程序运行状况和可用性。

重要

本文是 Azure 架构良好的框架任务关键型工作负荷系列的一部分。 如果不熟悉此系列，建议从什么是任务关键型工作负荷开始？

零停机部署

查看以下视频，大致了解零停机部署。


实现零停机部署是任务关键型应用程序的基本目标。 即使新版本在营业时间内推出，应用程序也需要全天可用。 提前投入精力来定义和规划部署过程，以推动关键设计决策，例如是否将资源视为临时资源。

若要实现零停机时间部署，请在现有基础结构旁边部署新基础结构，对其进行彻底测试，转换最终用户流量，然后才解除以前的基础结构的授权。 其他做法（如 缩放单元体系结构）也是关键。

Mission-Critical Online 和 Azure Mission-Critical Connected 参考实现演示了此部署方法，如下图所示：

显示零停机时间 DevOps 管道引用的关系图。

应用程序环境

查看以下视频，大致了解有关应用程序环境的建议。


需要各种类型的环境来验证和暂存部署操作。 这些类型具有不同的功能和生命周期。 某些环境可能会反映生产环境且生存期较长，而其他环境可能生存期较短，并且功能比生产更少。 在开发周期的早期设置这些环境有助于确保敏捷性、分离生产和预生产资产，并在发布到生产环境之前彻底测试操作。 所有环境都应尽可能反映生产环境，尽管你可以根据需要将简化应用于较低环境。 此图显示了任务关键型体系结构：

显示任务关键型 Azure 体系结构的关系图。

有一些常见注意事项：

  • 不应跨环境共享组件。 可能的例外是下游安全设备，例如综合测试数据的防火墙和源位置。

  • 所有环境都应使用基础结构作为代码（IaC）项目，例如 Terraform 或 Azure 资源管理器 （ARM） 模板。

开发环境

查看以下视频，了解有关临时开发环境和自动化功能验证的信息。


设计注意事项

  • 功能。 对于开发环境，可靠性、容量和安全性的要求较低。

  • 生命周期。 应根据需要创建开发环境，并在短时间内存在。 较短的生命周期有助于防止配置偏离代码库并降低成本。 此外，开发环境通常共享功能分支的生命周期。

  • 密度。 Teams 需要多个环境来支持并行功能开发。 他们可以在单个订阅中共存。

设计建议

  • 将环境保留在专用订阅中，该订阅具有用于开发目的的上下文集。

  • 使用自动化过程将代码从功能分支部署到开发环境。

测试或过渡环境

这些环境用于测试和验证。 执行许多测试周期以确保无 bug 部署到生产环境。 持续验证和测试部分介绍了 针对任务关键型工作负荷的适当测试 。

设计注意事项

  • 功能。 这些环境应反映生产环境的可靠性、容量和安全性。 如果缺少生产负载，请使用综合用户负载来提供实际指标和有价值的运行状况建模输入。

  • 生命周期。 这些环境生存期较短。 测试验证完成后，应销毁它们。

  • 密度。 可以在一个订阅中运行许多独立环境。 还应考虑使用多个环境，每个环境都在专用订阅中。

注意

任务关键型应用程序应接受严格的测试。

可以在单个环境中执行不同的测试函数，在某些情况下需要执行。 例如，对于混乱测试以提供有意义的结果，必须先将应用程序置于负载下，以便了解应用程序如何响应注入的错误。 这就是为什么混沌测试和负载测试通常并行执行的原因。

设计建议

  • 确保至少一个过渡环境完全反映生产环境，以启用类似生产环境的测试和验证。 此环境中的容量可以根据测试活动的执行而灵活。

  • 生成综合用户负载，为其中一个环境上的更改提供真实的测试用例。

    注意

    Mission Critical Online 参考实现提供了用户负载生成器的示例。

  • 定义开发和发布周期内的过渡环境数及其用途。

生产环境

设计注意事项

  • 功能。 需要应用程序的最高可靠性、容量和安全功能。

  • 生命周期。 虽然工作负荷和基础结构的生命周期保持不变，但所有数据（包括监视和日志记录）都需要特殊管理。 例如，备份和恢复需要管理。

  • 密度。 对于某些应用程序，可能需要考虑使用不同的生产环境来满足不同的客户端、用户或业务功能。

设计建议

对于生产环境和较低环境，具有明确的治理边界。 将每个环境类型放在专用订阅中，以实现该目标。 此分段可确保较低环境中的资源利用率不会影响生产配额。 专用订阅还会设置访问边界。

临时蓝/绿部署

蓝/绿部署模型至少需要两个相同的部署。 蓝色部署是用于在生产环境中为用户流量提供服务的活动部署。 绿色部署是准备并测试接收流量的新部署。 绿色部署完成并测试后，流量逐渐从蓝色定向到绿色。 如果负载传输成功，绿色部署将成为新的活动部署。 然后，可以通过分阶段过程解除旧的蓝色部署。 但是，如果新部署中存在问题，则可以中止该部署，并且流量可以保留在旧的蓝色部署中，也可以重定向到该部署。

Azure Mission-Critical 建议采用蓝/绿部署方法，其中基础结构 和应用程序 作为部署标记的一部分一起部署。 因此，对基础结构或应用程序的更改始终会导致包含这两个层的绿色部署。 使用此方法，可以在将用户流量重定向到基础结构和应用程序端到端之前，对更改的影响进行全面测试和验证。 由于可以验证与下游依赖项（如 Azure 平台、资源提供程序和 IaC 模块）的兼容性，因此此方法可以增强发布更改并实现零停机升级的信心。

设计注意事项

  • 技术功能。 利用 Azure 服务中的内置部署功能。 例如，Azure App 服务提供可在部署后交换的辅助部署槽位。 使用 Azure Kubernetes 服务 （AKS），可以在每个节点上使用单独的 Pod 部署并更新服务定义。

  • 部署持续时间。 部署可能需要更长的时间才能完成，因为模具包含基础结构和应用程序，而不仅仅是更改的组件。 但是，这是可以接受的，因为所有组件没有按预期工作的风险会覆盖时间问题。

  • 成本影响。 由于两个并行部署需要额外的成本，这必须在部署完成之前共存。

  • 流量转换。 验证新部署后，流量必须从蓝色环境过渡到绿色环境。 这种转换需要协调环境之间的用户流量。 转换应完全自动化。

  • 生命周期。 任务关键型部署戳记应被视为临时式。 每次预配资源之前，使用生存期较短的戳记都会创建一个新的开始。

设计建议

  • 采用蓝/绿部署方法来发布所有生产更改。 每次针对任何类型的更改部署所有基础结构和应用程序，以实现一致的状态和零停机时间。 尽管可以重复使用环境，但我们不建议将其用于任务关键型工作负荷。 将每个区域部署标记视为临时的，该生命周期与单个版本的生命周期相关联。

  • 使用全局负载均衡器（如 Azure Front Door）协调蓝绿环境之间的用户流量的自动转换。

  • 若要转换流量，请添加一个绿色后端终结点，该终结点使用低流量来增加流量权重，例如 10%。 验证绿色部署上的流量较低并提供预期的应用程序运行状况后，逐渐增加流量。 这样做时，请应用较短的纵向扩展期来捕获可能不会立即明显的故障。

    转换所有流量后，请从现有连接中删除蓝色后端。 例如，从全局负载均衡器服务中删除后端、清空队列和分离其他关联。 这样做有助于优化维护辅助生产基础结构的成本，并确保新环境没有配置偏差。

    此时，解除旧和现在处于非活动状态的蓝色环境。 对于下一个部署，请用蓝色和绿色反转重复此过程。

订阅范围的部署

根据应用程序的缩放要求，可能需要多个生产订阅来充当缩放单位。

查看以下视频，大致了解有关确定任务关键型应用程序的订阅范围的建议。


设计注意事项

  • 可伸缩性。 对于具有大量流量的大规模应用程序方案，请设计解决方案以跨多个 Azure 订阅进行缩放，以便单个订阅的规模限制不会限制可伸缩性。

    重要

    使用多个订阅需要额外的 CI/CD 复杂性，这必须得到适当的管理。 因此，建议仅在极端缩放方案中使用多个订阅，其中单个订阅的限制可能会成为限制。

  • 环境边界。 将生产、开发和测试环境部署到单独的订阅中。 这种做法可确保较低的环境不会影响规模限制。 它还通过提供明确的管理和标识边界来降低环境更新污染生产的风险。

  • 治理。 如果需要多个生产订阅，请考虑使用专用应用程序管理组通过策略聚合边界简化策略分配。

设计建议

  • 在专用订阅中部署每个区域部署标记，以确保订阅限制仅在单个部署标记的上下文中应用，而不是在整个应用程序中应用。 在适当情况下，可以考虑在单个区域中使用多个部署标记，但应该跨独立订阅部署它们。

  • 将全局共享资源放置在专用订阅中，以实现一致的区域订阅部署。 避免对主要区域使用专用部署。

持续验证和测试

测试是一项关键活动，可用于完全验证应用程序代码和基础结构的运行状况。 更具体地说，测试允许你满足可靠性、性能、可用性、安全性、质量和规模的标准。 测试必须明确定义并应用为应用程序设计和 DevOps 策略的一部分。 测试是本地开发人员过程（内部循环）和整个 DevOps 生命周期（外部循环）的一部分的关键问题，即代码从发布管道进程到生产环境的路径开始。

观看以下视频，大致了解持续验证和测试。


本部分重点介绍外部循环测试。 它描述了各种类型的测试。

测试 说明
单元测试 确认应用程序业务逻辑按预期工作。 验证代码更改的总体效果。
冒烟测试 确定基础结构和应用程序组件是否可用，并按预期运行。 通常，仅测试单个虚拟用户会话。 结果应为系统响应预期值和行为。
常见的冒烟测试方案包括访问 Web 应用程序的 HTTPS 终结点、查询数据库以及模拟应用程序中的用户流。
UI 测试 验证是否已部署应用程序用户界面，并且用户界面交互是否按预期运行。
应使用 UI 自动化工具来驱动自动化。 在 UI 测试期间，脚本应模拟真实的用户方案，并完成一系列执行操作并实现预期结果的步骤。
负载测试 通过快速增加负载和/或逐步来验证可伸缩性和应用程序操作，直到达到预先确定的阈值。 负载测试通常围绕特定用户流进行设计，以验证在定义的负载下是否满足应用程序要求。
压力测试 应用重载现有资源的活动，以确定解决方案限制并验证系统正常恢复的能力。 主要目标是确定潜在的性能瓶颈和缩放限制。
相反，纵向缩减系统的计算资源，并监视它在负载下的行为方式，并确定它是否可以恢复。
性能测试 结合负载和压力测试的各个方面来验证负载下的性能，并为应用程序操作建立基准行为。
混沌测试 将人为故障注入系统，以评估其反应方式，并验证复原措施、操作过程和缓解措施的有效性。
关闭基础结构组件、故意降低性能并引入应用程序故障是可用于验证应用程序在实际发生方案时是否按预期做出反应的测试示例。
渗透测试 确保应用程序及其环境满足预期安全状况的要求。 目标是识别安全漏洞。
安全测试可以包括端到端软件供应链和包依赖项，并扫描和监视已知的常见漏洞和暴露（CVE）。

设计注意事项

  • 自动化。 自动测试对于以及时且可重复的方式验证应用程序或基础结构更改至关重要。

  • 测试顺序。 由于各种依赖项（例如需要运行应用程序环境），因此执行测试的顺序是一个关键考虑因素。 测试持续时间还会影响顺序。 如果可能，运行时间较短的测试应在周期的早期运行，以提高测试效率。

  • 可伸缩性限制。 Azure 服务具有不同的软和硬性限制。 请考虑使用负载测试来确定系统是否在预期的生产负载期间超出它们的风险。 负载测试还可用于设置适当的自动缩放阈值。 对于不支持自动缩放的服务，负载测试可以帮助你微调自动化操作过程。

    无法适当缩放的系统组件（如主动/被动网络组件或数据库）具有限制性。 压力测试可以帮助识别限制。

  • 故障模式分析。 在应用程序和底层基础结构中引入故障并评估效果对于评估解决方案的冗余机制至关重要。 在此分析过程中，确定影响的风险、影响和广度（部分或完全中断）。 有关为 任务关键联机 参考实现创建的示例分析，请参阅 各个组件的中断风险。

  • 监视。 应逐个捕获和分析测试结果，并对其进行聚合以评估随时间推移的趋势。 应持续评估测试结果的准确性和覆盖范围。

设计建议

观看以下视频，了解如何将复原测试与 Azure DevOps CI/CD 管道集成。


  • 通过在基础结构和应用程序组件上自动执行所有测试，确保一致性。 在 CI/CD 管道中集成测试，以便协调并运行它们（如果适用）。 有关技术选项的信息，请参阅 DevOps 工具。

  • 将所有测试项目视为代码。 它们应与其他应用程序代码项目一起进行维护和版本控制。

  • 将测试基础结构的 SLA 与部署和测试周期的 SLA 保持一致。

  • 在每个部署中运行冒烟测试。 此外，还要运行广泛的负载测试以及压力和混乱测试，以验证应用程序性能和可操作性是否得到维护。

    • 使用反映实际峰值使用模式的负载配置文件。
    • 在负载测试的同时运行混沌试验和故障注入测试。

    提示

    Azure Chaos Studio 是一套本机混沌试验工具。 借助这些工具，可以轻松地进行混沌试验，并在 Azure 服务和应用程序组件中注入故障。

    Chaos Studio 为常见故障方案提供内置混沌试验，并支持面向基础结构和应用程序组件的自定义试验。

  • 如果负载或冒烟测试需要数据库交互（如创建记录）使用具有减少特权的测试帐户，并使测试数据与实际用户内容分离。

  • 扫描和监视已知 CVE 的端到端软件供应链和包依赖项。

    • 使用 Dependabot for GitHub 存储库，确保存储库与它所依赖的包和应用程序的最新版本自动保持最新。

基础结构即代码部署

基础结构即代码 （IaC） 将基础结构定义视为与其他应用程序项目一起控制的源代码。 使用 IaC 可跨环境提升代码一致性，在自动部署期间消除人为错误的风险，并提供可跟踪性和回滚性。 对于蓝/绿部署，将 IaC 与完全自动化部署结合使用势在必行。

任务关键型 IaC 存储库具有两个不同的定义，这些定义映射到全球资源和区域资源。 有关这些类型的资源的信息，请参阅 核心体系结构模式。

设计注意事项

  • 可重复的基础结构。 以每次生成相同环境的方式部署任务关键型工作负荷。 IaC 应该是主模型。

  • 自动化。 所有部署都必须完全自动化。 人为过程容易出错。

设计建议

  • 应用 IaC，确保所有 Azure 资源都在声明性模板中定义，并在源代码管理存储库中维护。 部署模板，并通过 CI/CD 管道从源代码管理自动预配资源。 不建议使用命令性脚本。

  • 禁止对所有环境执行手动操作。 唯一的例外是完全独立的开发人员环境。

DevOps 工具

有效使用部署工具对于整体可靠性至关重要，因为 DevOps 进程会影响整体功能和应用程序设计。 例如，故障转移和缩放操作可能取决于 DevOps 工具提供的自动化。 工程团队必须了解部署服务对整体工作负荷不可用的影响。 部署工具必须可靠且高度可用。

Microsoft 提供了两个 Azure 原生工具集，即 GitHub Actions 和 Azure Pipelines，可以有效地部署和管理任务关键型应用程序。

设计注意事项

  • 技术功能。 GitHub 和 Azure DevOps 的功能重叠。 你可以将它们一起使用来充分利用这两者。 一种常见方法是在使用 Azure Pipelines 进行部署时，将代码存储库存储在 GitHub.com 或 GitHub AE 中。

    请注意使用多种技术时添加的复杂性。 根据整体可靠性评估丰富的功能集。

  • 区域可用性。 就最大可靠性而言，依赖于单个 Azure 区域的依赖项表示操作风险。

    例如，假设流量分布在两个区域：区域 1 和区域 2。 区域 2 托管 Azure DevOps 工具实例。 假设区域 2 中有中断，实例不可用。 区域 1 会自动处理所有流量，并需要部署额外的缩放单元，以提供良好的故障转移体验。 但是，由于区域 2 中的 Azure DevOps 依赖项，它无法完成。

  • 数据复制。 应跨区域复制数据，包括元数据、管道和源代码。

设计建议

  • 这两种技术都托管在单个 Azure 区域中，这可能会限制灾难恢复策略。

    GitHub Actions 非常适合生成任务（持续集成），但可能缺少复杂部署任务（持续部署）的功能。 鉴于 Azure DevOps 的丰富功能集，建议将其用于任务关键型部署。 但是，评估权衡后，你应该做出选择。

  • 定义部署工具的可用性 SLA，并确保与更广泛的应用程序可靠性要求保持一致。

  • 对于使用主动/被动或主动/主动部署配置的多区域方案，请确保即使主区域托管部署工具集不可用，故障转移业务流程和缩放操作也能继续运行。

分支策略

有许多有效的分支方法。 应选择确保最大可靠性的策略。 良好的策略可实现并行开发，提供从开发到生产、支持快速发布的清晰路径。

设计注意事项

  • 最小化访问。 开发人员应在分支中feature/*fix/*执行其工作。 这些分支将成为更改的入口点。 应将基于角色的限制应用于分支，作为分支策略的一部分。 例如，仅允许管理员创建发布分支或强制实施分支的命名约定。

  • 紧急情况的加速过程。 分支策略应允许修补程序尽快合并到 main 一起。 这样，将来的版本就包含修补程序，并避免了问题的重复。 仅对解决紧急问题的次要更改使用此过程，并对其进行克制。

设计建议

  • 优先使用 GitHub 进行源代码管理。

    重要

    创建一个分支策略，该策略详细介绍 了功能 工作和 版本 ，并使用分支策略和权限来确保策略得到适当的实施。

  • 触发自动测试过程，在代码更改贡献被接受之前对其进行验证。 团队成员还必须查看更改。

  • 将 main 分支视为一个持续向前移动且稳定的分支，该分支主要用于集成测试。

    • 确保仅通过 PR 进行更改 main 。 使用分支策略禁止直接提交。
    • 每次将 PR 合并到 main其中时，它都应针对集成环境自动启动部署。
    • 分支 main 应被视为稳定。 从任何给定时间创建发布 main 应该很安全。

  • 使用从main分支创建的专用release/*分支，并用于部署到生产环境。 release/* 分支应保留在存储库中，可用于修补发布。

  • 记录修补程序过程，并仅在需要时才使用它。 在分支中创建 fix/* 修补程序，以便后续合并到发布分支并部署到生产环境。

AI for DevOps

可以在 CI/CD 管道中应用 AIOps 方法，以补充传统的测试方法。 这样做可以检测潜在的回归或降级，并允许先发制人地停止部署，以防止潜在的负面影响。

设计注意事项

  • 遥测数据量。 CI/CD 管道和 DevOps 进程为机器学习模型发出各种遥测数据。 遥测范围从测试结果和部署结果到有关复合部署阶段测试组件的操作数据。

  • 可伸缩性。 传统的数据处理方法（如提取、转换、加载（ETL）可能无法缩放吞吐量，以跟上部署遥测和应用程序可观测性数据的增长。 可以使用不需要 ETL 和数据移动（如数据虚拟化）的新式分析方法来启用 AIOps 模型的持续分析。

  • 部署更改。 部署中的更改需要存储，以便自动分析和与部署结果关联。

设计建议

  • 定义要收集和分析的 DevOps 进程数据。 遥测（例如测试执行指标和每个部署中更改的时序数据）非常重要。

    • 从过渡、测试和生产环境中公开应用程序可观测性数据，以便在 AIOps 模型中进行分析和关联。

  • 采用 MLOps 工作流。

  • 开发上下文感知和依赖项感知的分析模型，以便通过自动化特征工程提供预测，以解决架构和行为更改。

  • 通过在部署管道中注册和部署最佳训练的模型来操作模型。

下一步

查看安全注意事项。

安全性