你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

自动缩放

  • 项目

自动缩放是动态分配资源以满足性能需求的过程。 当工作量增大时，应用程序可能需要额外的资源来维持所需的性能级别和满足服务级别协议 (SLA)。 当需求降低，不再需要额外的资源时，可以取消分配资源，最大程度地降低成本。

自动缩放可以利用云托管环境的灵活性，同时降低管理开销。 这样就不怎么需要操作员持续监视系统性能并做出添加或删除资源的决策。

应用程序缩放有两种主要的方式：

  • 垂直缩放，也称为增加和减少，表示改变资源的容量。 例如，可将应用程序移动到更大的 VM 中。 垂直缩放在重新部署时通常会要求系统暂时不可用。 因此，自动化垂直缩放并不常见。

  • 水平缩放，也称为扩大和缩小，表示添加或删除资源的实例。 在预配新资源时，应用程序无需中断，可持续运行。 当预配过程完成时，解决方案就已部署在这些额外资源上。 如果需求降低，额外的资源可以完全关闭并解除分配。

许多基于云的系统（包括 Microsoft Azure）支持自动水平缩放。 本文的余下内容重点介绍水平缩放。

注意

自动缩放主要适用于计算资源。 虽然可以水平缩放数据库或消息队列，但这通常涉及非自动的数据分区。

自动缩放组件

自动缩放策略通常包括以下部分：

  • 位于应用程序、服务和基础结构级别的检测和监视系统。 这些系统可捕获响应时间、队列长度、CPU 利用率和内存使用量等关键指标。
  • 根据预定义的阈值或计划来评估这些指标并决定是否缩放的决策逻辑。
  • 缩放系统的组件。
  • 测试、监视和优化自动缩放策略，以确保它按预期工作。

Azure 提供用于处理常见方案的内置自动缩放机制。 如果某个特定服务或技术没有内置自动缩放功能，或者你有超出其功能的特定自动缩放需求，则可考虑自定义实现。 自定义实现将收集操作和系统指标，分析这些指标，然后相应地缩放资源。

配置 Azure 解决方案的自动缩放

Azure 为大多数计算选项提供内置自动缩放功能。

这些计算选项都使用 Azure Monitor 自动缩放来提供一组通用的自动缩放功能。

  • Azure Functions 与以前的计算选项不同，因为无需配置任何自动缩放规则。 相反，当代码正在运行时，Azure Functions 会自动分配计算能力，根据需要进行横向扩展，以处理负载。 有关详细信息，请参阅为 Azure Functions 选择正确的托管计划。

最后，自定义自动缩放解决方案有时非常有用。 例如，可使用 Azure 诊断和基于应用程序的指标，以及自定义代码来监视和导出应用程序指标。 然后，可根据这些指标定义自定义规则，并使用资源管理器 REST API 来触发自动缩放。 但是，自定义解决方案并不容易实施，只应在前述方法都无法满足要求时才加以考虑。

如果平台的内置自动缩放功能可以符合要求，就使用此内置功能。 否则，请仔细考虑是否真正需要更复杂的缩放功能。 其他要求的示例包括更细致的控制、检测缩放触发事件的其他方式、跨订阅缩放和缩放其他类型的资源。

使用 Azure Monitor 自动缩放

Azure Monitor 自动缩放为虚拟机规模集、Azure 应用服务和 Azure 云服务提供一套通用的自动缩放功能。 可按计划，也可根据运行时指标（如 CPU 或内存使用率）执行缩放。

示例：

  • 在工作日扩大到 10 个实例，在周六和周日缩小到 4 个实例。
  • 如果 CPU 平均使用率在 70% 以上，则扩大一个实例；如果 CPU 使用率低于 50%，则缩小一个实例。
  • 如果队列中消息数量超过特定阈值，则扩大一个实例。

提高负载时纵向扩展资源，确保可用性。 同样，在低使用量的时候，还可以纵向缩减，以便优化成本。 始终使用横向扩展和横向缩减规则组合。 否则，自动缩放只会在一个方向上发生，直到它达到配置文件中设置的阈值（最大或最小实例计数）。

请选择对工作负荷安全的默认实例计数。 如果未设置最大或最小实例计数，则基于该值进行缩放。

有关内置指标列表，请参阅 Azure Monitor 自动缩放常用指标。 还可通过使用 Application Insights 来实现自定义指标。

可通过使用 PowerShell、Azure CLI、Azure 资源管理器模板或 Azure 门户来配置自动缩放。 要实现更细化的控制，请使用 Azure 资源管理器 REST API。 Azure 监视服务管理库和 Microsoft Insights 库（预览版）是可让用户从不同的资源收集指标以及利用 REST API 执行自动缩放的 SDK。 对于不支持 Azure 资源管理器的资源，或者使用 Azure 云服务时，可以使用服务管理 REST API 进行自动缩放。 在其他所有情况下，请使用 Azure 资源管理器。

使用 Azure 自动缩放时，请注意以下几点：

  • 考虑是否可以准确预测应用程序上的负载以使用计划的自动缩放，添加和删除实例以满足预期的需求高峰。 如果不可行，请根据运行时指标使用被动自动缩放，以处理无法预测的需求变化。 通常情况下，可以组合使用这些方法。 例如，如果知道应用程序何时最繁忙，则可以创建一个策略，以根据时间计划添加资源。 这有助于确保容量在需要时可供使用，并且不会在启动新实例时发生延迟。 对于每个计划的规则，请定义在该期间允许被动自动缩放的指标，以确保应用程序能够处理持续但无法预测的需求高峰。

  • 通常很难了解指标与容量要求之间的关系，尤其是在最初部署应用程序后。 在一开始多预配一些附加容量，监视并调整自动缩放规则，使容量更接近实际负载的需要。

  • 配置自动缩放规则，然后监视应用程序在一段时间内的性能。 如果需要，请使用这种监视的结果来调整系统的缩放方式。 但请记住，自动缩放不是即时起效的过程。 它需要时间来对指标（例如平均 CPU 利用率超过或低于指定的阈值）做出反应。

  • 使用基于测得触发器属性（例如 CPU 使用量或队列长度）的检测机制的自动缩放规则使用一段时间内的聚合值而不是即时值来触发自动缩放操作。 默认情况下，聚合是值的平均值。 这可以防止系统反应太快，或导致快速震荡。 这还可以使自动启动的新实例顺利进入运行模式，避免当新实例正在启动时，又发生其他自动缩放操作。 对于 Azure 云服务和 Azure 虚拟机，聚合的默认期限为 45 分钟，指标需要经过这段时间后才为了响应需求高峰而触发自动缩放。 你可使用 SDK 更改聚合周期，但请注意，小于 25 分钟的周期可能会导致不可预知的结果。 对于 Web 应用，平均期限要短得多，这样便可以在平均触发测量值更改约五分钟后提供新实例。

  • 避免横向缩减和横向扩展操作不断地来回切换时出现摇摆。 假设有两个实例，上限为 80% CPU，下限则为 60%。 当负载为 85% 时，会添加另一个实例。 一段时间后，负载将减小到 60%。 在横向缩减之前，自动缩放服务会在删除实例时计算三个实例的总负载分布情况，此时负载为 90%。 这意味着必须立即再次横向扩展。 因此，它会跳过横向缩减，并且可能永远不会出现预期的缩放结果。

    可以通过在横向扩展和横向缩减阈值之间选择足够的边距来控制这种摇摆情况。

  • 用于自动缩放的最大和最小实例数进行重置手动缩放。 如果手动将实例计数更新为高于或低于最大值的值，则自动缩放引擎会自动缩放回最小值（如果低于）或最大值（如果高于）。 例如，将范围设置在 3 和 6 之间。 如果有一个正在运行的实例，则自动缩放引擎会在下次运行时缩放为三个实例。 同样，如果将缩放规模手动设置为八个实例，则自动缩放会在下次运行时收缩回六个实例。 手动缩放效果只是暂时的，除非也重置了自动缩放规则。

  • 自动缩放引擎一次只处理一个配置文件。 如果不满足条件，则检查下一个配置文件。 将关键指标排除在默认配置文件外，因为最后才会检查该配置文件。 在配置文件中，可以设有多个规则。 进行横向扩展时，只要满足任一规则，自动缩放就会运行。 进行缩小时，自动缩放需要满足所有规则。

有关 Azure Monitor 如何缩放的详细信息，请参阅自动缩放最佳做法。

  • 如果使用 SDK 而不是门户配置自动缩放，则可以指定更详细的计划，在执行该计划期间，规则将处于活动状态。 还可以创建自己的度量值，并将其与自动缩放规则中的现有度量值一起使用，或单独使用。 例如，建议使用备选计数器，如每秒的请求数或平均内存可用性，或使用测量特定业务流程的自定义计数器。

  • 自动缩放 Service Fabric 时，由于群集中的节点类型由后端的虚拟机规模集构成，因此需要为每个节点类型设置自动缩放规则。 在设置自动缩放之前请考虑必须具有的节点数。 对于主节点类型所必须具有的最小节点数受所选择的可靠性级别影响。 有关详细信息，请参阅使用自动缩放规则横向缩减或横向扩展 Service Fabric 群集。

  • 可以使用门户将 SQL 数据库实例和队列等资源链接到云服务实例。 这样，便可以更轻松地访问每个链接资源的各个手动和自动缩放配置选项。 有关详细信息，请参阅如何：将资源链接到云服务。

  • 配置多个策略和规则时，它们可能相互冲突。 自动缩放使用以下冲突解决规则来确保始终有足够的实例在运行状态：

    • 横向扩展操作始终优先于横向缩减操作。
    • 当横向扩展操作发生冲突时，使实例数增幅最大的规则优先启用。
    • 当向内缩放操作发生冲突时，使实例数降幅最小的规则优先。

  • 在应用服务环境中，可使用任何辅助池或前端指标来定义自动缩放规则。 有关详细信息，请参阅自动缩放和应用服务环境。

应用程序设计注意事项

自动缩放不是即时见效的解决方案。 只是将资源添加到系统或运行进程的更多实例并不能保证提高系统性能。 设计自动缩放策略时，请注意以下几点：

  • 系统必须设计为支持水平缩放。 不要在实例相关性方面做出假设；不要设计需要代码始终在特定的进程实例中运行的解决方案。 水平缩放云服务或网站时，不要假设一系列来自同一源的请求始终路由到同一实例。 出于相同原因，请将服务设计为无状态，以避免需要将一系列来自应用程序的请求始终路由到同一服务实例。 在设计从队列读取并处理消息的服务时，不要假设哪个服务实例处理哪个特定消息。 自动缩放可能会在队列长度增大时启动其他服务实例。 使用者竞争模式说明了如何解决这种情况。

  • 如果解决方案实施长时间运行的任务，请将此任务设计为同时支持向外和向内缩放。 如果不保持应有的谨慎，这种任务在系统向内缩放时会阻止进程实例完全关闭；如果进程被强行终止，则可能会丢失数据。 理想的情况是，重构长时间运行的任务并分解处理，使其以较小且不连续的块执行。 管道和筛选器模式提供了有关如何实现此目的的示例。

  • 或者，可以实施检查点机制，用于定期记录任务的状态信息，并将此状态保存在运行任务的任何进程实例可以访问的持久性存储中。 这样，如果过程关闭，可以使用另一个实例从最后一个检查点继续进它所执行的工作。 有一些库提供此功能，例如 NServiceBus 和 MassTransit。 它们以透明方式保留状态，其中间隔与 Azure 服务总线队列中的消息处理保持一致。

  • 当后台任务在独立的计算实例（例如云服务托管应用程序的辅助角色）上运行时，可能需要使用不同的缩放策略来缩放应用程序的不同部分。 例如，可能需要部署其他用户界面 (UI) 计算实例而不增加后台计算实例数，或是相反。 如果提供不同级别的服务（例如基本和高级服务包），可能需要使用比基本服务包更主动的高级服务包的计算资源才能符合 SLA。

  • 考虑 UI 和后台计算实例通信中的队列长度。 将其用作自动缩放策略的条件。 这也许能反映当前负载与后台任务处理容量之间的不平衡或差异。 有一个略显复杂但更有效的属性可作为缩放决策的基础。 使用发送消息和完成消息处理之间的时间，我们称之为“关键时间”。 如果此关键时间值低于有意义的业务阈值，即使队列长度较长，也无需缩放。

    • 例如，队列中可能有 50,000 条消息，但是最早的消息的关键时间是 500 毫秒，并且该终结点正在处理与第三方 Web 服务的集成以发送电子邮件。 公司的利益干系人可能会认为该时间段不值得花费额外的资金进行缩放。
    • 另一种情况是，队列中可能有 500 条消息，关键时间都为 500 毫秒，但终结点是一些实时在线游戏关键路径的一环，公司的利益干系人对其定义的是 100 毫秒或更少的响应时间。 在这种情况下，缩放是有意义的。
    • 为了在自动缩放决策中利用关键时间，在发送和处理消息时，让库自动将相关信息添加到消息标头中很有用。 NServiceBus 就是一种能提供此功能的库。

  • 如果自动缩放策略基于度量业务进程（例如每小时订单数或复杂事务的平均执行时间）的计数器，请确保完全了解这些计数器类型的结果与实际计算容量要求之间的关系。 可能需要缩放多个组件或计算单位来应对业务进程计数器的变化。

  • 若要防止系统过度地向外缩放并避免由于运行数千个实例而带来的成本开销，请考虑限制可以自动添加的实例数上限。 大多数自动缩放机制允许指定规则的实例数上限和下限。 此外，如果部署的实例数已达到上限而系统仍然过载，请考虑适当地降低系统提供的功能。

  • 请记住，自动缩放可能不是处理工作负荷中突发高峰的最适当机制。 设置并启动新服务实例或将资源添加到系统都需要花费时间，而当这些附加资源可供使用时，高峰需求可能已成为过去。 在这种情况下，限制服务可能更适合。 有关详细信息，请参阅限制模式。

  • 相比之下，如果希望在事务量快速波动时有足够的容量处理所有请求，并且成本不是主要考虑因素，那么，请考虑使用激进的自动缩放策略来更快速地启动附加实例。 还可以使用计划的策略在最大负载来临前预先启动足量的实例。

  • 自动缩放机制应该监视自动缩放过程，并记录每个自动缩放事件的详细信息（触发的事件、添加或删除了哪些资源，以及时间）。 在创建自定义自动缩放机制时，请确保它包含此功能。 分析信息以帮助度量自动缩放策略的有效性，并根据需要进行优化。 在短时间内使用模式变得明显，以及长期业务拓展或对应用程序的要求变化时，可以进行优化。 如果应用程序达到定义的自动缩放上限，机制可以提醒操作人员，让操作人员手动启动其他资源（如果必要）。 请注意，在这种情况下，操作员可能还要负责在工作负荷减轻后手动删除这些资源。

实施自动缩放时，以下模式和指南也可能与方案相关：

  • 限制模式。 此模式描述当需求增大而对资源产生极大负载时，应用程序如何继续工作并满足 SLA。 限制可与自动缩放配合使用，以避免系统向外缩放时失控。

  • 使用者竞争模式。 此模式描述如何实施服务实例池，以便处理来自任何应用程序实例的消息。 自动缩放可用于启动和停止服务实例，以符合预期的工作负荷。 此模式可让系统同时处理多个消息，以优化吞吐量、提高伸缩性和可用性，以及平衡工作负荷。

  • 监视和诊断。 检测和遥测在收集信息以促成自动缩放过程方面至关重要。