通过设计来满足容量需求

已完成
提供充足的供应来满足预期的需求。

主动衡量性能非常重要。 测量性能涉及测量基线,以及初步了解系统中哪些组件可能会带来挑战。 无需执行完整性能测试或通过精细优化即可实现此目的。 通过执行这些初始步骤,可以在开发生命周期的早期奠定有效的性能管理基础。

检查整个系统,而不是专注于各个组件。 避免在此阶段进行微调。 进行精细的性能改进会导致在其他领域做出权衡。 随着你在生命周期中取得进展,并开始进行用户验收测试或进入生产阶段,可以快速确定哪些领域需要进一步优化。

示例方案

Contoso Manufacturing 开发了一个内部使用的基于 Java Spring 的微服务应用,用于监视和优化其制造过程。 工作负载团队正在将当前托管在本地的应用迁移到 Azure。

由 Azure 托管的应用将基于 Azure Spring Apps、Azure Database for MySQL 和 Azure IoT 中心构建。 Contoso 已经与 Azure 建立 ExpressRoute 连接。

有效地设计工作负载

跨技术堆栈选择适当的资源,这可以支持你实现性能目标并与系统集成。 请考虑可以满足可伸缩性要求的功能,并在资源分配和系统要求之间找到适当的平衡,以高效处理意外激增。

通过分析资源的不同功能,可以确保每个组件有助于系统的整体功能和性能,并且可以确定可以利用的缩放功能。

正确调整大小的资源无需过度预配即可满足需求变化,从而节省成本。

Contoso 的挑战

  • 现有的本地应用环境基础结构完全由 Contoso 管理,这给团队带来了重大负担。 目前,他们需要预配和维护服务器、网络和存储,以及配置和更新 Java Spring 服务运行时和所有依赖项。
  • 团队期待使用 Azure Spring Apps 迁移到 PaaS 模型,这会支持团队更加专注于确保应用程序提供预期的业务价值,并减少在管理基础结构方面投入的时间。
  • 此应用程序对于 Contoso 的业务至关重要,并且具有严格的性能要求,因此他们需要确保在迁移过程中做出的技术选择可以支持他们能够满足这些要求。

应用方法和结果

  • 比较可用的不同计划后,团队选择了 Azure Spring Apps 标准计划,该计划可以为 Spring Boot 应用提供完全托管服务,并针对生产流量进行了优化。 在标准计划中,每个应用最多有 500 个实例,因此能够提供足够的计算容量,以达到预期的最大使用量。
  • 此外,可以将服务配置为根据需要进行横向扩展,并在不需要额外容量时横向缩减计算资源。
  • 该团队查看了企业版计划,该计划能够纵向扩展到每个应用最多 1000 个实例,但决定目前不需要该容量。 他们还确信,他们不需要企业版计划提供的支持级别,也不需要其专有功能的其余部分。

正确预测容量需求

根据需求和所选资源的功能制订容量规划,以扩充性能模型。 使用预测建模技术来预测因为可预测和意外的变化而发生的容量变化。 定义可转换为技术要求的性能目标。

通过采用此方法,可以有效地使用资源并满足需求,而无需过度预配,从而避免不必要的成本。 此外,它还将帮助你了解设计选择会如何影响性能。

Contoso 的挑战

  • 为了最大程度地有效使用生产机械,Contoso 的生产线将按周期计划运行,从而可以在一天的不同时间生产不同的产品。
  • 每个产品需要不同的操作,因此控制应用程序的计算需求也会不同。 在产品之间的切换过程中,控制应用程序需要执行各种需要增加计算容量的任务,例如分析以前生产运行中的数据并更新计算机的控制算法。

应用方法和结果

  • 为了在切换期间满足更高的需求,团队首先确定了处理切换功能的流、记录其性能要求,并根据应用程序的本地版本估算其事务量。 借助此数据,团队会继续估算属于目标流的微服务所需的计算容量。
  • 为这些组件配置自动缩放,以确保在切换期之前预配其他资源,并在任务完成后将其释放。
  • 在将应用部署到生产环境之前,将根据新环境中的实际性能调整自动缩放设置。

概念证明部署

实现验证技术要求和设计选择的概念证明 (POC)。

概念证明有助于验证设计,以确定系统是否可以满足性能目标以及这些目标是否现实。 根据预期的负载,可以验证预期容量能否满足性能目标。

此外,验证设计选项的成本影响。

Contoso 的挑战

  • 在开发过程中,团队使用设备模拟器对应用程序功能执行广泛的负载和性能测试,并使用此信息来优化自动缩放配置。
  • 可能影响自动缩放配置有效性的一个方面是,从 Azure Spring Apps 环境到制造车间中的 IoT 设备(通过 ExpressRoute 连接到 Azure)的潜在网络延迟。 团队推测 Azure 中的延迟将高于应用本地版本,并且延迟也可能受到其他因素(例如一天中的时间或设备位置)的影响。
  • 延迟增加可能会影响每个微服务实例能够处理的事务量。

应用方法和结果

  • 团队决定将 POC 部署到 Azure 以验证其假设,并收集可用于优化配置的指标。 他们构建了一个测试 Azure Spring 应用来与分布在制造车间的 IoT 设备通信。 IoT 设备连接到本地网络,并注册到 Azure IoT 中心。 测试应用程序可通过发送简单的 ping 在一天中随机连接到设备,并记录接收响应所需的时间。
  • 通过结合在此 POC 期间捕获的数据与负载测试的结果,团队能够在准备初始生产启用时更准确地估计所需的计算容量。
  • 该团队还在研究如何进一步改进用于负载测试的测试用例,以基于从 POC 获得的经验模拟更切合实际的响应时间。

知识检查

1.

在通过设计来满足容量要求的情况下,可以使用哪种方法为工作负载选择合适的资源?

2.

应将预测建模用于什么方面?

3.

Contoso 尝试通过 POC 部署进行验证的一个假设是什么?