【韧性设计】节流模式

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 【韧性设计】节流模式

控制应用程序实例、单个租户或整个服务使用的资源消耗。这可以使系统继续运行并满足服务水平协议,即使需求增加对资源造成极大负载。


背景和问题

云应用程序的负载通常会根据活动用户的数量或他们正在执行的活动类型而随时间变化。例如,更多用户可能会在工作时间处于活跃状态,或者系统可能需要在每个月底执行计算成本高昂的分析。活动中也可能出现突然的和意料之外的爆发。如果系统的处理需求超过了可用资源的容量,那么它的性能就会很差,甚至会失败。如果系统必须满足商定的服务水平,则此类故障可能是不可接受的。

有许多策略可用于处理云中的不同负载,具体取决于应用程序的业务目标。一种策略是使用自动缩放在任何给定时间将供应的资源与用户需求相匹配。这有可能始终如一地满足用户需求,同时优化运行成本。但是,虽然自动缩放可以触发额外资源的配置,但这种配置并不是立即的。如果需求快速增长,可能会出现资源短缺的时间窗口。

解决方案

自动缩放的另一种策略是允许应用程序仅在某个限制内使用资源,然后在达到此限制时限制它们。系统应该监控它是如何使用资源的,以便当使用量超过阈值时,它可以限制来自一个或多个用户的请求。这将使系统能够继续运行并满足任何现有的服务水平协议 (SLA)。有关监控资源使用情况的更多信息,请参阅 Instrumentation and Telemetry Guidance。

该系统可以实施多种节流策略,包括:

  • 拒绝在给定时间段内每秒访问系统 API 超过 n 次的单个用户的请求。这需要系统计量每个租户或运行应用程序的用户的资源使用情况。有关详细信息,请参阅服务计量指南。
  • 禁用或降低选定非必要服务的功能,以便必要服务可以在有足够资源的情况下畅通无阻地运行。例如,如果应用程序正在流式传输视频输出,它可以切换到较低的分辨率。
  • 使用负载均衡来平滑活动量(基于队列的负载均衡模式更详细地介绍了这种方法)。在多租户环境中,这种方法会降低每个租户的性能。如果系统必须支持具有不同 SLA 的租户组合,则可能会立即执行高价值租户的工作。可以推迟对其他租户的请求,并在积压情况缓解后进行处理。优先队列模式可以用来帮助实现这种方法。
  • 推迟代表较低优先级的应用程序或租户执行的操作。这些操作可以暂停或限制,但会生成一个异常通知租户系统正忙,稍后应重试该操作。

该图显示了使用三个功能的应用程序的资源使用(内存、CPU、带宽和其他因素的组合)与时间的面积图。特性是功能的一个区域,例如执行一组特定任务的组件、执行复杂计算的一段代码或提供诸如内存缓存之类的服务的元素。这些特征标记为 A、B 和 C。

特性线正下方的区域指示应用程序在调用此特性时使用的资源。例如,功能 A 的线下方的区域显示正在使用功能 A 的应用程序使用的资源,功能 A 和功能 B 的线之间的区域表示调用功能 B 的应用程序使用的资源。聚合区域每个功能都显示系统的总资源使用情况。

上图说明了延迟操作的影响。就在时间 T1 之前,分配给使用这些功能的所有应用程序的总资源达到阈值(资源使用限制)。此时,应用程序有耗尽可用资源的危险。在这个系统中,功能 B 不如功能 A 或功能 C 重要,因此它被暂时禁用并且它正在使用的资源被释放。在时间 T1 和 T2 之间,使用功能 A 和功能 C 的应用程序继续正常运行。最终,这两个功能的资源使用减少到在时间 T2 有足够的容量再次启用功能 B 的程度。

自动缩放和限制方法也可以结合使用,以帮助保持应用程序响应并在 SLA 范围内。如果预计需求将保持高位,则在系统横向扩展时,节流提供了一种临时解决方案。此时,可以恢复系统的全部功能。


下图显示了系统中运行的所有应用程序对时间的总体资源使用情况的区域图,并说明了如何将限制与自动缩放结合起来。

在时间 T1,达到指定资源使用的软限制的阈值。此时,系统可以开始横向扩展。但是,如果新资源没有足够快地可用,则现有资源可能会耗尽,系统可能会失败。如前所述,为防止这种情况发生,系统会暂时受到限制。当自动缩放完成并且额外的资源可用时,可以放松限制。

问题和考虑

在决定如何实现此模式时,您应该考虑以下几点:

  • 限制应用程序和使用的策略是影响整个系统设计的架构决策。应该在应用程序设计过程的早期考虑节流,因为一旦实现了系统就不容易添加。
  • 必须快速执行节流。系统必须能够检测到活动的增加并做出相应的反应。系统还必须能够在负载减轻后迅速恢复到原始状态。这需要持续捕获和监控适当的性能数据。
  • 如果服务需要暂时拒绝用户请求,它应该返回特定的错误代码,以便客户端应用程序了解拒绝执行操作的原因是由于限制。客户端应用程序可以在重试请求之前等待一段时间。
  • 系统自动缩放时,节流可用作临时措施。在某些情况下,如果活动突然爆发并且预计不会长期存在,则最好简单地限制而不是扩展,因为扩展会大大增加运行成本。
  • 如果在系统自动缩放时将节流用作临时措施,并且如果资源需求增长非常快,则系统可能无法继续运行,即使在节流模式下运行也是如此。如果这不可接受,请考虑保持更大的容量储备并配置更积极的自动缩放。

何时使用此模式

使用此模式:

  • 确保系统继续满足服务水平协议。
  • 防止单个租户垄断应用程序提供的资源。
  • 处理活动的突发。
  • 通过限制保持系统运行所需的最大资源水平来帮助优化系统成本。

例子

最后一张图说明了如何在多租户系统中实现节流。每个租户组织的用户都可以访问云托管的应用程序,并在其中填写和提交调查。该应用程序包含监控这些用户向应用程序提交请求的速率的工具。

为了防止来自一个租户的用户影响应用程序对所有其他用户的响应能力和可用性,对来自任何一个租户的用户每秒可以提交的请求数施加了限制。应用程序阻止超过此限制的请求。

下一步

在实施此模式时,以下指南也可能是相关的:

  • 仪器仪表和遥测指导。限制取决于收集有关服务使用量的信息。描述如何生成和捕获自定义监控信息。
  • 服务计量指南。描述如何计量服务的使用,以了解它们的使用方式。此信息可用于确定如何限制服务。
  • 自动缩放指导。节流可用作系统自动缩放时的临时措施,或消除系统自动缩放的需要。包含有关自动缩放策略的信息。

相关指导

在实现此模式时,以下模式也可能是相关的:

  • 基于队列的负载均衡模式。基于队列的负载均衡是实现节流的常用机制。队列可以充当缓冲区,帮助平衡应用程序发送到服务的请求的速率。
  • 优先队列模式。系统可以使用优先队列作为其节流策略的一部分,以维持关键或更高价值应用程序的性能,同时降低不太重要的应用程序的性能。
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
17天前
|
存储 自然语言处理 JavaScript
箭头函数的性能优势体现在哪些方面?
【10月更文挑战第27天】箭头函数的性能优势主要体现在简化的 `this` 绑定机制、更轻量级的函数对象、减少预解析时间以及优化事件处理函数等方面。这些优势使得箭头函数在一些特定的场景下能够提高代码的执行效率和内存使用效率,从而提升整个应用的性能。不过,在实际开发中,性能提升的程度还会受到多种因素的影响,需要根据具体的应用场景和需求来综合考虑是否使用箭头函数。
32 0
|
3月前
|
Prometheus 监控 Java
微服务架构下的服务治理策略:打破服务混乱的惊天秘籍,开启系统稳定的神奇之门!
【8月更文挑战第7天】微服务架构将应用细分为可独立部署的小服务,提升灵活性与可扩展性。但服务增多带来治理挑战。通过服务注册与发现(如Eureka)、容错机制(如Hystrix)、监控工具(如Prometheus+Grafana)、集中配置管理(如Spring Cloud Config)和服务网关(如Zuul),可有效解决这些挑战,确保系统的高可用性和性能。合理运用这些技术和策略,能充分发挥微服务优势,构建高效应用系统。
62 1
|
4月前
|
存储 前端开发 JavaScript
链动2+1模式系统开发规则模式方案设计
随着区块链技术的日益成熟,越来越多的业务开始尝试利用区块链技术来提高效率、增加业务收入。然而,对于一些复杂的业务场景,传统的区块链架构可能无法完全满足需求。这时,我们可以考虑采用链动2+1模式系统开发方案,这是一种较为复杂的系统开发模式,其中包含两个公链和一个私链的组合。
|
4月前
|
数据库
交易链路设计原则&模式问题之在软件开发中,平衡业务需求和平台能力的边界,如何解决
交易链路设计原则&模式问题之在软件开发中,平衡业务需求和平台能力的边界,如何解决
|
6月前
|
SQL 运维 监控
老系统重构系列--稳定性摸排灵魂三问
该文主要讨论了老系统改造的过程和方法,特别是针对版权资产管理-财资系统的重构。作者强调了系统稳定性的重要性,并分享了他们团队在重构过程中采取的策略。他们通过确定目标、制定方法论和实施步骤来确保问题的全面摸排,包括核心链路图、流程时序图和问题路由图的绘制,以识别可能的问题和需要加强监控的部分。此外,文章还提到了数据对账监控和系统级统一监控的重要性,以及技术改造和预案的制定。作者提供了相关文章链接以供进一步阅读,并分享了他们在摸排和整改过程中的实际成果。
106 0
|
6月前
|
算法 测试技术 数据安全/隐私保护
简单粗暴的分佣机制:链动2+1系统开发案例
- 团队协作:在团队中合理分工,确保沟通和协作顺畅。 - 版本控制:使用版本控制系统来管理代码的修改和版本历史。 - 文档记录:及时记录开发过程中的决策、问题和解决方案。 - 安全性和隐私保护:考虑软件的安全性和隐私保护,遵循相关法律和准则。
|
区块链
关于DEFI模式系统详细方案技术开发逻辑讲解方案
关于DEFI模式系统详细方案技术开发逻辑讲解方案
|
资源调度 分布式计算 Kubernetes
技术抉择:阿里云13年后重构全部核心调度系统
在阿里云十三年的发展历史上,重新设计调度系统算得上是一个重要的技术抉择。
1350 11
技术抉择:阿里云13年后重构全部核心调度系统
|
算法 IDE 编译器
HLS设计方法论 - 优化硬件函数方法论及流水操作的优化策略
HLS设计方法论 - 优化硬件函数方法论及流水操作的优化策略
246 0
HLS设计方法论 - 优化硬件函数方法论及流水操作的优化策略
|
小程序 搜索推荐
聚合卡牌盲盒模式系统开发逻辑方案设计程序(成熟代码)
聚合卡牌盲盒模式系统开发逻辑方案设计程序(成熟代码)
310 0