通过设计来满足容量需求

确保有足够的库存以满足你预计的需求。

通过尽早关注性能，可以保持领先，这样做是个好主意。 应测量基线并大致了解系统哪些部分可能会导致问题。 无需运行完整的性能测试或深入了解详细的优化才能执行此作。 采取这些早期步骤有助于在开发生命周期开始时为良好的性能管理设置。

尝试将系统视为整体，而不是专注于各个部分。 现在不是微调的时候了。 过早地对性能进行详细调整可能会影响其他方面的平衡。 随着进一步前进，就像开始用户验收测试或更接近生产时一样，你将能够确定哪些领域确实需要额外的优化。

示例场景

Contoso Manufacturing 构建了一个基于 Java Spring 的微服务应用，可帮助他们密切关注和微调其制造流程。 现在，开发和运营团队正在努力将应用从本地设置转移到 Azure。

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

有效地设计工作负载

在整个技术堆栈中选择正确的资源，以便你可以达到性能目标，并确保一切都能很好地协同工作。 查找能够处理可伸缩性需求的功能，并尝试在分配量和系统实际需要多少之间取得良好的平衡。 这些注意事项可帮助你有效应对意外激增。

分析每个资源可以执行的工作时，可确保系统的每个部分都发挥作用并提升整体性能。 它还有助于查找要利用的任何内置缩放功能。

调整资源以适应实际需求意味着可以在处理需求变化时避免过度预配，从而节省成本。

Contoso 的挑战

• 现在，Contoso 正在完全管理本地应用环境，这给团队带来了很大的压力。 它们处理从设置和维护服务器、网络和存储到配置和更新 Java Spring 服务运行时及其所有依赖项等所有内容。

• 团队期待着使用 Azure Spring Apps 迁移到 PaaS 模型，这将使团队能够更加专注于确保应用程序提供预期的业务价值，减少管理基础结构的时间。

• 此应用程序在 Contoso 的业务中扮演着重要角色，并且具有严格的性能要求。 因此，作为迁移的一部分，团队需要确保他们所做的技术选择将支持这些要求。

应用方法和结果

• 团队比较不同的计划后，他们选择 Azure Spring Apps Standard 计划，该计划为 Spring Boot 应用提供完全托管服务，并针对生产流量进行了优化。 标准计划支持每个应用程序最多 500 个实例，为他们提供大量的计算容量，以涵盖其最高预期使用量。

• 可将服务配置为在需求增加时横向扩展，并在不再需要额外计算资源时自动收缩。

• 团队还了解了企业版方案，因为它可以支持每个应用程序的 1,000 个实例。 但他们决定，现在不需要这种容量。 他们还有信心，他们不需要此阶段企业计划附带的支持级别或额外功能。

正确预测容量需求

若要构建更强大的性能模型，请根据预期需求和所选资源实际可以处理的需求来规划容量。 使用预测建模提前完成任何更改，无论这些更改是预期还是意外。 并确保你具有明确的性能目标，你可以将其转化为团队可以处理的技术要求。

采用此方法可帮助你更高效地使用资源，且无需过度预配即可满足需求，这意味着可以避免花费比所需支出更多。 它还可让你更好地了解设计决策对性能的影响。

Contoso 的挑战

• 为了充分利用生产机械，Contoso 制造按轮流计划运行生产线。 他们可以在整个一天中的不同时间制作不同的产品，并保持一切高效运行。

• 生产线上的每个产品都需要不同的操作，这意味着控制应用程序必须处理不同级别的计算需求。 当生产线从一个产品切换到另一个产品时，控制应用程序必须执行几个需要增加计算容量的额外任务，例如分析上次运行中的数据并更新计算机的控制算法。

应用方法和结果

• 为了在更换期间处理更高的需求，团队首先识别出负责管理这一过程的流程。 它们记录了这些流所需的性能，并通过使用应用程序本地版本的数据来估算流量大小。 借助这些信息，他们继续估算这些流中微服务所需的计算容量。

• 这些组件设立了自动缩放机制，以确保额外的资源可以在转换时段开始之前就已准备就绪，随后在这些任务完成后进行缩减。

• 团队计划在将应用程序推出到生产环境之前微调自动缩放设置，具体取决于它在新环境中的实际执行方式。

概念证明部署

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

POC 是检查设计是否真正满足性能目标的一种好方法，以及这些目标在一开始是否有意义。 根据预期的负载，可以看到计划容量是否足以满足这些目标。 还可以验证设计选择如何影响成本。

Contoso 的挑战

• 虽然应用程序仍在开发中，但团队正在使用设备模拟器运行广泛的负载和性能测试。 他们正在使用这些测试中学到的内容来微调自动缩放设置。

• 可能影响自动缩放工作的一件事是 Azure Spring Apps 环境和制造车间 IoT 设备之间的潜在网络延迟。 这些设备通过 ExpressRoute 连接到 Azure。 团队怀疑与本地设置相比，Azure 中的延迟可能更高。 他们还认为延迟可能会因一天中的时间或设备所在的位置而异。

• 如果延迟上升，则可能会影响每个微服务实例可以处理的事务数。

应用方法和结果

• 为了测试其假设并收集指标以微调设置，团队决定在 Azure 中推出 POC。 他们构建了一个测试 Azure Spring Apps 环境，该环境与分布在制造车间的 IoT 设备通信。 这些设备连接到本地网络，并注册到 IoT 中心。 全天，测试应用会随机 ping 设备并记录获取响应所需的时间。

• 在此 POC 期间收集的数据与负载测试结果结合起来，将为团队提供更清晰的了解，帮助他们确定初始生产启动所需的计算容量。

• 根据 POC 的学习，该团队还致力于通过更好地反映实际响应时间来改进负载测试用例的方法。