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

有关设计可靠缩放策略的建议

  • 项目

适用于此 Azure Well-Architected 框架可靠性清单建议：

RE：06 在应用程序、数据和基础结构级别实施及时可靠的缩放策略。

相关指南：数据分区

本指南介绍设计可靠缩放策略的建议。

定义

术语 定义
垂直缩放 一种将计算容量添加到现有资源的缩放方法。
水平扩展 一种缩放方法，用于添加给定类型的资源实例。
自动缩放 一种缩放方法，在满足一组条件时自动添加或删除资源。

注意

缩放操作可以是静态 (定期计划的每日缩放以适应正常负载模式) 、自动 (自动化过程以响应) 满足的条件，或手动 (操作员执行一次性缩放操作以响应意外的负载更改) 。 垂直缩放和水平缩放都可以通过以下任一方法执行。 但是，自动垂直缩放需要额外的自定义自动化开发，并可能导致停机，具体取决于要缩放的资源。

关键设计策略

若要为工作负载设计可靠的缩放策略，请重点确定导致缩放操作的每个工作负载的用户和系统流的负载模式。 下面是不同负载模式的示例：

  • 静态：到美国时间晚上 11 点，活动用户数低于 100，应用服务器的 CPU 使用率在所有节点上下降 90%。

  • 动态、定期且可预测：每个星期一早上，跨多个区域的 1000 名员工登录到 ERP 系统。

  • 动态、不规则且可预测：产品发布在当月的第一天进行，并且有以前发布的有关在这些情况下流量如何增加的历史数据。

  • 动态、不规则和不可预知：大规模事件会导致产品需求激增。 例如，制造和销售除湿机的公司可能会经历飓风或其他洪水事件后交通突然激增，而受影响地区的人们需要干涸家中的房间。

确定这些类型的负载模式后，可以：

  • 确定与每种模式关联的负载更改如何影响基础结构。

  • 生成自动化以可靠地解决缩放问题。

对于前面的示例，缩放策略可以是：

  • 静态：计算节点的计划规模为 2 (2) ，时间在 11 PM 到 6 AM EST 之间。

  • 动态、常规且可预测：在第一个区域开始工作之前，你已计划将计算节点横向扩展到正常的每日容量。

  • 动态、不规则且可预测：在产品发布当天上午定义计算和数据库实例的一次性计划纵向扩展，并在一周后缩减。

  • 动态、不规则和不可预知：定义了自动缩放阈值来解释计划外流量高峰。

设计缩放自动化时，请务必考虑以下问题：

  • 工作负荷的所有组件都应是缩放实现的候选项。 在大多数情况下，Microsoft Entra ID 等全球服务会自动且透明地缩放你和你的客户。 请务必了解网络入口和出口控制器的缩放功能以及负载均衡解决方案。

  • 无法横向扩展的组件。例如，大型关系数据库未启用分片，并且无法重构而不会产生重大影响。 记录云提供商发布的资源限制并密切监视这些资源。 在迁移到可缩放服务的未来规划中包括这些特定资源。

  • 执行缩放操作所需的时间，以便正确安排操作在额外负载到达基础结构之前发生。 例如，如果 API 管理 等组件需要 45 分钟才能缩放，则将缩放阈值调整为 65% 而不是 90% 可能有助于提前缩放，并为预期的负载增加做好准备。

  • 流组件按缩放操作顺序的关系。 首先缩放上游组件，确保不会无意中重载下游组件。

  • 任何可能被缩放操作中断的有状态应用程序元素，以及实现的任何会话相关性 (或会话粘性) 。 粘性可能会限制缩放能力，并引入单一故障点。

  • 潜在的瓶颈。 横向扩展并不能解决每个性能问题。 例如，如果后端数据库是瓶颈，则添加更多 Web 服务器无济于事。 在添加更多实例之前，先确定并解决系统中的瓶颈。 系统中有状态的部分最有可能引起瓶颈问题。

遵循 部署标记 设计模式有助于进行整体基础结构管理。 将缩放设计基于缩放单元的邮票也很有用。 它可以帮助你严格控制跨多个工作负载和工作负载子集的缩放操作。 可以向部署标记应用一组有限的缩放定义，然后根据需要跨标记镜像，而不是管理许多不同资源的缩放计划和自动缩放阈值。

权衡：纵向扩展会产生成本影响，因此请优化策略以尽快缩减，以帮助控制成本。 确保用于纵向扩展的自动化也具有纵向缩减的触发器。

Azure 简化

自动缩放功能 在许多 Azure 服务中都可用。 它使你可以轻松地配置条件以自动水平缩放实例。 某些服务具有有限或没有内置功能可自动缩减，因此请务必记录这些情况并定义处理缩减的过程。

许多 Azure 服务提供的 API 可用于使用 Azure 自动化 设计自定义自动缩放操作，例如自动缩放Azure IoT 中心中的代码示例。 可以使用 KEDA 等工具进行事件驱动的自动缩放，这在 Azure Kubernetes 服务 和 Azure 容器应用中可用。

Azure Monitor 自动缩放为 Azure 虚拟机规模集、Azure 应用服务、Azure Spring Apps 等提供了一组常见的自动缩放功能。 可以按计划或基于运行时指标（例如 CPU 或内存使用率）执行缩放。 有关最佳做法，请参阅 Azure Monitor 指南 。

权衡

自动缩放注意事项

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

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

如果解决方案实施长时间运行的任务，请将此任务设计为同时支持向外和向内缩放。 如果不小心，此类任务可能会阻止进程实例在系统横向扩展时干净地关闭。 或者，如果进程强行终止，它可能会丢失数据。 理想的情况是，重构长时间运行的任务并分解处理，使其以较小且不连续的块执行。 管道和筛选器模式提供了如何实现此解决方案的示例。

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

当后台任务在单独的计算实例上运行时（例如，在云服务托管的应用程序的辅助角色中），可能需要使用不同的缩放策略来缩放应用程序的不同部分。 例如，可能需要在不增加后台计算实例数的情况下，将额外的用户界面 (UI) 计算实例部署，反之亦然。 如果提供不同级别的服务，例如基本和高级服务包，则可能需要比基本服务包更积极地横向扩展高级服务包的计算资源，以满足服务级别协议 (SLA) 。

考虑 UI 和后台计算实例通信中的队列长度。 将其用作自动缩放策略的条件。 此问题可能表明当前负载与后台任务的处理能力之间存在不平衡或差异。 基于缩放决策的一个稍微复杂一些但更好的属性是使用消息发送到处理完成之间的时间。 此间隔称为关键时间。 如果此关键时间值低于有意义的业务阈值，则无需缩放，即使队列长度较长。

例如，队列中可能有 50,000 条消息。 但最旧消息的关键时间是 500 毫秒，终结点正在处理与第三方 Web 服务集成以发送电子邮件。 业务利益干系人可能会认为，这是一段无法证明花费额外资金进行缩放的合理性。

另一方面，队列中可能有 500 条消息，其关键时间为 500 毫秒，但在一些实时在线游戏中，终结点是关键路径的一部分，其中业务利益干系人将响应时间定义为 100 毫秒或更少。 在这种情况下，缩放是有意义的。

若要在自动缩放决策中使用关键时间，最好让库在发送和处理消息时自动将相关信息添加到消息的标头中。 提供此功能的一个库是 NServiceBus。

如果自动缩放策略基于度量业务流程的计数器（例如每小时下达的订单数或复杂事务的平均运行时间），请确保完全了解这些类型计数器的结果与实际计算容量要求之间的关系。 可能需要缩放多个组件或计算单元，以响应业务流程计数器中的更改。

若要防止系统尝试过度横向扩展，并避免与运行数千个实例相关的成本，请考虑限制自动添加的最大实例数。 大多数自动缩放机制允许指定规则的最小和最大实例数。 此外，如果部署的实例数已达到上限而系统仍然过载，请考虑适当地降低系统提供的功能。

请记住，自动缩放可能不是处理工作负荷中突然突发的最合适机制。 预配和启动服务的新实例或将资源添加到系统需要一些时间，而高峰需求可能会超过这些额外资源可用的时间。 在这种情况下，限制服务可能更好。 有关详细信息，请参阅限制模式。

相反，如果需要容量在卷快速波动且成本不是主要因素时处理所有请求，请考虑使用主动的自动缩放策略，以更快地启动更多实例。 还可以使用计划的策略在最大负载来临前预先启动足量的实例。

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

示例

请参阅 AKS 基线参考体系结构 缩放指南。

可靠性清单

请参阅完整的建议集。

可靠性清单