自动缩放是动态分配资源以满足性能需求的过程。 当工作量增大时，应用程序可能需要更多资源来维持所需的性能级别和满足服务级别协议 (SLA)。 随着需求减少且不再需要额外资源，可以取消分配这些资源，以最大程度地降低成本。
自动缩放可以利用云托管环境的灵活性，同时降低管理开销。 这样就不怎么需要操作员持续监视系统性能并做出添加或删除资源的决策。
应用程序缩放有两种主要的方式：
垂直缩放（也称为纵向扩展和缩减）意味着更改资源的容量。 例如，可以将应用程序移动到更大的虚拟机大小。 垂直缩放通常会导致系统在重新部署过程中暂时不可用。 因此，自动化垂直缩放不太常见。
水平缩放（也称为横向扩展和收缩）意味着添加或删除资源的实例。 在预配新资源时，应用程序无需中断，可持续运行。 预配过程完成后，解决方案将部署在这些额外的资源上。 如果需求下降，可以完全关闭并取消分配额外的资源。
许多基于云的系统（包括 Microsoft Azure）都支持自动水平缩放。 本文的其余部分重点介绍水平缩放。
注释
自动缩放主要适用于计算资源。 虽然可以水平缩放数据库或消息队列，但此过程通常涉及 数据分区，这通常不是自动化的。
自动缩放组件
自动缩放策略通常涉及以下组件：
应用程序、服务和基础结构级别的检测和监视系统。 这些系统捕获关键指标，例如响应时间、队列长度、CPU 使用率和内存使用情况。
决策逻辑根据预定义的阈值或计划评估这些实时使用情况指标，并决定是否缩放。
组件和机制执行缩放操作。 理想情况下，这些组件和机制应与工作负荷代码本身分离，并作为外部进程进行管理。 处于空闲状态或超负荷的代码不应负责自我调整。
测试、监视和优化自动缩放策略的功能，以确保其按预期运行。
Azure 提供解决常见方案的内置自动缩放机制。 如果特定服务或技术没有内置自动缩放功能，或者你具有超出其功能的特定自动缩放要求，请考虑使用自定义实现。 自定义实现收集操作指标和系统指标，分析这些指标，并相应地调整资源。
为 Azure 解决方案配置自动缩放
Azure 为大多数计算选项提供内置的自动缩放功能。
Azure 虚拟机 通过 虚拟机规模集自动缩放，这些规模集将一组虚拟机作为组进行管理。 有关详细信息，请参阅 使用自动缩放和虚拟机规模集。
Azure Service Fabric 支持通过虚拟机规模集自动缩放。 Service Fabric 群集中的每个节点类型都设置为单独的虚拟机规模集。 每个节点类型可以独立缩容或扩容。 有关详细信息，请参阅 使用自动缩放规则对 Service Fabric 群集进行扩展和缩减。
Azure 应用服务 具有内置的自动缩放功能。 自动缩放设置适用于应用服务中的所有应用。 有关详细信息，请参阅手动或自动调整实例计数及在应用服务中扩展应用。
这些计算选项都使用 Azure Monitor 自动缩放功能 来提供一组常见的自动缩放功能。
- Azure Functions 不同于以前的计算选项，因为无需配置任何自动缩放规则。 相反，Azure Functions 会在代码运行时自动分配计算能力。 Azure Functions 会根据需要进行横向扩展以处理负载。 有关详细信息，请参阅 为 Azure Functions 选择正确的托管计划。
自定义自动缩放解决方案有时可能很有用。 例如，可以使用 Azure 诊断和基于应用程序的指标以及自定义代码来监视和导出应用程序指标。 然后，可以根据这些指标定义自定义规则，并使用 Azure 资源管理器 REST API 触发自动缩放。 但是，自定义解决方案并不简单，仅当上述任何方法都无法满足你的要求时，才应考虑这一点。
如果平台满足你的要求，请使用平台的内置自动缩放功能。 如果没有，请仔细考虑是否需要更复杂的缩放功能。 其他要求的示例可能包括更多的控制粒度、检测缩放所需的触发事件的不同方式、跨订阅实现缩放，以及缩放其他类型的资源。
使用 Azure Monitor 自动缩放功能
Azure Monitor 自动缩放功能为虚拟机规模集、应用服务和 Azure 云服务提供了一组常见的自动缩放功能。 缩放可以按计划执行，也可以基于运行时指标（例如 CPU 或内存使用情况）。
请考虑以下示例：
在工作日扩展到 10 个实例，星期六和星期日缩减至 4 个实例。
如果平均 CPU 使用率超过 70%，则横向扩展一个实例；如果 CPU 使用率低于 50%，则横向缩减一个实例。
如果队列中消息数量超过特定阈值，则扩大一个实例。
增加负载时纵向扩展资源，以确保可用性。 在使用率低时，缩小规模，以便优化成本。 始终使用横向扩展和横向缩减规则组合。 否则，自动缩放仅以一个方向进行，直到达到配置文件中设置的阈值（最大或最小实例计数）。
选择适合工作负荷的默认实例计数。 如果未设置最大或最小实例计数，则资源将根据该值进行缩放。
有关内置指标的列表，请参阅 Azure Monitor 自动缩放常见指标。 还可以使用 Application Insights 实现自定义指标。
可以使用 PowerShell、Azure CLI、Azure 资源管理器模板或 Azure 门户配置自动缩放。 有关更详细的控制，请使用 资源管理器 REST API。 Azure 监视管理库和Microsoft见解库（预览版）是 SDK，可用于从不同资源收集指标，并使用 REST API 执行自动缩放。 对于资源管理器支持不可用的资源，或者如果您使用 Azure 云服务，可以使用服务管理 REST API 来实现自动缩放。 在所有其他情况下，请使用 Resource Manager。
使用自动缩放时，请考虑以下几点：
请考虑是否可以准确预测应用程序上的负载，以使用计划的自动缩放、添加和删除实例以满足预期的需求高峰。 如果无法，请使用基于运行时指标的被动自动缩放来处理不可预测的需求更改。 通常，可以合并这些方法。
例如，创建一个策略，根据知道应用程序最繁忙的时间计划添加资源。 额外的资源有助于确保容量在需要时可用，而不会延迟启动新实例。 对于每个计划规则，定义允许在该时间段内进行被动自动缩放的指标，以确保应用程序能够处理持续但不可预知的需求高峰。
通常很难理解指标与容量要求之间的关系，尤其是在最初部署应用程序时。 在开始时配置一点额外的容量，然后监视和优化自动缩放规则，使容量更接近实际负载。
配置自动缩放规则，然后监视应用程序随时间推移的性能。 使用此监视的结果可以根据需要调整系统缩放的方式。 但是，请记住，自动缩放不是即时过程。 对指标做出反应需要时间，例如平均 CPU 使用率超过或低于指定阈值。
使用基于度量触发器属性的检测机制的自动缩放规则，会使用随着时间推移的聚合值（而不是即时值）来触发自动缩放动作。 触发器属性包括 CPU 使用率或队列长度。 默认情况下，聚合是值的平均值。 此方法可防止系统反应太快或导致快速振荡。 它还允许自动启动的新实例有时间进入稳定的运行状态。 启动新实例时，无法执行其他自动缩放操作。 对于 Azure 云服务和 Azure 虚拟机，聚合的默认期限为 45 分钟。 因此，指标可能需要长达一段时间才能触发自动缩放，以响应需求激增。 可以使用 SDK 更改聚合周期，但小于 25 分钟的时间段可能会导致不可预知的结果。 对于应用服务的 Web 应用功能，平均周期较短，允许在更改平均触发器度量值后大约 5 分钟内提供新实例。
避免横向缩减和横向扩展操作不断地来回切换时出现摇摆。 假设有两个实例。 上限为 80% CPU，下限为 60%。 当负载为 85%时，将添加另一个实例。 经过一段时间后，负载将降低到 60%。 在自动缩放服务进行缩放之前，它会计算在移除一个实例后总负载在三个实例中的分布情况，将其调整为 90%。 它必须立即再次进行横向扩展。 因此，它会跳过缩放过程，可能无法看到预期的缩放结果。
可以通过在横向扩展和横向缩减阈值之间选择足够的边距来控制这种摇摆情况。
手动缩放将依据自动缩放时使用的最大和最小实例数进行重置。 如果手动将实例计数更新为大于或低于最大值的值，则自动缩放引擎会自动缩减到最小值（如果较低）或最大值（如果更高）。 例如，设置介于 3 和 6 之间的范围。 如果有一个正在运行的实例，则自动缩放引擎将在下次运行时缩放为三个实例。 同样，如果手动将缩放设置为 8 个实例，则在下一次运行中自动缩放会将其缩减为下一次运行中的 6 个实例。 手动缩放是暂时的，除非同时重置自动缩放规则。
自动缩放引擎一次只处理一个配置文件。 如果未满足某个条件，它将检查下一个配置。 将关键指标排除在默认配置文件外，因为最后才会检查该配置文件。 在配置文件中，可以设有多个规则。 进行横向扩展时，只要满足任何规则，自动缩放就会运行。 在横向缩减时，自动缩放要求满足所有规则。
有关 Azure Monitor 缩放方式的详细信息，请参阅 自动缩放的最佳做法。
如果使用 SDK 而不是门户配置自动扩展，则可以指定更详细的时间表，其间规则处于活动状态。 您还可以创建自己的指标，并在自动缩放规则中与现有指标一起或单独使用。 例如，你可能希望使用备用计数器，例如每秒请求数或平均内存可用性。 或者，可以使用自定义计数器来度量特定的业务流程。
自动缩放 Service Fabric 时，群集中的节点类型由后端的虚拟机规模集组成，因此需要为每个节点类型设置自动缩放规则。 考虑在设置自动缩放之前必须拥有的节点数。 您的可靠性级别决定了主节点类型所需的最小节点数。 有关详细信息，请参阅 使用自动缩放规则对 Service Fabric 群集进行扩展和缩减。
可以使用门户将 Azure SQL 数据库实例和队列等资源链接到云服务实例。 使用此方法，可以更轻松地访问每个链接资源的单独手动和自动缩放配置选项。 有关详细信息，请参阅 管理 Azure 云服务。
配置多个策略和规则时，它们可能会相互冲突。 自动缩放使用以下冲突解决规则来确保始终有足够的实例运行：
横向扩展操作始终优先于横向缩减操作。
当横向扩展操作发生冲突时，启动实例数增加最多的规则将会被优先考虑。
当缩减实例数量的操作发生冲突时，优先选择实例数量减少幅度最小的规则。
在应用服务环境中，任何工作池或前端部分的指标都可用于定义自动缩放规则。 有关详细信息，请参阅 应用服务环境概述。
应用程序设计注意事项
自动缩放不是即时见效的解决方案。 只需将资源添加到系统或运行进程的更多实例就不能保证系统的性能会提高。 设计自动缩放策略时，请注意以下几点：
系统必须设计为水平可缩放。 避免对实例相关性做出假设。 不要设计要求代码始终在进程的特定实例中运行的解决方案。 水平缩放云服务或网站时，不要假定来自同一源的一系列请求始终路由到同一实例。 出于同样的原因，设计服务是无状态的，以避免要求应用程序发出的一系列请求始终路由到服务的同一实例。 在设计从队列中读取消息并处理消息的服务时，不要对服务哪个实例处理特定消息做出任何假设。 随着队列长度的增长，自动缩放可能会启动更多服务的实例。 竞争使用者模式描述如何应对此情况。
如果解决方案实施长时间运行的任务，请将此任务设计为同时支持向外和向内缩放。 如果不进行适当的设计，此类任务可能会阻止系统缩小时进程实例被完全关闭。 或者，如果进程强行终止，它可能会丢失数据。 理想情况下，重构长时间运行的任务，并将其执行的处理分解为较小的离散区块。 有关示例，请参阅 管道和筛选器模式。
或者，你可以实现一种检查点机制，以定期记录有关任务的状态信息。 将此状态信息保存在持久存储中，运行任务的进程的任何实例都可以访问。 因此，如果进程关闭，则可以使用另一个实例从最后一个检查点恢复它正在执行的工作。 有一些库提供此功能，例如 NServiceBus 和 MassTransit。 它们以透明方式保留状态，其中间隔与 Azure 服务总线队列中的消息处理保持一致。
当后台任务在单独的计算实例上运行时，例如在云服务托管应用程序的工作角色中，可能需要使用不同的扩展策略来调整应用程序的不同部分。 例如，可能需要部署更多的用户界面（UI）计算实例，而无需增加后台计算实例的数量，或者相反。 可以提供不同级别的服务，例如基本和高级服务包。 可能需要比基本服务包的资源更积极地横向扩展高级服务包的计算资源。 此方法可帮助你满足 SLA。
其他缩放条件
考虑 UI 和后台计算实例通信中的队列长度。 将其用作自动缩放策略的条件。 此条件可以指示当前负载与后台任务的处理能力之间的不平衡或差异。 有一个稍微复杂但更好的属性可以作为基础来做缩放决策。 使用消息发送时间与消息处理完成时间之间的时间，称为 关键时间。 如果此关键时间值低于有意义的业务阈值，则无需缩放，即使队列长度较长也是如此。
例如，队列中可能有 50,000 条消息。 但是，最旧的消息的关键时间为 500 毫秒，该终结点正在处理与合作伙伴 Web 服务的集成，以便发送电子邮件。 业务利益干系人可能认为这种情况不够紧迫，无法证明横向扩展的成本是正当的。
另一方面，队列中可能有 500 条消息，关键时间为 500 毫秒。 但是，终结点是实时在线游戏中的关键路径的一部分，其中业务利益干系人定义了 100 毫秒或更少的响应时间。 在这种情况下，横向扩展是有意义的。
为了在自动缩放决策中使用关键时间，让库在传输和处理过程中自动将相关信息自动添加到消息标头中会很有帮助。 提供此功能的一个此类库是 NServiceBus。
如果将自动缩放策略基于度量业务流程的计数器，请确保充分了解这些类型的计数器的结果与实际计算容量要求之间的关系。 计数器的示例包括每小时下订单数或复杂事务的平均运行时数。 可能需要缩放多个组件或计算单元，以响应业务流程计数器中的更改。
若要防止系统尝试过度扩展，请考虑限制可自动添加的最大实例数。 此方法还避免了与运行数千个实例相关的成本。 大多数自动缩放机制都允许指定规则的最小和最大实例数。 此外，如果部署最大实例数，并且系统仍然重载，请考虑正常降级系统提供的功能。
请记住，自动缩放可能不是处理工作负荷突然突发的最合适机制。 设置和启动服务的新实例或向系统添加资源需要一段时间。 高峰需求可能会在这些额外资源可用时过去。 在这种情况下，最好限制服务。 有关详细信息，请参阅 “限制”模式。
相反，如果您需要能够在请求量快速波动时处理所有请求，请考虑使用激进的自动缩放策略，以更快地启动额外的实例。 确保成本不是主要的贡献因素。 您还可以使用预定策略，在预计负载到来之前启动足够数量的实例，以应对最大负载。
自动缩放机制应监视自动缩放过程并记录每个自动缩放事件的详细信息。 这些详细信息包括触发事件的内容、添加或删除的资源以及何时发生。 如果创建自定义自动缩放机制，请确保它包含此功能。 分析信息以帮助衡量自动缩放策略的有效性，并在必要时对其进行优化。 可以在短期内调整两个方面，因为使用模式会变得更加明显；从长远来看，随着业务的扩展或应用程序需求的变化，也可以进行调整。 如果应用程序达到为自动缩放定义的上限，该机制还可能会向作员发出警报，作员可以在必要时手动启动额外的资源。 在这些情况下，作员还可能负责在工作负载缓解后手动删除这些资源。
相关资源
实现自动缩放时，以下模式和指南也可能与方案相关：