你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
适用于此 Azure Well-Architected 框架可靠性清单建议:
RE:06 | 在应用程序、数据和基础结构级别实施及时可靠的缩放策略。 根据实际或预测的使用模式制定缩放策略,并最大程度地减少手动干预。 |
---|
本指南介绍设计可靠缩放策略的建议。
定义
术语 | 定义 |
---|---|
纵向扩展 | 向现有资源添加计算容量的缩放方法。 |
水平缩放 | 一种缩放方法,用于添加给定类型的资源实例。 |
自动缩放 | 满足一组条件时自动添加或删除资源的缩放方法。 |
注释
缩放作可以是静态的(定期计划每日缩放以适应正常负载模式)、自动(响应满足条件的自动化过程)或手动作(作员执行一次性缩放作来响应意外的负载更改)。 可以通过上述任何方法执行垂直和水平缩放。 但是,自动垂直缩放需要额外的自定义自动化开发,并可能导致停机,具体取决于正在缩放的资源。
系统必须设计为水平可缩放。 避免对实例相关性做出假设。 不要设计要求代码始终在进程的特定实例中运行的解决方案。 水平缩放云服务或网站时,不要假定来自同一源的一系列请求始终路由到同一实例。 出于同样的原因,设计服务是无状态的,以避免要求应用程序发出的一系列请求始终路由到服务的同一实例。 在设计从队列中读取消息并处理消息的服务时,不要对服务哪个实例处理特定消息做出任何假设。 随着队列长度的增长,自动缩放可能会启动更多服务的实例。 竞争使用者模式描述如何处理这种情境。
若要在自动缩放决策中使用关键时间,让库在发送和处理消息时自动将相关信息添加到消息的标头中会很有帮助。 提供此功能的一个库是 NServiceBus。
关键设计策略
根据负载模式进行设计
若要为工作负荷设计可靠的缩放策略,请专注于确定导致缩放作的每个工作负荷的用户和系统流的负载模式。 下面是不同负载模式及其相应的缩放策略的示例:
静态的: 每天晚上 11 点到晚上 EST,应用程序的活动用户数低于 100,应用服务器的 CPU 使用率在所有节点上下降 90%。 若要解决此问题,可以将计算节点的缩减计划为下午 11 点到上午 6 点之间的最小计数(2)。
动态、常规和可预测: 每周一早上,跨多个区域的 1000 名员工登录到 ERP 系统。 若要管理这一点,可以在第一个区域开始工作之前将计算节点的横向扩展计划到正常的每日容量。
动态、不规则和可预测的: 产品发布发生在当月的第一天,以及以前发布的历史数据,说明这些情况量如何增加。 若要解决此问题,可以在产品发布当天上午定义计算和数据库实例的一次性计划纵向扩展,并在一周后缩减。
动态、不规则和不可预知: 大规模事件导致产品需求激增。 例如,制造和销售除湿剂的公司在飓风或其他洪水事件后,在受灾地区的人需要在其家中干燥房间时,交通突然激增。 若要解决此问题,可以将自动缩放阈值设置为考虑计划外流量峰值。
调整缩放策略以适应各个组件或流
没有一个大小拟合的缩放策略。 不同的云服务对缩放的支持程度不同,以及缩放的不同方法。 因此,必须了解如何在所有工作负荷组件中支持和实现缩放,以设计总体缩放策略。 可以根据体系结构设计,在单个组件级别或流级别应用缩放策略。 确定如何在工作负荷之间实现缩放时,请考虑以下因素:
无法横向扩展的那些组件。例如,未启用分片且无法重构的大型关系数据库,而不会产生重大影响。 记录云提供商发布的资源限制,并密切监视这些资源。 在将来的规划中包括这些特定资源,以便迁移到可缩放的服务。
按缩放作顺序排列流的组件关系。 确保不无意中通过先缩放上游组件来重载下游组件。
任何可能被缩放作中断的有状态应用程序元素,以及实现的任何会话相关性(或会话粘性)。 粘性可以限制缩放能力,并引入单一故障点。 将工作负荷设计为在实际范围内无状态。
潜在的瓶颈。 横向扩展无法解决每个性能问题。 例如,如果后端数据库是瓶颈,则添加更多 Web 服务器并没有帮助。 先识别并解决系统中的瓶颈,然后再添加更多实例。 系统中有状态的部分最有可能引起瓶颈问题。
处理长时间运行的任务。 设计长期运行的任务,以支持横向扩展和缩小。 如果不小心,此类任务可能会阻止系统横向扩展时进程实例被彻底关闭。 或者,如果进程强行终止,它可能会丢失数据。 理想情况下,重构长时间运行的任务,并将其执行的处理分解为较小的离散区块。 管道和筛选器模式提供了如何实现此解决方案的示例。
选择合适的技术
考虑到缩放,做出明智的技术选择将有助于确保工作负载在工作负载发展时能够达到可靠性目标。 研究为提供类似功能的不同资源提供的缩放能力,并为未来的增长计划选择最佳组合。 例如,对于可以托管要使用的特定类型的数据库的数据存储,你可能有多个选项。 但是,一种选择可能比其他选项更适合现成的缩放功能,这使得它成为工作负荷更好的选择。
利用自动缩放的服务。 如果可行,请使用无需任何配置或输入即可自动缩放的 SaaS 服务。 Microsoft Entra ID 等全局服务提供此功能。 无服务器解决方案 还提供自动缩放功能,并且对于许多用例来说,这是一个很好的选择。
利用提供现用缩放的服务。 许多 PaaS 服务提供集成的易于使用的缩放功能,你可以配置这些功能以满足可靠性要求。 例如,可以为 Cosmos DB 配置吞吐量缩放 以满足特定要求。
自动缩放
在实际范围内自动执行工作负荷组件的缩放作。 使用具有可配置自动缩放功能的资源时,请将配置逻辑构建到基础结构即代码 (IaC) 部署代码中。 使用未提供自动缩放功能的资源时,使用本机自动化工具生成自动化以执行缩放作,并在 IaC 代码中包含自动化代码。
如果将自动缩放策略基于度量业务流程的计数器,例如每小时订单数或复杂事务的平均运行时间,请确保充分了解这些类型的计数器的结果与实际计算容量要求之间的关系。 可能需要缩放多个组件或计算单元,以响应业务流程计数器中的更改。
请记住,自动缩放可能不是处理工作负荷突然突发的最合适机制。 预配和启动服务的新实例或向系统添加资源需要一些时间,高峰需求可能会经过这些额外资源的时间。 在这种情况下,最好限制服务。 有关详细信息,请参阅 限制模式。
相反,如果需要容量在卷快速波动且成本不是主要因素时处理所有请求,请考虑使用主动的自动缩放策略来更快地启动更多实例。 您还可以使用预定策略,在预计负载到来之前启动足够数量的实例,以应对最大负载。
选择适当的缩放单位
将缩放策略基于缩放单元,这是组件要一起缩放的逻辑分组,以及要使用的缩放增量(例如,从一个 VM SKU 移动到另一个 VM SKU)。 要考虑的选项包括:
单独缩放资源:可能需要仅缩放单个 VM 或数据库。
同时缩放完整组件: 例如,你可能有一个微服务 API,该 API 由需要同时缩放的应用服务、数据库和队列组成。
缩放完整解决方案:对于复杂或任务关键型工作负荷,将整个解决方案缩放为 部署标记 可以简化缩放策略。 无需管理许多不同资源的缩放计划和自动缩放阈值,可以将有限的缩放定义集应用于部署标记,然后根据需要跨标记镜像。
重要
针对可自动分配的规模单位数设置最大限制,以避免产生超额成本。
优化缩放单元初始化时间
设计缩放策略时,请记住,不同的服务在不同的时间刻度上缩放。 有一些服务几乎即时缩放,而另一些服务缩放速度要慢得多。 例如,API 管理实例最多可能需要 45 分钟才能完成其缩放作。 若要考虑缩放作的时间刻度,请适当计划执行缩放作,然后再预期增加的负载达到工作负荷。 要考虑的其他建议包括:
将部署的预初始化节点以减少初始化所需的时间。
在进行进一步更改或使用系统之前,在配置更改之前允许缓冲时间。 例如,可以通过规则更改解除分配应用网关后端实例。 需要等待连接从该实例中排出,然后才能安全删除它。
过度预配资源,以处理缩放时增加的负载。 可以确保 VM 通常以 75% 利用率运行,以确保 VM 可以在水平缩放期间处理增加的负载。
使用监视微调缩放阈值。 使用容量监视来确保缩放阈值触发缩放作。
使用分片和分区缩放数据存储
通过在缩放策略中包含数据资产的可靠性来优化数据资产的可靠性。 将数据分区分散到逻辑或物理存储资源之间,从而消除单一故障点。 为用例选择最佳分区策略。
水平分区(分片):分区(分片)放置在单独的数据存储中,但所有分区具有相同的架构。 每个分片保存数据库的子集。 这是优化可靠性的好方法,因为它有助于实现负载均衡,并在处理问题时最大程度地减轻作负担。 可以复制分片以提高可靠性。
垂直分区:每个分区保存数据存储中项的字段子集。 这些字段根据其使用模式进行划分。
功能分区:根据系统中每个绑定上下文如何使用数据聚合数据。
设计分区方案时,请考虑合并这些策略。 例如,可以将数据划分为分片,然后使用垂直分区进一步细分每个分片中的数据。
优化分区策略,实现可伸缩性。 分析数据访问模式,以确定哪些作需要大多数处理资源,并平衡分区,以确保每个作有足够的资源来处理可伸缩性要求。
有关分区和分片的详细指南,请参阅 设计指南
监视缩放作
自动缩放机制应监视自动缩放过程,并记录每个自动缩放事件的详细信息(触发的内容、添加或删除的资源以及何时)。 如果创建自定义自动缩放机制,请确保它包含此功能。 主动分析信息,帮助衡量自动缩放策略的有效性,并在必要时对其进行优化。
Azure 便利化
许多 Azure 服务中都提供了自动缩放功能。 它允许你轻松配置条件以水平缩放实例。 某些服务具有有限或没有内置功能来自动缩减,因此请务必记录这些情况并定义处理缩减的过程。
许多 Azure 服务提供 API,可用于使用 Azure 自动化设计自定义自动缩放作,例如 自动缩放 Azure IoT 中心的代码示例。 可以使用 KEDA 等工具进行事件驱动的自动缩放,可在 Azure Kubernetes 服务和 Azure容器应用中使用。
Azure Monitor 自动缩放 为 Azure 虚拟机规模集、Azure 应用服务、Azure Spring Apps 等提供了一组常见的自动缩放功能。 缩放可以按计划执行,也可以基于运行时指标(例如 CPU 或内存使用情况)。 有关最佳做法,请参阅 Azure Monitor 指南 。
权衡
权衡:纵向扩展会产生成本影响,因此请优化策略以尽快缩减,以帮助控制成本。 确保用于纵向扩展的自动化也具有纵向缩减的触发器。
示例:
请参阅 AKS 基线参考体系结构 缩放指南。
相关链接
可靠性清单
请参阅完整的建议集。