你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
随着云原生应用程序和服务变得更加复杂，为它们部署更改和新版本可能具有挑战性。 服务中断通常是由部署或发布故障引起的。 但是， 在部署后，当应用程序开始接收实际流量时，也可能发生错误，尤其是在在高度分布式多租户云环境中运行且由多个开发团队维护的复杂工作负荷中。 这些环境需要更多的复原措施，例如重试逻辑和自动缩放，这通常很难在开发过程中进行测试。
这就是为什么 在类似于生产环境的环境中进行持续验证很重要，因此，你可以尽早在开发周期中找到并修复任何问题或 bug。 工作负载团队应在开发过程的早期进行测试（左移），并使开发人员能够方便地在接近生产环境的环境中进行测试。
任务关键型工作负载具有高可用性要求，目标为 3、4 或 5 个 9（分别为 99.9%、99.99% 或 99.999%）。 实施 严格的自动化测试 以达到这些目标至关重要。
持续验证取决于每个工作负荷和体系结构特征。 本文提供有关准备 Azure 负载测试和 Azure Chaos Studio 并将其集成到常规开发周期的指南。
1 - 根据预期阈值定义测试
持续测试是一个需要正确准备的复杂过程。 将测试哪些内容，预期结果必须明确。
在 PE：06 - 性能测试和RE：08 - 设计可靠性测试策略的建议中，Azure Well-Architected Framework 建议首先 确定关键方案、依赖项、预期使用情况、可用性、性能和可伸缩性目标。
然后，应定义一组 可度量的阈值 ，以量化关键方案的预期性能。
小窍门
阈值的示例包括预期的用户登录数、给定 API 每秒的请求数，以及后台进程的每秒作数。
应使用阈值 为应用程序开发运行状况模型，以便测试和在生产环境中运行应用程序。
接下来，使用这些值来定义 负载测试，以生成实际流量，从而测试应用程序的基准性能，验证预期的扩展操作等。 在预生产环境中需要持续人工用户流量，因为在不使用的情况下，很难揭示运行时问题。
负载测试可确保对应用程序或基础结构所做的更改不会导致问题，并且系统仍满足预期的性能和测试条件。 测试运行失败而不符合测试标准，表明您需要调整基准线，或发生了意外错误。
尽管自动测试表示日常使用情况， 但应定期运行手动负载测试 ，以验证系统如何响应意外的峰值。
连续验证的第二部分是“故障注入”（混沌工程）。 此步骤通过测试系统响应故障的方式来验证系统的复原能力。 此外，所有复原措施（例如重试逻辑、自动缩放等）都按预期工作。
2 - 使用负载测试和 Chaos Studio 实现验证
Microsoft Azure 提供了这些托管服务来实现负载测试和混乱工程：
- Azure 负载测试 在应用程序和服务上生成综合用户负载。
- Azure Chaos Studio 通过系统地将故障注入应用程序组件和基础结构，提供执行混沌试验的功能。
可以通过 Azure 门户部署和配置 Chaos Studio 和负载测试，但在持续验证的上下文中，使用 API 以 编程和自动化方式部署、配置和运行测试更为重要。 结合使用这两种工具，可以观察系统如何应对问题及其应对基础结构或应用程序故障的能力。
以下视频演示了 Azure DevOps 中集成的 混沌和负载测试的组合实现 ：
如果您正在开发关键任务工作负载，请利用作为 Azure Mission-Critical 项目 和 Azure Well-Architected 框架 提供的参考架构、详细指导、示例实现和代码工件。
Mission-Critical 实现通过 Terraform 部署负载测试服务，并包含 PowerShell Core 包装器脚本集合 ，用于通过其 API 与服务交互。 这些脚本可以直接嵌入到部署管道中。
参考实现中的一个选项是直接从用于启动单个（分支特定）开发环境的端到端（e2e）管道中执行负载测试：
流水线将自动运行负载测试，并行执行或不执行混沌实验（取决于选择）：
注释
在负载测试期间运行混沌试验可能会导致更高的延迟、更高的响应时间和暂时增加的错误率。 与不含混沌试验的运行相比，在横向扩展操作完成或故障转移完成之前，你会注意到更高的数字。
根据是否启用混沌测试并选择试验，基线定义可能会有所不同，因为“正常”状态和“混沌”状态对错误的容忍度可能有所不同。
3 – 调整阈值并建立基线
最后，调整常规运行的 负载测试阈值 ，以验证应用程序（仍）是否提供预期性能，并且不会生成任何错误。 具有单独的混沌测试基线，可以容忍错误率的预期峰值和暂时降低的性能。 此活动是连续的，需要定期重复。 例如，在引入新功能、更改服务 SKU 和其他功能后。
Azure 负载测试服务提供名为 测试条件 的内置功能，用于指定测试需要通过的某些条件。 此功能可用于实现不同的基线。
该功能是通过 Azure 门户和负载测试 API 提供的，并且作为 Azure 任务关键型的一部分开发的包装器脚本提供了一个用于移交基于 JSON 的基线定义的选项。
我们强烈建议 将这些测试直接集成到 CI/CD 管道， 并在功能开发的早期阶段运行它们。 有关示例，请参阅 Azure Mission-critical 参考实现中的 示例实现。
总之，在任何复杂的分布式系统中，故障是不可避免的，因此必须构建解决方案（并对其进行测试）来处理故障。 Well-Architected Framework 任务关键型工作负载指南和参考实现可帮助设计和操作高度可靠的应用程序，以从 Microsoft 云中获取最大价值。
后续步骤
查看任务关键型工作负载的部署和测试设计区域。