你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
优化缩放成本的建议
适用于此 Azure 精心构建的框架成本优化清单建议：
| CO：12 | 优化缩放成本。 评估缩放单元中的替代缩放。 考虑替代缩放配置，并与成本模型保持一致。 注意事项应包括针对每个实例、资源和缩放单元边界的继承限制的利用率。 使用策略来控制需求和供应。 |
|---|
本指南提供有关优化缩放成本的建议。 成本优化缩放是删除工作负荷缩放效率低下的过程。 目标是降低缩放成本，同时仍满足所有非功能要求。 花更少的钱来获得相同的结果。 通过优化缩放，可以避免不必要的费用、过度预配和浪费。 它还通过控制需求和限制供应来帮助防止成本意外飙升。 低效的缩放做法可能导致工作负荷和运营成本增加，并对工作负荷的整体财务运行状况产生负面影响。
定义
| 术语 | 定义 |
|---|---|
| 自动缩放 | 满足一组条件时自动添加或删除资源的缩放方法。 |
| 成本指标 | 与工作负荷成本相关的数值数据。 |
| 纵向缩减 | 垂直缩放策略，该策略会转移到较低的 SKU，以向工作负荷提供更少的资源。 |
| 缩小 | 一种水平缩放策略，用于删除实例，以向工作负荷提供更少的资源。 |
| 横向扩展 | 一种水平缩放策略，用于添加实例以向工作负荷提供更多资源。 |
| 缩放单元 | 一组按比例缩放的资源。 |
| 纵向扩展 | 垂直缩放策略，该策略会转移到更高的 SKU，以向工作负荷提供更多资源。 |
| 库存单位 (SKU) | Azure 服务的服务层。 |
| 使用情况数据 | 使用情况数据是有关使用任务、服务或应用程序的直接信息（真实）或间接/代表性信息（代理）。 |
关键设计策略
成本优化缩放的目标是在最后责任时刻进行纵向扩展和横向扩展，并在实际操作后尽快纵向扩展和缩减。 若要优化工作负载的缩放，可以在缩放单元中评估备用缩放选项，并将其与成本模型保持一致。 缩放单元表示可以独立缩放或一起缩放的资源的特定分组。 应设计缩放单元来处理特定数量的负载，它们可以包含多个实例、服务器或其他资源。 需要评估工作负荷缩放单元和模型备用项的成本效益。
如果不使用缩放，请参阅有关缩放工作负荷的指南。 需要确定应用程序是否可以缩放。 无状态应用程序更易于缩放，因为它们可以同时处理多个请求。 此外，评估应用程序是否是使用分布式系统原则生成的。 分布式系统可以通过跨多个节点分配工作负荷来处理增加的负载。 但是，单一实例应用程序设计为在任何给定时间只运行一个实例。 因此，缩放可能不适合所有工作负荷。
评估横向扩展与纵向扩展
评估横向扩展与纵向扩展包括根据定价、工作负载要求和可接受的故障时间等各种因素，在增加现有系统中的资源（纵向扩展）或添加该系统的更多实例（横向扩展）之间确定最经济高效的方法。 选择正确的缩放方法可以节省大量成本，从而确保只需为所需的内容付费，同时仍满足性能和可靠性标准。
目标是根据服务层级定价、工作负荷特征、可接受的停机时间和成本模型来确定最经济高效的选择。 对于一些人，选择数量较少的更昂贵的实例可能更经济。 相反，对于其他人来说，具有更多实例的更便宜的层可能更好。 若要做出明智的决策，需要分析设置中的实际数据或代表性数据，并评估每个策略的相对成本优点。 若要评估最经济高效的方法，请考虑以下建议：
收集使用情况数据：收集代表工作负荷使用模式和资源利用率的实际生产数据或代理数据。 此数据应包括 CPU 使用率、内存使用率、网络流量以及影响缩放成本的任何其他相关指标等指标。
定义成本指标：确定与工作负荷相关的成本指标，例如每小时成本、每个事务的成本或资源使用情况单位的成本。 这些指标可帮助你比较不同缩放选项的成本效益。
收集使用情况数据：收集代表工作负荷使用模式和资源利用率的实际生产数据或代理数据。 此数据应包括 CPU 使用率、内存使用率、网络流量以及影响缩放成本的任何其他相关指标等指标
定义成本指标：确定与工作负荷相关的成本指标，例如每小时成本、每个事务的成本或资源使用情况单位的成本。 这些指标可帮助你比较不同缩放选项的成本效益。
请参阅要求：在横向扩展和纵向扩展策略之间进行决定时，请考虑工作负荷的可靠性、性能和缩放要求。 横向扩展可以通过冗余提高可靠性。 纵向扩展会增加资源的容量，但可能会限制可以纵向扩展的容量。
考虑资源限制：评估缩放选项时，请务必考虑每个实例、资源和缩放单元边界的固有限制。 请注意每个资源的缩放上限，并相应地进行计划。 此外，请记住订阅和其他资源的限制。
测试缩放：为不同的缩放方案创建测试，包括横向扩展和纵向扩展选项。 应用使用情况数据，模拟不同缩放配置下的工作负荷行为。 使用建模的缩放方案进行实际测试。
计算成本：使用收集的数据和成本指标来计算与每个缩放配置关联的成本。 请考虑实例定价、资源利用率以及与缩放相关的任何额外费用等因素。
优化自动缩放
优化自动缩放策略涉及优化自动缩放，以根据工作负荷的非功能要求对负载更改做出反应。 可以通过调整阈值和使用适当的冷却期来限制过度缩放活动。 若要优化自动缩放，请考虑以下建议：
分析当前的自动缩放策略：了解现有策略及其行为，以响应不同的负载级别。
请参阅非功能要求：确定需要考虑的特定非功能要求，例如响应时间、资源利用率或成本。
调整缩放阈值：根据工作负荷特征和非功能要求调整缩放阈值。 根据一段时间内的 CPU 使用率、网络流量或队列长度等因素设置纵向扩展或缩减的阈值。
调整冷却期：调整冷却期，以防止临时负载高峰触发的过度缩放活动。 冷却期引入了缩放事件之间的延迟，使系统能够在进一步缩放操作之前稳定下来。
监视和微调：持续监视系统的行为和性能。 分析缩放活动并根据需要调整策略，以优化成本并满足所需的非功能要求。
权衡：减少缩放事件的数量会增加遇到与缩放相关的问题的机会。 这意味着你正在消除额外的缓冲或缓冲区，以帮助管理潜在的问题或延迟从缩放。
使用基于事件的缩放
事件驱动的自动缩放允许应用程序根据特定事件或触发器动态调整资源，而不是 CPU 或内存利用率等传统指标。 例如，Kubernetes 事件驱动的自动缩放（KEDA）可以根据缩放程序（例如 Kafka 主题的长度）缩放应用程序。 精度有助于防止不必要的缩放波动和资源浪费。 高精度级别最终可优化成本。 若要使用基于事件的缩放，请执行以下步骤：
选择事件源：确定触发缩放单元缩放的事件源。 源可以是消息队列、流式处理平台或任何其他事件驱动系统。
设置事件引入：将应用程序配置为使用所选事件源中的事件。 它通常涉及建立连接、订阅相关主题或队列以及处理传入事件。
实现缩放逻辑：编写逻辑，确定缩放单元应基于传入事件缩放的时间和方式。 此逻辑应考虑各种因素，例如事件数、传入事件的速率或任何其他相关指标。
与缩放机制集成：根据应用程序的运行时环境，可以使用不同的缩放机制来调整分配给应用程序的资源。
配置缩放规则：定义缩放规则，这些缩放规则指定缩放单元在响应事件时应如何缩放。 这些规则可以基于阈值、模式或任何其他符合应用程序要求的条件。 缩放阈值应与业务指标相关。 例如，如果再添加两个实例，则可以在购物车处理中再支持 50 个用户。
测试和监视：通过使用不同的事件方案测试基于事件的缩放实现的行为。 监视缩放操作并确保操作符合预期。
优化需求和供应
根据供应控制需求。 在使用情况确定缩放的工作负荷上，成本与缩放相关。 若要优化缩放成本，可以最大程度地减少缩放支出。 可以通过向其他资源分配需求来卸载需求，也可以通过实现优先级队列、网关卸载、缓冲和速率限制来减少需求。 由于缩放和资源消耗，这两种策略都可以防止意外成本。 还可以通过限制缩放限制来控制供应。 若要优化工作负荷需求和供应，请考虑以下建议。
卸载需求
卸载需求是指将资源需求分发或转移到其他资源或服务的做法。 可以使用各种技术或策略：
缓存：使用缓存来存储经常访问的数据或内容，从而减少后端基础结构上的负载。 例如，使用内容分发网络（CDN）来缓存和提供静态内容，从而减少缩放后端的需求。 但是，并非每个工作负荷都可以缓存数据。 需要最新和实时数据（如交易或游戏工作负载）的工作负载不应使用缓存。 缓存的数据将旧且与用户无关。
权衡。 缓存可能会在缓存失效、一致性和管理缓存过期方面带来挑战。 请务必仔细设计和实施缓存策略，以避免潜在的权衡。内容卸载：将内容卸载到外部服务或平台，以减少基础结构上的工作负荷。 例如，可以在独立于主服务器的单独存储服务中托管这些文件，而不是在主服务器上存储视频文件。 可以直接从存储服务加载这些大型文件。 此方法释放服务器上的资源，使你能够使用较小的服务器。 将大型文件存储在单独的数据存储中可能更便宜。 可以使用 CDN 来提高性能。
负载均衡：使用负载均衡跨多个服务器分配传入请求。 负载均衡均匀分配工作负荷，并阻止任何单一服务器变得不知所措。 负载均衡器优化资源利用率，并提高基础结构的效率。
数据库卸载：通过将数据库操作卸载到单独的数据库服务器或专用服务来减少主应用程序服务器上的负载。 例如，使用 CDN 进行静态内容缓存，将 Redis 缓存用于动态内容（数据库中的数据）缓存。 数据库分片、只读副本或使用托管数据库服务等技术还可以减少负载。
权衡： 将特定任务卸载到备用资源有助于减少或避免与缩放相关的额外缩放和成本。 但是，请务必考虑卸载时可能出现的操作和维护挑战。 为工作负荷选择最合适的卸载技术时，进行全面的成本效益分析至关重要。 此分析可确保所选方法在预期的节省和操作复杂性方面既有效又可行。
减少需求
减少资源需求意味着实施有助于最大程度地减少工作负荷中的资源利用率的策略。 卸载需求会将需求转移到其他资源。 减少需求会减少对工作负荷的需求。 通过减少需求，可以避免超量预配资源以及为未使用或未充分利用的产能付费。 应使用代码级设计模式来减少对工作负载资源的需求。 若要通过设计模式减少需求，请执行以下步骤：
了解设计模式：熟悉促进资源优化的各种设计模式。
分析工作负荷要求：评估工作负荷的特定要求，包括其预期的需求模式、峰值负载和资源需求。
选择适当的设计模式：选择符合工作负荷要求和目标的设计模式。 例如，如果工作负荷遇到波动的需求，事件驱动的缩放和限制模式可以通过动态分配资源来帮助管理工作负荷。 将所选设计模式应用于工作负荷体系结构。 可能需要分离工作负荷组件、容器化应用程序、优化存储利用率等。
持续监视和优化：定期评估实现的设计模式的有效性，并根据需要进行调整。 监视资源使用情况、性能指标和成本优化机会。
通过执行这些步骤并使用适当的设计模式，可以降低资源需求、优化成本，并确保其工作负荷高效运行。
使用这些设计模式来减少需求：
缓存端：模式检查缓存，以查看数据是否已存储在内存中。 如果在缓存中找到数据，应用程序可以快速检索和返回数据，从而减少查询持久性数据存储的需求。
声明检查：通过将数据与消息流分离，此模式可减小消息的大小，并支持更具成本效益的消息传送解决方案。
竞争使用者：此模式通过应用分布式和并发处理来有效处理队列中的项。 此设计模式通过缩放来优化成本，该缩放基于队列深度，并针对最大并发使用者实例设置限制。
计算资源整合：此模式通过合并共享基础结构上的多个应用程序或组件来增加密度并合并计算资源。 它将资源利用率最大化，避免未使用的预配容量并降低成本。
部署戳：使用部署戳记提供了多种优势，例如设备异地分布组、将新功能部署到特定标记以及观察每个设备的成本。 部署标记可提供更好的可伸缩性、容错性和高效的资源利用率。
网关卸载：此模式会卸载网关设备中的请求处理，并将每个节点资源的成本重定向到网关实现。 使用此设计模式可能会导致集中处理模型中的所有权成本降低。
发布者/订阅者：此模式将体系结构中的组件分离，并将直接通信替换为中间消息代理或事件总线。 它支持事件驱动的方法和基于消耗的计费，避免过度预配。
基于队列的负载调配：模式缓冲队列中的传入请求或任务。 缓冲可以平滑处理工作负荷，并减少过度预配资源来处理峰值负载的需求。 以异步方式处理传入请求，以降低成本。
分片：此模式将特定请求定向到逻辑目标，从而允许使用数据并置进行优化。 分片可能会导致成本节省，方法是使用多个较低规格的计算或存储资源实例。
静态内容托管：此模式通过使用专为此目的设计的托管平台有效地提供静态内容。 它避免使用更昂贵的动态应用程序主机，从而优化资源利用率。
限制：此模式对资源或组件的传入请求的速率（速率限制）或吞吐量施加限制。 它有助于通知成本建模，并可直接绑定到应用程序的业务模型。
辅助密钥：此模式可授予对资源的安全和独占访问权限，而无需涉及更多组件，减少对中间资源的需求并提高效率。
控制供应
定义你愿意在特定资源或服务上花费的金额上限是控制供应的一种方法。 这是控制成本并确保支出不超过特定级别的重要策略。 建立预算并监视支出，以确保其保持在定义的金额内。 可以使用成本管理平台、预算警报或跟踪使用情况和支出模式。 某些服务允许你限制供应和限制速率，并且应该使用这些功能来提供帮助。
控制供应是指定义你愿意在特定资源或服务上花费的金额上限。 这是一个重要的策略，因为它有助于控制成本并确保费用不超过某一特定级别。 建立预算并监视支出，以确保其保持在定义的阈值内。 可以使用成本管理平台、预算警报或跟踪使用情况和支出模式。 某些服务允许你限制供应和限制速率，并且应该使用这些功能来提供帮助。
Azure 便利化
评估横向扩展与纵向扩展：Azure 提供了一个测试环境，可在其中部署和测试不同的缩放配置。 通过使用实际工作负荷数据或代理数据，可以模拟实际方案并衡量对成本的影响。 Azure 提供用于性能测试、负载测试和监视的工具和服务，这有助于评估横向扩展与纵向扩展选项的成本效益。
Azure 通过各种工具和服务（例如 Azure 顾问）提供成本管理建议。 这些建议分析使用情况模式、资源利用率和缩放配置，以提供优化成本的见解和建议。
Azure 负载测试 是一项完全托管的负载测试服务，可生成大规模负载。 该服务可以模拟应用程序的流量，且无需其托管位置。 开发人员、测试人员和质量保证（QA）工程师可以使用负载测试来优化应用程序性能、可伸缩性或容量。
优化自动缩放：许多 Azure 计算服务支持部署多个相同的实例，并快速优化缩放阈值和策略。 Azure 提供自动缩放功能，使你可以根据工作负荷需求自动调整实例或资源的数量。 可以定义缩放规则和阈值，以触发横向扩展或横向扩展操作。 通过使用自动缩放，可以通过根据实际需求动态缩放资源来优化资源分配和成本效益。
Azure 维护订阅和服务限制的列表 。 在每个资源组中部署的资源实例数有一般限制，但有一些例外情况。 有关详细信息，请参阅 每个资源组的资源实例限制。
优化需求和供应：Azure Monitor 提供有关应用程序和基础结构性能和运行状况的见解。 可以使用 Azure Monitor 监视资源负载，并分析一段时间内的趋势。 通过使用 Azure Monitor 收集的指标和日志，可以确定可能需要缩放调整的区域。 此信息可以指导自动缩放策略的优化，以确保它符合非功能要求和成本优化目标。
卸载供应：Azure 有一个名为 Azure Front Door 的新式云内容分发网络（CDN）和缓存服务（Azure Redis 缓存和 Azure HPC 缓存）。 CDN 将内容缓存到更接近最终用户，从而减少网络延迟并提高响应时间。 缓存将数据存储在主数据存储前的数据副本，从而减少了对后端的重复请求的需求。 通过使用 CDN 和缓存服务，可以优化性能并降低服务器上的负载，从而节省潜在的成本。
控制供应：Azure 还允许为云工作负荷设置资源限制。 通过定义资源限制，可以确保工作负荷保留在分配的资源中，并避免不必要的成本。 Azure 提供了各种机制来设置资源限制，例如配额、策略和预算警报。 这些机制有助于监视和控制资源使用情况。
API 管理可以对限制和限制请求进行速率限制。 限制传入请求是 Azure API 管理的重要功能。 通过控制请求的速率或传输的请求/数据总量，API 管理让 API 提供程序能够保护其 API 不被滥用，为不同的 API 产品层创造价值。
相关链接
- 缩放工作负荷
- Azure 顾问成本建议
- 什么是 Azure 负载测试？
- Azure 订阅和服务限制、配额和约束
- 资源不限于每个资源组 800 个实例
- 什么是 Azure Front Door？
- 什么是 Azure Redis 缓存？
- 什么是 Azure HPC 缓存？
- 使用 Azure API 管理进行高级请求限制
成本优化清单
请参阅完整的建议集。