你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
设计可靠缩放策略的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：06 | 在应用程序、数据和基础结构级别实施及时、可靠的缩放策略。 |
|---|
相关指南：数据分区
本指南介绍设计可靠缩放策略的建议。
定义
| 术语 | 定义 |
|---|---|
| 垂直缩放 | 向现有资源添加计算容量的缩放方法。 |
| 水平缩放 | 一种缩放方法，用于添加给定类型的资源实例。 |
| 自动缩放 | 满足一组条件时自动添加或删除资源的缩放方法。 |
注意
缩放操作可以是静态的（定期计划每日缩放以适应正常负载模式）、自动（响应满足条件的自动化过程）或手动操作（操作员执行一次性缩放操作来响应意外的负载更改）。 可以通过上述任何方法执行垂直和水平缩放。 但是，自动垂直缩放需要额外的自定义自动化开发，并可能导致停机，具体取决于正在缩放的资源。
关键设计策略
根据负载模式进行设计
若要为工作负荷设计可靠的缩放策略，请专注于确定导致缩放操作的每个工作负荷的用户和系统流的负载模式。 下面是不同负载模式的示例：
静态：每天晚上 11 点到 EST，活动用户数低于 100，应用服务器的 CPU 使用率在所有节点上下降 90%。
动态、常规和可预测的：每周一早上，跨多个区域的 1000 名员工登录到 ERP 系统。
动态、不规则和可预测的：产品发布发生在当月的第一天，以及以前发布的历史数据，说明这些情况量如何增加。
动态、不规则和不可预知：大规模事件会导致产品需求激增。 例如，制造和销售除湿剂的公司在飓风或其他洪水事件后，在受灾地区的人需要在其家中干燥房间时，交通突然激增。
确定这些类型的负载模式后，可以：
确定与每个模式关联的负载更改如何影响基础结构。
生成自动化以可靠地解决缩放问题。
对于前面的示例，缩放策略可以是：
静态：计算节点的计划规模在下午 11 点到上午 6 点之间达到最小计数（2）。
动态、常规和可预测的：在第一个区域开始工作之前，计划将计算节点横向扩展到正常的每日容量。
动态、不规则和可预测的：在产品发布当天上午定义计算和数据库实例的一次性纵向扩展，并在一周后缩减。
动态、不规则和不可预知：定义了自动缩放阈值，以考虑计划外流量高峰。
自动执行缩放策略
设计缩放自动化时，请务必考虑这些问题：
工作负荷的所有组件都应适合用于缩放实现。 在大多数情况下，Microsoft Entra ID 等全局服务会自动且透明地缩放给你和你的客户。 请务必了解网络入口和出口控制器以及负载均衡解决方案的缩放功能。
无法横向扩展的那些组件。例如，未启用分片且无法重构的大型关系数据库，而不会产生重大影响。 记录云提供商发布的资源限制，并密切监视这些资源。 在将来的规划中包括这些特定资源，以便迁移到可缩放的服务。
执行缩放操作所需的时间，以便在额外负载达到基础结构之前正确计划操作。 例如，如果API 管理等组件需要 45 分钟进行缩放，将缩放阈值调整为 65%，而不是 90% 可能会帮助你提前缩放，并为预期的负载增加做好准备。
按缩放操作顺序排列流的组件关系。 确保不无意中通过先缩放上游组件来重载下游组件。
任何可能被缩放操作中断的有状态应用程序元素，以及实现的任何会话相关性（或会话粘性）。 粘性可以限制缩放能力，并引入单一故障点。
潜在的瓶颈。 横向扩展无法解决每个性能问题。 例如，如果后端数据库是瓶颈，则无法添加更多 Web 服务器。 先识别并解决系统中的瓶颈，然后再添加更多实例。 系统中有状态的部分最有可能引起瓶颈问题。
遵循 部署模具 设计模式有助于实现整体基础结构管理。 将缩放设计基于印章作为缩放单位也很有用。 它可帮助你严格控制跨多个工作负荷和工作负荷子集的缩放操作。 无需管理许多不同资源的缩放计划和自动缩放阈值，可以将有限的缩放定义集应用于部署标记，然后根据需要跨标记镜像。
权衡：纵向扩展会产生成本影响，因此请优化策略以尽快缩减，以帮助控制成本。 确保用于纵向扩展的自动化也具有纵向缩减的触发器。
Azure 便利化
许多 Azure 服务中都提供了自动缩放功能。 它允许你轻松配置条件以水平缩放实例。 某些服务具有有限或没有内置功能来自动缩减，因此请务必记录这些情况并定义处理缩减的过程。
许多 Azure 服务提供 API，可用于使用Azure 自动化设计自定义自动缩放操作，例如自动缩放Azure IoT 中心中的代码示例。 可以使用 KEDA 等工具进行事件驱动的自动缩放，可在 Azure Kubernetes 服务 和 Azure 容器应用中使用。
Azure Monitor 自动缩放为 Azure 虚拟机规模集、Azure App 服务、Azure Spring Apps 等提供了一组常见的自动缩放功能。 缩放可以按计划执行，也可以基于运行时指标（例如 CPU 或内存使用情况）。 有关最佳做法， 请参阅 Azure Monitor 指南 。
权衡
自动缩放注意事项
自动缩放不是即时见效的解决方案。 只是将资源添加到系统或运行进程的更多实例并不能保证提高系统性能。 设计自动缩放策略时，请注意以下几点：
系统必须设计为支持水平缩放。 避免对实例相关性做出假设。 不要设计要求代码始终在进程的特定实例中运行的解决方案。 水平缩放云服务或网站时，不要假定来自同一源的一系列请求始终路由到同一实例。 出于相同原因，请将服务设计为无状态，以避免需要将一系列来自应用程序的请求始终路由到同一服务实例。 在设计从队列读取并处理消息的服务时，不要假设哪个服务实例处理哪个特定消息。 随着队列长度的增长，自动缩放可能会启动更多服务的实例。 使用者竞争模式说明了如何解决这种情况。
如果解决方案实施长时间运行的任务，请将此任务设计为同时支持向外和向内缩放。 如果不小心，此类任务可能会阻止系统横向扩展时进程实例被彻底关闭。 或者，如果进程强行终止，它可能会丢失数据。 理想的情况是，重构长时间运行的任务并分解处理，使其以较小且不连续的块执行。 管道和筛选器模式提供了如何实现此解决方案的示例。
或者，你可以实现一种检查点机制，以定期记录有关任务的状态信息。 然后，可以将此状态保存在持久存储中，该存储可由运行任务的进程的任何实例访问。 这样，如果进程关闭，则另一个实例可以从最后一个检查点恢复它正在执行的工作。 有一些库提供此功能，例如 NServiceBus 和 MassTransit。 它们以透明方式保留状态，其中间隔与处理来自Azure 服务总线队列的消息保持一致。
当后台任务在单独的计算实例上运行（例如，在云服务托管应用程序的辅助角色中），可能需要使用不同的缩放策略来缩放应用程序的不同部分。 例如，可能需要部署额外的用户界面（UI）计算实例，而无需增加后台计算实例的数量，反之亦然。 如果提供不同的服务级别（如基本和高级服务包），则可能需要比基本服务包更积极地横向扩展高级服务包的计算资源，以满足服务级别协议（SLA）。
考虑 UI 和后台计算实例通信中的队列长度。 将其用作自动缩放策略的条件。 此问题可能是当前负载与后台任务的处理能力之间不平衡或差异的一个可能指标。 一个稍微复杂但更好的属性，从其基础缩放决策开始，是使用消息发送时间与处理完成时间之间的时间。 此间隔称为关键时间。 如果此关键时间值低于有意义的业务阈值，则无需缩放，即使队列长度较长也是如此。
例如，队列中可能有 50,000 条消息。 但最早消息的关键时间为 500 毫秒，终结点正在处理与第三方 Web 服务的集成，以便发送电子邮件。 业务利益干系人可能会认为，这是一段时间，不会证明花额外的资金进行缩放是正当的。
另一方面，队列中可能有 500 条消息，关键时间相同，但终结点是一些实时在线游戏中的关键路径的一部分，其中业务利益干系人定义了 100 毫秒或更少的响应时间。 在这种情况下，缩放是有意义的。
若要在自动缩放决策中使用关键时间，让库在发送和处理消息时自动将相关信息添加到消息的标头中会很有帮助。 提供此功能的一个库是 NServiceBus。
如果将自动缩放策略基于度量业务流程的计数器，例如每小时订单数或复杂事务的平均运行时间，请确保充分了解这些类型的计数器的结果与实际计算容量要求之间的关系。 可能需要缩放多个组件或计算单元，以响应业务流程计数器中的更改。
若要防止系统尝试过度扩展，并避免与运行数千个实例相关的成本，请考虑限制自动添加的最大实例数。 借助大多数自动缩放机制，可指定规则的实例数上限和下限。 此外，如果部署了最大实例数，并且系统仍然过载，请考虑正常降级系统提供的功能。
请记住，自动缩放可能不是处理工作负荷突然突发的最合适机制。 预配和启动服务的新实例或向系统添加资源需要一些时间，高峰需求可能会经过这些额外资源的时间。 在这种情况下，最好限制服务。 有关详细信息，请参阅限制模式。
相反，如果需要容量在卷快速波动且成本不是主要因素时处理所有请求，请考虑使用主动的自动缩放策略来更快地启动更多实例。 还可以使用计划的策略在最大负载来临前预先启动足量的实例。
自动缩放机制应监视自动缩放过程，并记录每个自动缩放事件的详细信息（触发的内容、添加或删除的资源以及何时）。 在创建自定义自动缩放机制时，请确保它包含此功能。 分析信息以帮助度量自动缩放策略的有效性，并根据需要进行优化。 在短时间内使用模式变得明显，以及长期业务拓展或对应用程序的要求变化时，可以进行优化。 如果应用程序达到为自动缩放定义的上限，该机制可能还会向操作员发出警报，操作员可以在必要时手动启动更多资源。 在这些情况下，操作员还可能负责在工作负载缓解后手动删除这些资源。
示例
请参阅 AKS 基线参考体系结构 缩放指南。
相关链接
可靠性清单
请参阅完整的建议集。