选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

部署前活动 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

部署前活动

环境设计

您测试和评估应用程序的环境会影响您对其进行测试的彻底程度,以及您对这些结果能否准确反映生产中将发生的事情的信心。您可以使用诸如 Amazon DynamoDB 之类的服务,在开发者计算机上本地执行一些集成测试(请参阅 DynamoDB 文档中的本地设置 DynamoDB)。但是,在某些时候,您需要在复制生产环境的环境中进行测试,以便获得对结果的最大可信度。这种环境会产生成本,因此我们建议您对环境采取分阶段或流水线方法,在这些环境中,类似于生产的环境将在稍后的流程中出现。

集成测试

集成测试是测试应用程序中定义明确的组件在使用外部依赖项运行时能否正确执行其功能的过程。这些外部依赖项可能是其他自定义开发的组件、您用于应用程序的 AWS 服务、第三方依赖项和本地依赖项。  本指南重点介绍可证明应用程序弹性的集成测试。它假设已经存在可以证明软件功能准确性的单元测试和集成测试。

我们建议您设计集成测试,专门测试您已实现的弹性模式,例如断路器模式或减载(参见第 2 阶段:设计和实施)。面向弹性的集成测试通常涉及向应用程序施加特定的负载,或者使用诸如 () 之类的功能故意对环境造成干扰。AWS Fault Injection ServiceAWS FIS理想情况下,应将所有集成测试作为 CI/CD 管道的一部分运行,并确保每次提交代码时都运行测试。这可以帮助您快速检测导致违反弹性目标的任何代码或配置更改并做出反应。大规模分布式应用程序非常复杂,即使是微小的更改也会显著影响应用程序中看似无关的部分的弹性。尝试在每次提交时运行测试。 AWS 为操作 CI/CD 管道和其他 DevOps 工具提供了一套出色的工具。有关更多信息,请参阅 AWS 网站上的 DevOps “简介”。 AWS

自动部署管道

部署到预生产环境并在预生产环境中进行测试是一项重复而复杂的任务,最好留给自动化处理。该过程的自动化可以腾出人力资源,减少出错的机会。自动执行此过程的机制通常被称为管道。在创建管道时,我们建议您设置一系列越来越接近生产配置的测试环境。您可以使用这一系列的环境来反复测试您的应用程序。第一个环境提供的功能集比生产环境更为有限,但成本要低得多。后续环境应添加服务和扩展,以更紧密地反映生产环境。

首先在第一个环境中进行测试。在您的部署通过第一个测试环境中的所有测试后,让应用程序在一定负载下运行一段时间,以查看是否会随着时间的推移出现任何问题。确认您已正确配置可观察性(请参阅本指南后面的警报精度),以便可以检测出现的任何问题。成功完成此观察期后,将您的应用程序部署到下一个测试环境并重复该过程,在环境支持的范围内添加其他测试或加载。以这种方式对应用程序进行了充分的测试后,您可以使用先前设置的部署方法将应用程序部署到生产环境中(请参阅本指南前面的 “定义 CI/CD 策略”)。Amazon Builders Library 中的 “自动执行安全、无需动手的部署” 一文是描述亚马逊如何自动部署代码的绝佳资源。生产部署之前的环境数量会有所不同,具体取决于应用程序的复杂性及其依赖关系的类型。

负载测试

从表面上看,负载测试类似于集成测试。您可以测试应用程序的离散函数及其外部依赖关系,以验证其是否按预期运行。然后,负载测试不仅仅是集成测试,而是侧重于应用程序在定义明确的负载下如何运行。负载测试需要验证功能是否正确,因此必须在成功完成集成测试之后进行。重要的是要了解应用程序在预期负载下的响应情况,以及当负载超出预期时应用程序的行为。这可以帮助您验证您是否已经实施了必要的机制,以确保您的应用程序在极端负载下仍能保持弹性。有关负载测试的综合指南 AWS,请参阅 AWS 解决方案库 AWS中的分布式负载测试

隐私网站条款Cookie 首选项
© 2025, Amazon Web Services, Inc. 或其附属公司。保留所有权利。