自动缩放是动态分配资源来满足性能需求的过程。当工作负载增大时，应用程序可能会需要额外的资源来维持所需的性能级别并满足服务级别协议(SLA)。当需求降低并不再需要额外的资源时，可以取消资源分配以最大程度地降低成本。
自动缩放可以使用云托管环境的弹性的同时降低管理开销。不再需要操作员对系统性能持续监视，然后做出添加删除资源的决策。
应用程序伸缩主要有两种方式：
垂直缩放，也称为增加和减少，表示改变资源容量。例如，可将应用程序移动到更大的VM中。 垂直缩放在重新部署时通常会要求系统暂时不可用。因此，自动化垂直缩放并不常见。
水平缩放，也称为扩大和缩小，表示添加或删除资源实例。在预配新资源时，应用程序无需中断并可持续运行。当预配过程完成时，额外资源已经部署完成。如果性能需求降低，额外的资源可完全关闭并解除分配。许多基于云系统（包括微软Azure）支持自动水平缩放。本文的余下内容重点介绍水平缩放。
备注
自动伸缩主要适用于资源计算。虽然可以对数据库或消息队列进行水平伸缩，但这通常会关系到数据分区（https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning），而它很难自动化。
概述
自动伸缩策略通常包括以下部分：
应用程序、服务和基础结构级别的检测和监视的系统。这些系统可捕获响应时间、队列长度、CPU利用率和内存使用量等关键指标。
根据预定义的阈值或计划来评估这些指标并决定是否缩放。
系统伸缩组件。
测试、监视并优化自动伸缩策略，以确保它能够按预期工作。
Azure内置了用于处理常见方案的自动缩放机制。如果某特定服务或技术没有内置自动缩放，或者对自动缩放有特殊需求，则可考虑自定义实现。自定义实现会收集操作和系统指标信息，分析这些信息然后相应地缩放资源。
配置Azure解决方案的自动缩放机制
Azure为大多数计算选项内置了自动缩放功能。
虚拟机使用VM集群支持的自动缩放，这是分组形式来管理Azure虚拟机集群的方法。请参阅如何使用自动缩放和虚拟机集群。（https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-overview）
ServiceFabric也通过VM集群来实现自动缩放。ServiceFabric集群中的每个节点类型会配置各自的VM集群。这样每个节点类型都可以独立地扩大和缩小。请参阅使用自动缩放规则来扩大和缩小ServiceFabric集群（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-scale-up-down）。
Azure应用服务内置了自动伸缩机制。自动伸缩应用于应用服务中的所有应用。请参阅手动或自动缩放实例。（https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-how-to-scale?toc=%2fazure%2fapp-service-web%2ftoc.json#scaling-based-on-a-pre-set-metric）
Azure云服务在角色级别内置了自动缩放功能。请参阅如何在门户为云服务配置自动缩放（https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-how-to-scale-portal）。这些计算选项使用AzureMonitor自动缩放来提供一组通用的自动缩放功能。
AzureFunctions与之前的计算选项不同，因为无需配置任何自动缩放规则。相反，当代码运行时，AzureFunctions会自动分配计算能力，根据需要横向扩展进行负载。有关详细信息，请参阅为AzureFunctions选择正确的托管计划。（https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale）
自定义的自动缩放解决方案有时非常有用。例如，可使用Azure诊断并基于应用程序指标，以及自定义代码来监视并导出应用程序指标。然后，可根据这些指标来自定义规则，并使用资源管理器提供的REST-API来触发自动缩放。但是，自定义解决方案并不容易把控，只应在上述方法都无法满足要求时才考虑。如果平台内置自动缩放功能可以符合要求，就应该使用。否则，请仔细考虑是否真的需要一种更复杂的伸缩机制。其他相关示例可能还包括更高粒度的控制、用于检测缩放触发事件的其他方式、跨订阅伸缩机制和其他资源类型的伸缩机制。
使用AzureMonitor自动缩放
AzureMonitor自动缩放机制为VM集群、Azure应用服务和Azure云服务提供了一套通用的自动伸缩功能。可按计划、根据运行时指标（如CPU或内存使用率）来执行缩放。示例:
在工作日，扩大到10个实例，在周六和周日则缩小为4个实例。
如果平均CPU使用率在70%以上，增加一个实例；如果CPU使用率低于50%，则减少一个实例。
如果队列中消息数量超过特定阈值，增加一个实例。
有关内置指标列表，请参阅AzureMonitor自动缩放常用指标（https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-autoscale-common-metrics）。还可通过使用ApplicationInsights来实现自定义指标。
可通过使用PowerShell、AzureCLI、Azure资源管理器模板或Azure门户来配置自动缩放。要实现更细化的控制，可以使用Azure资源管理器的REST-API。Azure监视服务管理库和MicrosoftInsights库（预览版https://www.nuget.org/packages/Microsoft.Azure.Insights/）是SDK，用户可以用它从不同的资源收集指标并使用REST-API执行自动缩放。对于不支持Azure资源管理器的资源，或使用Azure云服务时，可以使用服务管理REST-API进行自动缩放。在其他所有情况下，请使用Azure资源管理器。
使用Azure自动缩放机制时，应考虑到以下几点：
考虑是否能精确地预测应用程序负载，使用计划的自动缩放来添加和删除实例以满足需求的预期高峰。如果不可行，可根据运行时指标使用被动的自动缩放机制，以应对无法预测的需求变化。在通常情况下，可对这些方法进行组合。例如，如果知道应用程序何时最忙，则可创建一个策略，根据时间计划来添加资源。这有助于确保容量在需要时使用，并且不会在启动新实例时发生延迟。对于每个计划的规则，需要定义在该期间允许被动自动缩放的指标，以确保应用程序能够处理无法预测的需求高峰。
通常很难了解指标与容量需求之间的关系，尤其是在部署应用程序后。在一开始多预配一些附加容量，监视并调整自动缩放规则，使容量更接近实际负载的需要。
配置自动缩放规则，然后监视应用程序在一段时间内的性能。如果需要，可使用这种监视的结果来调整系统的缩放方式。但是，自动缩放不是即时生效的。它需要过一段时间来对指标（例如平均CPU利用率超过或低于指定阈值）做出反应。
基于可测量的触发器属性（例如CPU使用量或队列长度）的检测机制，自动缩放规则使用一段时间内的聚合值而不是瞬时值来触发自动缩放操作。默认情况下，聚合是值的平均值。这可以防止系统反应太快，或导致快速震荡。这还可以使自动启动的新实例顺利进入运行模式，避免当新实例正启动时，又发生其他自动缩放操作。对于Azure云服务和Azure虚拟机来说，聚合的默认期限为45分钟，指标需要经过这段时间后才会为响应需求高峰而触发自动缩放。可使用SDK来更改聚合期限，但是，低于25分钟可能会导致不可预测的结果（有关详细信息，请参阅（使用Azure监视服务管理库基于CPU百分比实现自动缩放的云服务http://rickrainey.com/2013/12/15/auto-scaling-cloud-services-on-cpu-percentage-with-the-windows-azure-monitoring-services-management-library/）。对于Web应用，平均期限要短得多，以便在平均触发测量值更改约五分钟后提供新实例。
如果使用SDK而不是门户配置的自动缩放，则可以指定更详细的计划，在执行计划期间，规则处于活动状态。还可以创建自己的度量值，并将其与自动缩放规则中现有的度量值一起使用，或单独使用。例如，建议使用备选的计数器，如每秒请求数或平均内存可用性，或用于测量特定业务流程的自定义计数器。
自动缩放ServiceFabric时，由于群集中的节点类型由后端的 VM 规模集构成，因此需要为每个节点类型设置自动缩放规则。 在设置自动缩放之前请考虑必须具有的节点数。 对于主节点类型所必须具有的最小节点数受所选择的可靠性级别影响。 有关详细信息，请参阅使用自动缩放规则扩大或缩小ServiceFabric群集。（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-scale-up-down）
可以使用门户网站将SQL数据库实例和队列等资源链接到云服务实例。这样便可以更轻松地访问每个资源的手动和自动缩放配置选项。有关详细信息，请参阅如何：将资源链接到云服务（https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-how-to-manage-portal）。配置多个策略和规则时，它们可能会相互冲突。自动伸缩机制使用以下冲突解决方案来确保始终有足够的实例在运行：
向外扩展始终优先于向内收缩操作。
当向外扩展操作发生冲突时，使实例数增幅最大的规则优先。
当向内收缩操作发生冲突时，使实例数降幅最小的规则优先。
在应用服务环境中，可使用任何工作任务池或前端指标来定义自动缩放规则。有关详细信息，请参阅自动缩放和应用服务环境。（https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-environment-auto-scale）
应用程序设计注意事项
自动缩放不是即时见效的解决方案。仅仅将资源添加到系统或运行进程的更多实例并不能保证系统性能的提高。 在设计自动缩放策略时，需要以下几点：
系统必须设计为可水平缩放。不要在实例关联性上做假设；不要设计为始终需要代码在特定进程实例中运行的解决方案。水平伸缩云服务或网站时，不要假设一系列来自同一源的请求始终被路由到同一实例。将服务设计为无状态的，以免一系列来自应用程序的请求对某一服务实例产生耦合。当从队列读取并处理消息时，不要假设哪个服务实例会处理哪个特定消息。自动缩放可能会在队列长度增大时启动其他服务实例。使用者竞争模式说明了如何解决这种情况。（https://docs.microsoft.com/en-us/azure/architecture/patterns/competing-consumers）
如果解决方案包含了长时间运行的任务，将此任务设计为可伸缩的。如果不谨慎，这种任务在系统向内缩放时可能会导致进程实例完全关闭；如果进程被强行终止，可能会丢失数据。理想的情况是，对长时间运行的任务重构并分解处理，使其以较小且不连续的块执行。管道和筛选器模式提供了有关如何实现此目的的示例。（https://docs.microsoft.com/en-us/azure/architecture/patterns/pipes-and-filters）
或者可以实施检查点机制，定期记录任务状态信息，并将状态保存在运行任务的任何进程实例都可以访问的持久化存储中。如果进程关闭，它所执行的工作可被另一个实例从最后一个检查点的地方继续执行。
当后台任务在独立的计算实例（例如云服务上托管应用程序的工作角色）上运行时，可能需要使用不同的缩放策略来对应用程序的不同部分进行缩放。例如，可能需要部署更多用户界面(UI)的计算实例而不需要增加后台计算实例数，或相反。如果提供不同级别的服务（例如基本和高级服务包），可能需要使用比基本服务包更主动的高级服务包的计算资源来符合SLA。考虑使用UI和后台计算实例通信的队列长度作为自动缩放策略的条件。 以最好地反映当前负载与后台任务处理的不平衡或差异。
如果自动缩放策略基于度量业务进程（例如每小时订单数或复杂事务的平均执行时间）的计数器，请确保完全了解这些计数器类型的结果与实际计算需求的关系。可能需要缩放多个组件或计算单位来应对业务进程计数器的变化。
若要防止系统过度地向外扩展并避免由运行数千个实例而产生的成本，考虑限制自动添加实例数的上限。大多数自动缩放机制允许指定实例数的上限和下限。此外，如果部署的实例数已达到上限而系统仍过载，考虑适当地减少系统提供的功能。
请记住，自动缩放可能不是用于处理工作负荷突发高峰的有效方案。设置并启动新服务实例或将资源添加到系统都需要时间，而当这些附加资源变得可用时，高峰需求可能已经过去。在这种情况下，限制服务可能更适合。有关详细信息，请参阅限流模式。（https://docs.microsoft.com/en-us/azure/architecture/patterns/throttling）
相比之下，如果希望在事务量快速波动时有足够容量处理所有请求，并且成本不是主要考虑因素，请考虑使用积极的自动缩放策略来更快速地启动附加实例。还可使用计划策略在最大负载来临前预先启动足够的实例。自动缩放机制应该监视自动缩放过程，并记录每个自动缩放事件的详细信息（触发的事件、添加或删除了哪些资源，以及时间）。在创建自定义缩放机制时，请确保它包含了这个功能。分析这些信息以帮助度量自动缩放策略的有效性，并根据需要进行优化。你可以在短期或长期业务拓展以及应用程序的要求变化时来进行优化。如果应用程序达到自定义的自动缩放上限，这种机制可以提醒操作人员，让操作人员手动启动其他资源（如果必要）。注意，在这种情况下，操作人员可能还要负责在工作负荷减轻后手动删除这些资源。
相关模式和指南
实施自动缩放时，以下模式和指南也可能是相关的：
限制模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/throttling）。该模式描述了当需求增大而对资源产生极大负载时，应用程序如何继续工作并满足SLA。限制可与自动缩放配合使用，以避免系统向外扩展时失控。
消费者竞争模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/competing-consumers）。此模式描述如何部署服务实例池，以处理来自任何应用程序实例的消息。自动缩放可用于启动和停止服务实例，以符合预期的工作负荷。此模式可让系统同时处理多个消息，以优化吞吐量、提高伸缩性和可用性，以及平衡工作负荷。
监视和诊断（https://docs.microsoft.com/en-us/azure/architecture/best-practices/monitoring）。检测和遥测用于收集信息，来完成自动缩放过程。
自动缩放可以使用云托管环境的弹性的同时降低管理开销。不再需要操作员对系统性能持续监视，然后做出添加删除资源的决策。
应用程序伸缩主要有两种方式：
垂直缩放，也称为增加和减少，表示改变资源容量。例如，可将应用程序移动到更大的VM中。 垂直缩放在重新部署时通常会要求系统暂时不可用。因此，自动化垂直缩放并不常见。
水平缩放，也称为扩大和缩小，表示添加或删除资源实例。在预配新资源时，应用程序无需中断并可持续运行。当预配过程完成时，额外资源已经部署完成。如果性能需求降低，额外的资源可完全关闭并解除分配。许多基于云系统（包括微软Azure）支持自动水平缩放。本文的余下内容重点介绍水平缩放。
备注
自动伸缩主要适用于资源计算。虽然可以对数据库或消息队列进行水平伸缩，但这通常会关系到数据分区（https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning），而它很难自动化。
概述
自动伸缩策略通常包括以下部分：
应用程序、服务和基础结构级别的检测和监视的系统。这些系统可捕获响应时间、队列长度、CPU利用率和内存使用量等关键指标。
根据预定义的阈值或计划来评估这些指标并决定是否缩放。
系统伸缩组件。
测试、监视并优化自动伸缩策略，以确保它能够按预期工作。
Azure内置了用于处理常见方案的自动缩放机制。如果某特定服务或技术没有内置自动缩放，或者对自动缩放有特殊需求，则可考虑自定义实现。自定义实现会收集操作和系统指标信息，分析这些信息然后相应地缩放资源。
配置Azure解决方案的自动缩放机制
Azure为大多数计算选项内置了自动缩放功能。
虚拟机使用VM集群支持的自动缩放，这是分组形式来管理Azure虚拟机集群的方法。请参阅如何使用自动缩放和虚拟机集群。（https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-overview）
ServiceFabric也通过VM集群来实现自动缩放。ServiceFabric集群中的每个节点类型会配置各自的VM集群。这样每个节点类型都可以独立地扩大和缩小。请参阅使用自动缩放规则来扩大和缩小ServiceFabric集群（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-scale-up-down）。
Azure应用服务内置了自动伸缩机制。自动伸缩应用于应用服务中的所有应用。请参阅手动或自动缩放实例。（https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-how-to-scale?toc=%2fazure%2fapp-service-web%2ftoc.json#scaling-based-on-a-pre-set-metric）
Azure云服务在角色级别内置了自动缩放功能。请参阅如何在门户为云服务配置自动缩放（https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-how-to-scale-portal）。这些计算选项使用AzureMonitor自动缩放来提供一组通用的自动缩放功能。
AzureFunctions与之前的计算选项不同，因为无需配置任何自动缩放规则。相反，当代码运行时，AzureFunctions会自动分配计算能力，根据需要横向扩展进行负载。有关详细信息，请参阅为AzureFunctions选择正确的托管计划。（https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale）
自定义的自动缩放解决方案有时非常有用。例如，可使用Azure诊断并基于应用程序指标，以及自定义代码来监视并导出应用程序指标。然后，可根据这些指标来自定义规则，并使用资源管理器提供的REST-API来触发自动缩放。但是，自定义解决方案并不容易把控，只应在上述方法都无法满足要求时才考虑。如果平台内置自动缩放功能可以符合要求，就应该使用。否则，请仔细考虑是否真的需要一种更复杂的伸缩机制。其他相关示例可能还包括更高粒度的控制、用于检测缩放触发事件的其他方式、跨订阅伸缩机制和其他资源类型的伸缩机制。
使用AzureMonitor自动缩放
AzureMonitor自动缩放机制为VM集群、Azure应用服务和Azure云服务提供了一套通用的自动伸缩功能。可按计划、根据运行时指标（如CPU或内存使用率）来执行缩放。示例:
在工作日，扩大到10个实例，在周六和周日则缩小为4个实例。
如果平均CPU使用率在70%以上，增加一个实例；如果CPU使用率低于50%，则减少一个实例。
如果队列中消息数量超过特定阈值，增加一个实例。
有关内置指标列表，请参阅AzureMonitor自动缩放常用指标（https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-autoscale-common-metrics）。还可通过使用ApplicationInsights来实现自定义指标。
可通过使用PowerShell、AzureCLI、Azure资源管理器模板或Azure门户来配置自动缩放。要实现更细化的控制，可以使用Azure资源管理器的REST-API。Azure监视服务管理库和MicrosoftInsights库（预览版https://www.nuget.org/packages/Microsoft.Azure.Insights/）是SDK，用户可以用它从不同的资源收集指标并使用REST-API执行自动缩放。对于不支持Azure资源管理器的资源，或使用Azure云服务时，可以使用服务管理REST-API进行自动缩放。在其他所有情况下，请使用Azure资源管理器。
使用Azure自动缩放机制时，应考虑到以下几点：
考虑是否能精确地预测应用程序负载，使用计划的自动缩放来添加和删除实例以满足需求的预期高峰。如果不可行，可根据运行时指标使用被动的自动缩放机制，以应对无法预测的需求变化。在通常情况下，可对这些方法进行组合。例如，如果知道应用程序何时最忙，则可创建一个策略，根据时间计划来添加资源。这有助于确保容量在需要时使用，并且不会在启动新实例时发生延迟。对于每个计划的规则，需要定义在该期间允许被动自动缩放的指标，以确保应用程序能够处理无法预测的需求高峰。
通常很难了解指标与容量需求之间的关系，尤其是在部署应用程序后。在一开始多预配一些附加容量，监视并调整自动缩放规则，使容量更接近实际负载的需要。
配置自动缩放规则，然后监视应用程序在一段时间内的性能。如果需要，可使用这种监视的结果来调整系统的缩放方式。但是，自动缩放不是即时生效的。它需要过一段时间来对指标（例如平均CPU利用率超过或低于指定阈值）做出反应。
基于可测量的触发器属性（例如CPU使用量或队列长度）的检测机制，自动缩放规则使用一段时间内的聚合值而不是瞬时值来触发自动缩放操作。默认情况下，聚合是值的平均值。这可以防止系统反应太快，或导致快速震荡。这还可以使自动启动的新实例顺利进入运行模式，避免当新实例正启动时，又发生其他自动缩放操作。对于Azure云服务和Azure虚拟机来说，聚合的默认期限为45分钟，指标需要经过这段时间后才会为响应需求高峰而触发自动缩放。可使用SDK来更改聚合期限，但是，低于25分钟可能会导致不可预测的结果（有关详细信息，请参阅（使用Azure监视服务管理库基于CPU百分比实现自动缩放的云服务http://rickrainey.com/2013/12/15/auto-scaling-cloud-services-on-cpu-percentage-with-the-windows-azure-monitoring-services-management-library/）。对于Web应用，平均期限要短得多，以便在平均触发测量值更改约五分钟后提供新实例。
如果使用SDK而不是门户配置的自动缩放，则可以指定更详细的计划，在执行计划期间，规则处于活动状态。还可以创建自己的度量值，并将其与自动缩放规则中现有的度量值一起使用，或单独使用。例如，建议使用备选的计数器，如每秒请求数或平均内存可用性，或用于测量特定业务流程的自定义计数器。
自动缩放ServiceFabric时，由于群集中的节点类型由后端的 VM 规模集构成，因此需要为每个节点类型设置自动缩放规则。 在设置自动缩放之前请考虑必须具有的节点数。 对于主节点类型所必须具有的最小节点数受所选择的可靠性级别影响。 有关详细信息，请参阅使用自动缩放规则扩大或缩小ServiceFabric群集。（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-scale-up-down）
可以使用门户网站将SQL数据库实例和队列等资源链接到云服务实例。这样便可以更轻松地访问每个资源的手动和自动缩放配置选项。有关详细信息，请参阅如何：将资源链接到云服务（https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-how-to-manage-portal）。配置多个策略和规则时，它们可能会相互冲突。自动伸缩机制使用以下冲突解决方案来确保始终有足够的实例在运行：
向外扩展始终优先于向内收缩操作。
当向外扩展操作发生冲突时，使实例数增幅最大的规则优先。
当向内收缩操作发生冲突时，使实例数降幅最小的规则优先。
在应用服务环境中，可使用任何工作任务池或前端指标来定义自动缩放规则。有关详细信息，请参阅自动缩放和应用服务环境。（https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-environment-auto-scale）
应用程序设计注意事项
自动缩放不是即时见效的解决方案。仅仅将资源添加到系统或运行进程的更多实例并不能保证系统性能的提高。 在设计自动缩放策略时，需要以下几点：
系统必须设计为可水平缩放。不要在实例关联性上做假设；不要设计为始终需要代码在特定进程实例中运行的解决方案。水平伸缩云服务或网站时，不要假设一系列来自同一源的请求始终被路由到同一实例。将服务设计为无状态的，以免一系列来自应用程序的请求对某一服务实例产生耦合。当从队列读取并处理消息时，不要假设哪个服务实例会处理哪个特定消息。自动缩放可能会在队列长度增大时启动其他服务实例。使用者竞争模式说明了如何解决这种情况。（https://docs.microsoft.com/en-us/azure/architecture/patterns/competing-consumers）
如果解决方案包含了长时间运行的任务，将此任务设计为可伸缩的。如果不谨慎，这种任务在系统向内缩放时可能会导致进程实例完全关闭；如果进程被强行终止，可能会丢失数据。理想的情况是，对长时间运行的任务重构并分解处理，使其以较小且不连续的块执行。管道和筛选器模式提供了有关如何实现此目的的示例。（https://docs.microsoft.com/en-us/azure/architecture/patterns/pipes-and-filters）
或者可以实施检查点机制，定期记录任务状态信息，并将状态保存在运行任务的任何进程实例都可以访问的持久化存储中。如果进程关闭，它所执行的工作可被另一个实例从最后一个检查点的地方继续执行。
当后台任务在独立的计算实例（例如云服务上托管应用程序的工作角色）上运行时，可能需要使用不同的缩放策略来对应用程序的不同部分进行缩放。例如，可能需要部署更多用户界面(UI)的计算实例而不需要增加后台计算实例数，或相反。如果提供不同级别的服务（例如基本和高级服务包），可能需要使用比基本服务包更主动的高级服务包的计算资源来符合SLA。考虑使用UI和后台计算实例通信的队列长度作为自动缩放策略的条件。 以最好地反映当前负载与后台任务处理的不平衡或差异。
如果自动缩放策略基于度量业务进程（例如每小时订单数或复杂事务的平均执行时间）的计数器，请确保完全了解这些计数器类型的结果与实际计算需求的关系。可能需要缩放多个组件或计算单位来应对业务进程计数器的变化。
若要防止系统过度地向外扩展并避免由运行数千个实例而产生的成本，考虑限制自动添加实例数的上限。大多数自动缩放机制允许指定实例数的上限和下限。此外，如果部署的实例数已达到上限而系统仍过载，考虑适当地减少系统提供的功能。
请记住，自动缩放可能不是用于处理工作负荷突发高峰的有效方案。设置并启动新服务实例或将资源添加到系统都需要时间，而当这些附加资源变得可用时，高峰需求可能已经过去。在这种情况下，限制服务可能更适合。有关详细信息，请参阅限流模式。（https://docs.microsoft.com/en-us/azure/architecture/patterns/throttling）
相比之下，如果希望在事务量快速波动时有足够容量处理所有请求，并且成本不是主要考虑因素，请考虑使用积极的自动缩放策略来更快速地启动附加实例。还可使用计划策略在最大负载来临前预先启动足够的实例。自动缩放机制应该监视自动缩放过程，并记录每个自动缩放事件的详细信息（触发的事件、添加或删除了哪些资源，以及时间）。在创建自定义缩放机制时，请确保它包含了这个功能。分析这些信息以帮助度量自动缩放策略的有效性，并根据需要进行优化。你可以在短期或长期业务拓展以及应用程序的要求变化时来进行优化。如果应用程序达到自定义的自动缩放上限，这种机制可以提醒操作人员，让操作人员手动启动其他资源（如果必要）。注意，在这种情况下，操作人员可能还要负责在工作负荷减轻后手动删除这些资源。
相关模式和指南
实施自动缩放时，以下模式和指南也可能是相关的：
限制模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/throttling）。该模式描述了当需求增大而对资源产生极大负载时，应用程序如何继续工作并满足SLA。限制可与自动缩放配合使用，以避免系统向外扩展时失控。
消费者竞争模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/competing-consumers）。此模式描述如何部署服务实例池，以处理来自任何应用程序实例的消息。自动缩放可用于启动和停止服务实例，以符合预期的工作负荷。此模式可让系统同时处理多个消息，以优化吞吐量、提高伸缩性和可用性，以及平衡工作负荷。
监视和诊断（https://docs.microsoft.com/en-us/azure/architecture/best-practices/monitoring）。检测和遥测用于收集信息，来完成自动缩放过程。