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