常见的自动缩放模式
在本单元中，我们将了解自动缩放的模式。
自动缩放不是即时见效的解决方案。 简单地向系统添加资源或运行更多进程实例并不能保证提高系统性能。 设计自动缩放策略时，请注意以下几点：
建议
确定瓶颈：横向扩展并不是解决所有性能问题的万能方式。 例如，如果后端数据库是瓶颈，则添加更多 Web 服务器并没有帮助。 首先确定并解决系统中的瓶颈，然后针对该问题引发更多实例。 系统中有状态的部分最有可能引起瓶颈问题。
按可伸缩性要求分解工作负载：应用程序通常由多个工作负载组成，它们的缩放要求各不相同。 例如，应用程序可能有面向公众的网站和单独的管理网站。 公共站点可能会遇到流量突然激增的情况，而管理网站的负荷更小，且更具可预测性。
卸载资源密集型任务：需要大量 CPU 或 I/O 资源的任务应尽可能移动到后台作业。 卸载任务可最大程度地减少处理用户请求的前端上的负载。
使用内置自动缩放功能：如果应用程序具有可预测的常规工作负载，则可按计划横向扩展。 例如，在营业时间期间扩大。 否则，如果工作负载不可预测，请使用性能指标（如 CPU 或请求队列长度）来触发自动缩放。
考虑对关键工作负载进行主动自动缩放：对于关键工作负载，你要保持领先于需求。 最好在负载繁重的情况下快速添加新实例来处理其他流量，然后逐渐缩减。
针对横向缩减进行设计：请记住，使用弹性缩放时，应用程序会有横向缩减时期，此时实例会被移除。 应用程序必须妥善处理正在移除的实例。 以下是处理横向缩减的一些方法：
- 在关闭事件可用时，侦听它们并干净地关闭。
- 支持暂时性故障处理和重试。
- 对于长时间运行的任务，请考虑分解工作。
- 如果实例是在处理过程中移除的，请将工作项置于队列中，以便另一个实例可以接手工作。
通知
- 所有自动缩放失败都会记录到活动日志中。 然后，可以配置活动日志警报，每当出现自动缩放失败时，通过电子邮件、短信服务 (SMS) 或 Webhook 发出通知。
- 同样，所有成功的缩放操作也会发布到活动日志中。 然后可以配置活动日志警报，以便在自动缩放操作成功时，可通过电子邮件、短信或 Webhook 收到通知。 还可以配置电子邮件或 Webhook 通知，以通过自动缩放设置上的“通知”选项卡获取有关成功缩放操作的通知。
在 Azure 中缩放资源的常见模式
根据需求缩放
当客户需求增加时，可以在工作日开始时自动横向扩展服务实例的数量。 在工作日结束时，若应用程序使用率较低，自动横向缩减应用程序实例的数量，以在夜间将资源成本降至最低。
在工作日与周末以不同方式缩放
在晚上或周末，应用程序需求可能较低。 如果此负载在一段时间内保持一致，可以配置自动缩放规则来减少规模集中的服务实例数。 采取这种横向缩减操作可减少运行规模集所需的成本，因为只运行满足当前需求所需的实例数。
在节假日期间以不同方式缩放
如果某项服务在某个月或会计周期的某些部分使用量很大，可自动缩放服务实例的数量以满足其额外需求。 当有市场营销活动、促销或假日促销活动时，可在预期的客户需求之前自动缩放服务实例的数量。
基于自定义指标进行缩放
最后，最好仔细定义自动缩放规则。 例如，拒绝服务 (DoS) 攻击很可能会导致传入流量大规模涌入。 尝试处理由拒绝服务攻击造成的请求激增将会无果且成本高昂。 这些请求不是真实请求，应放弃，无需处理。 更好的解决方案是在这些请求达到服务前，在类似的攻击发生期间实现检测和对发生的请求进行筛选。
配置自动缩放规则后，监视应用程序在一段时间的性能。 如有必要，请使用这种监视的结果来调整系统缩放的模式。