设计利用率优化

充分利用工具和作。 确保它们满足解决方案的功能和非功能要求。

不同的服务具有不同的功能和价格点。 选择计划后，不要让这些功能浪费。 找到充分利用它们的方法，并得到你的钱的价值。 此外，请关注计费模型。 检查是否有更适合实际使用服务的计费模型是明智的。

示例方案

Contoso 大学托管了一个商业现成的（科茨）系统，帮助教职员工管理课程，并允许学生注册。 它连接到基于云的教育管理系统，他们计划在几年内完全切换到。 目前，他们希望优化自定义集成部件的成本。

在 Azure Database for MySQL 上运行的数据库除外，科茨产品的技术解决方案通常被视为黑匣子。 自定义集成是一个 Azure 持久函数，在用于托管大学网站的标准 Azure 应用服务计划上运行，但不再如此。 Durable 函数是使用 Azure 存储的 Python 应用。 它每天晚上将数据从 MySQL 数据库同步到基于云的 API。

使用资源的完整值

只购买所需的内容，并使用你支付的所有内容。

某些资源 SKU 附带了内置功能，用于性能、安全性和可靠性。 如果要为其付费，请确保使用它们。 如果你不需要这些功能，请选择更简单的 SKU 来节省资金。

Contoso 的挑战

• 持久函数在最初为公共网站调整大小的标准应用服务计划中运行，但此后该网站已停用。

• 团队从未重新评估 SKU，因此他们仍然为他们不使用的功能和容量付费。

• 他们不确定集成工作负载实际需要哪些功能。

应用方法和结果

• 团队回顾了当前的应用服务计划，并得出结论，集成不需要相同的可伸缩性或性能级别，并且可由较低层配置支持。

• 它们将函数移动到仍支持持久函数的较低层计划，但成本要低得多。

• 他们还检查其 MySQL SKU，并确认它已针对当前工作负荷进行权限化。

• 这些更改有助于降低成本，而不会影响性能或可靠性。

优化高可用性设计

如果你已经支付了资源费用，作为恢复计划的一部分，请优先考虑主动-主动或仅主动模式的部署，而不是主动-被动模式。

如果你的设计默认使用主动-被动模型，那么你可能有闲置的资源可以使用。 转换为主动-主动可能使你能够在不超支的情况下满足负载均衡和规模爆发的要求。 如果你可以使用仅主动模型来满足恢复目标，则可以完全消除这些资源的成本。

Contoso 的挑战

• COTS 应用程序使用为同区域高可用性配置的 Azure Database for MySQL 灵活服务器，该高可用性模式在与主服务器相同的可用性区域中提供备用服务器。 它们还启用了自动备份。

• 工作负荷的恢复点目标（RPO）在 12 小时内相对较长，恢复时间目标（RTO）在学校当天为 3 小时。

• 根据以前的恢复测试，团队知道他们可以通过自动故障切换到备用服务器来实现 RPO 和 RTO 目标。 他们还测试了从备份中恢复数据库，可以实现此场景中的目标。

应用方法和结果

• 工作负荷团队重新评估高可用性设计的好处，而服务的成本是单个实例的两倍。

• 团队测试生成新实例并从备份中恢复数据库，并且他们确信它们仍符合其恢复目标，因此他们决定消除备用实例。

• 团队更新灾难恢复计划，以反映新的恢复策略，并通过新配置实现成本节省。

使用需求缩放智能

根据实际需求调整容量。

在需求增加时纵向扩展，而不是随时预配高峰使用量，并在需求下降时纵向扩展。 此方法使成本与实际使用情况保持一致。

Contoso 的挑战

• 集成函数每晚都会运行，但应用服务计划始终保持活动状态。

• 他们为大部分时间处于空闲状态的计算资源付费。

• 他们尚未探索在不使用服务时纵向缩减或暂停服务的选项。

应用方法和结果

• 团队将应用服务计划配置为在非工作时间缩减。

• 他们探索将函数移动到 Azure 容器应用或 Azure Functions 消耗计划，该计划可缩放到零。

• 他们还设置警报来监视使用情况并根据需要调整缩放规则。

• 这些更改有助于将成本与实际使用情况保持一致，并减少浪费。