高可用三大利器 — 熔断、限流和降级

这篇具有很好参考价值的文章主要介绍了高可用三大利器 — 熔断、限流和降级。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

近年来,各大厂Google、微软、阿里、腾讯等都在提高可用的概念。高可用(High Availability,简称HA)是指系统或服务在遭受故障或异常情况时仍能持续提供稳定和可靠的运行能力。

在武侠世界里,“利器”通常指的是武器中的上乘、出色之物;武器对于武者的重要性不言而喻,拥有一把优秀的武器可以让武者在战斗中更加得心应手,威力更强。

在分布式系统追求高可用的背景下,熔断、限流和降级这三个重要的策略可以称得上三大利器。

熔断(Circuit Breaker):熔断是一种防止故障扩散的策略。当一个服务出现故障或超时,熔断器会打开并快速失败,拒绝后续的请求,避免请求堆积和资源耗尽。熔断器会暂时屏蔽该服务,并在一段时间后尝试恢复。熔断器的状态变化可用于监控系统健康和提供告警信息。

限流(Rate Limiting):限流是一种控制系统请求流量的策略。通过设置一个请求速率阈值,限流可以限制每个客户端或用户在特定时间内的请求次数。这样可以防止过多的请求涌入系统,保护系统免受过载和压力冲击。限流可以平滑流量,避免系统突发流量的影响。

降级(Fallback):降级是一种在面对特殊业务或异常情况时保持系统可用的策略。当服务不可用时,降级服务会代替提供一些基本功能或返回预设的默认值,以确保系统依然能够提供有限的功能或服务;又或者某些特定活动场景(例如:双十一)下优先保障计算资源投入到 业务倾向的服务,降级边缘服务。

熔断(Circuit Breaker)

在分布式架构中,一个服务通常会与多个外部服务进行交互,这些外部服务可能是RPC接口、数据库、第三方API等。例如,在支付过程中,可能需要调用银联提供的API;而查询某个商品的价格,则可能需要进行营销活动查询。然而,除了自身服务外,依赖的外部服务的稳定性是无法绝对保证。

当依赖的第三方服务出现不稳定的情况时,例如三方服务器过载,会导致服务自身调用第三方服务的响应时间也变长,甚者形成级联效应。这样一来,服务自身的线程可能会积压,最终可能耗尽业务自身的线程池,导致服务本身变得不可用。

高可用三大利器 — 熔断、限流和降级

熔断(Circuit Breaker)就是应对这种三方服务不稳定的设计,它可以帮助系统在出现问题时保持高可用,防止故障进一步扩散,同时也能在一段时间后重新尝试恢复正常操作。避免局部不稳定因素导致整个分布式系统的雪崩。作为保护服务自身的手段,通常在客户端(调用端)进行配置。

熔断器模式(Circuit Breaker Pattern),是Michael Nygard在他的著作《Release It!》中开始推荐使用的。其可以防止应用程序反复尝试执行可能会失败的操作,使其能够继续进行而无需等待故障被修复,也无需浪费CPU周期来确定故障是否持久。Circuit Breaker模式还使应用程序能够检测故障是否已解决。如果问题似乎已经解决,应用程序可以尝试调用该操作。

注:这种设计也是典型的 快速失败原则(Fail-Fast Principle) 的应用。强调在面对错误或异常情况时,系统应该尽早地检测并快速失败,而不是继续执行可能导致更严重后果的操作。这个原则的目的是尽早发现问题并及时处理,避免故障进一步扩大,从而提高系统的稳定性和可靠性。

熔断器模式中最关键的设计在于熔断器的三种状态:

  • Closed状态:来自应用程序的请求被 Proxy 操作。Proxy 维护最近故障次数的计数,如果对操作的调用不成功,Proxy 会增加这个计数。如果在给定的时间段内最近故障的次数超过了指定的阈值,Proxy 将进入Open状态。此时,Proxy 启动一个超时计时器,当计时器到达阈值时,Proxy 将进入Half-Open状态。(这里 Proxy 代指 Resilience4j、Sentinel、Hystrix类似框架)

  • Open状态:来自应用程序的请求立即失败,并向应用程序返回异常。

  • Half-Open状态:应用程序允许有限数量的请求通过并调用操作。如果这些请求成功,假定之前导致失败的故障已经修复,将切换到Closed状态(故障计数器被重置)。如果任何请求失败,会认为故障仍然存在,因此它会回退到Open状态,并重新启动超时计时器,为系统提供进一步的时间来从故障中恢复。。

高可用三大利器 — 熔断、限流和降级

许多开源的框架都基于这三个状态进行了熔断实现的设计,比如:Resilience4j、Sentinel、Hystrix;就实际使用上推荐 Sentinel 和 Resilience4j ,因为 Hystrix 已经宣布不维护了。附上,一张网上广泛流传的对比表格 [1]

高可用三大利器 — 熔断、限流和降级

开源框架仅仅只是熔断机制的代码实现,更重要的在于结合具体业务常见来设计相关的熔断策略。这里列出一些通常具体业务设计熔断时候的考量点:

熔断异常应该如何处理:三方服务处于在熔断 Open状态下,应该如何进行服务的返回。比如:用一个默认值来替代三方服务的返回结果;返回异常页面告知用户稍后再重试;调用其他的服务来替代原来的功能等。异常往往多样的,也可以考虑不同异常下设置不同的处理方式。

应该记录详细日志:注意异常日志的记录,确保关键信息都写入日志,往往线上故障异常的多样的;好的日志格式/日志设计能够快速的定位问题、监控熔断策略符合预期。熔断状态的转换需要详细写入,方便复盘熔断策略。

是否需要诊断定时程序:当处于熔断 Open状态时,考虑是否需要来做个定时程序 测试三方服务是否恢复并转换 到 Half-Open状态,更灵活的恢复服务。

管理熔断的工具:由于异常是多样的,某些情况下意外触发了熔断;此时管理员可以通过熔断工具来恢复相关状态,应对熔断策略出现问题的情况。

注意三方服务耗时:有时候三方服务能够正常返回但耗时很长,这样可能会导致自身服务的超时;针对这种情况应该进行相关超时熔断处理,应该关注这种隐蔽的超时异常。

限流(Rate Limit)

无论服务器的硬件多么强大,总归也是有限的资源只能处理有限的请求;简单理解限流(Rate Limit)的话,在有限时间内请求数量超过服务的处理数量,自动丢弃新来的请求从而保障有限的请求高可用。

用日常例子来类比说明就很好理解,一个餐厅只有5张四人桌,理想坐满的情况也也就是20个人;而如果涌进来50个人都点单,那么每个人都无法正常的用餐。因此,要限制进来的人数是保障正常用餐。

同样的对于系统而言,一次性接受超出硬件承载的资源,就会导致资源的剧烈竞争从而 导致请求服务的延迟、异常等等,无法提供到高可用的服务。为此,对服务进行限流保护是提供高可用的重要策略了。

以下是常见的限流算法:

固定窗口计数限流算法(Fixed Window Counter):在固定的时间窗口内,限制请求的数量。例如,在1秒内最多允许处理10个请求,当窗口满时,后续请求将被拒绝。

滑动窗口计数限流算法(Sliding Window Counter):设置一个滑动时间窗口,计算在该时间窗口内的请求数量,并限制其在指定范围内。与固定窗口计数算法相比,滑动窗口算法允许更加灵活的流量控制。

令牌桶算法(Token Bucket):令牌桶算法通过将请求放入令牌桶中来控制流量。每个请求需要从令牌桶中获取令牌,如果桶中没有足够的令牌,则请求被拒绝。令牌桶算法允许突发流量一定程度的处理,并平滑了请求的速率。

  1. 令牌桶是一个固定容量的桶,它以恒定的速率产生令牌(即令牌产生速率),并将其放入桶中。
  2. 桶中最大可以保存的令牌数量为桶的容量,当桶满时,多余的令牌会被丢弃。
  3. 每当有请求到达时,如果令牌桶中有足够的令牌,该请求会获取一个令牌,并被处理。如果桶中没有令牌可用,该请求将被延迟或丢弃。
  4. 令牌桶可以应用于固定窗口计数限流算法和滑动窗口计数限流算法。在固定窗口计数限流中,令牌桶以固定速率产生令牌,而在滑动窗口计数限流中,令牌桶按照滑动时间窗口的速率产生令牌。

令牌桶算法的优点在于,它可以平滑地处理突发流量,即使在短时间内有大量请求到达,令牌桶算法仍然能够保持相对稳定的速率来处理这些请求。此外,令牌桶算法还可以允许一定程度的突发流量,因为桶中积累的令牌可以处理突发的请求。令牌桶算法的缺点是在某些情况下可能会导致请求的延迟。如果请求到达时桶中没有足够的令牌,该请求将被延迟等待令牌,可能会导致响应时间增加。

漏桶算法(Leaky Bucket):漏桶算法将请求放入一个漏桶中,请求以恒定的速率从漏桶中流出。如果漏桶已满,则多余的请求将被拒绝。漏桶算法可以用于平滑流量,防止突发请求造成的资源浪费。

  1. 漏桶是一个固定容量的桶,它有一个漏口。桶底的漏口以固定的速率(即令牌产生速率)漏水。
  2. 每个请求都会向漏桶中添加一个令牌。如果漏桶已满(即桶内令牌数量达到了最大容量),则新的令牌会被丢弃。
  3. 当请求到达时,如果漏桶中有可用的令牌,则请求被处理,且漏桶中的令牌数量减少一个。如果漏桶中没有足够的令牌,则请求被丢弃或延迟处理。

漏桶算法的优点在于,它能够以固定的速率来处理请求,从而平滑流量,防止突发请求对系统造成过大的压力。此外,漏桶算法还能够控制流出速率,避免资源的浪费;然而,漏桶算法的缺点是对于突发流量的处理相对较差。如果漏桶中的令牌数量耗尽,那么突发流量的请求会被丢弃,可能会导致某些请求的延迟。

降级(Fallback)

不知道大家是否有经历,当在楼下沙县小店吃面时,如果小店人不多的情况下 店员会端上一碟小菜给到我们;而人很多的情况,如果想吃小菜可以自己去窗口附近用小蝶装取。换个角度,这其实也可以称得上服务降级。

服务降级往往指在面对系统过载、资源不足、有计划的大型活动(双十一),有意识地降低系统的部分功能或服务质量,以保证系统的核心功能和关键服务仍能继续正常运行。

举个例子,电商系统中支持 商家对商品的价格调整 是一种非常常见的功能,但当 双十一零点的时刻 往往会和商家达成一致 不提供在零点后一段时间内商品价格的调整服务,以用来保障零点活动的高效执行。

所以降级是一种非常规应对措施,不应该成为长期的解决方案。一旦面对情况有所改变就应该恢复降级的服务,确保系统能够正常提供全部功能和服务。

降级本身的实现是根据具体业务规则来进行编码,常见的设计有:

开关硬编码: 用一个参数标识是否进行降级,在服务中用 if 来判断标识 从而进行相关服务降级的业务逻辑。如果时间很短情况下要实现降级,可能是最直接最常见的选择。

AOP拦截:通过 AOP切面面编程拦截服务请求,并更加服务降级的业务要求条件,调用降级服务请求。因为使用到了 AOP切面技术,代码侵入性小,但代码可读性差;如果没有一些注释说明,不熟悉相关业务的研发者忽略了降级拦截。

策略/工厂设计模式:在服务设计的时候采用工厂 或者 策略的设计模式,根据降级业务要求条件来进行策略/工厂的具体服务生成,从而实现服务降级逻辑。代码逻辑实现上会复杂些,可能带来更多类,可读性上对于设计模式不熟悉的研发者造成疑惑。

三者的关系

行文至此,也许有部分读者困惑比如:降级和熔断是不是一回事?熔断后执行策略就相当于降级?

纠结于这些问题的本身,还是要回到文章开头三大策略提出所面对解决的高可用问题。熔断是针对防止故障扩散所进行的策略设计,而 降级面对的是特殊场景的 服务功能/质量的调整策略。

因此,可以看到 描述降级中提到的 双十一零点前关闭商家价格调整的功能,显然 并非为了防止故障扩散的措施而是保障其他业务关注功能性能(不是熔断,主动改变);同样的,也可以举个例子当调用某个服务失败高时,切换调用到备用服务器来作为熔断处理策略,此时提供的服务功能或许都没有变化,只是启动了熔断一种技术处理策略(不属于服务降级)。

两者并非一回事。但如果考虑到 熔断发生时,处理的方式是 调整某种产品功能服务,那其实既可以算熔断也可以算降级,所以有些文章中也有提到 熔断降级 的概念。限流 与 降级呢? 熔断 与 限流呢? 在此就不一一赘述了,简而言之的话,三者都非一回事,但在某些场景下相互支撑。

熔断、限流、降级这些概念,更多是指导 在分布式系统 高可用设计上 应该考虑方面,其核心目的都是 达到系统的高可用。

转载望能 保留,欢迎关注 Java研究者 公众号文章来源地址https://www.toymoban.com/news/detail-607536.html

参考文献

  • sentinel 限流熔断神器详细介绍 https://blog.csdn.net/a745233700/article/details/122733366
  • Release It! Second Edition https://pragprog.com/titles/mnee2/release-it-second-edition/
  • Rate Limiting pattern https://learn.microsoft.com/en-us/azure/architecture/patterns/rate-limiting-pattern
  • Computer Network | Leaky bucket algorithm https://www.geeksforgeeks.org/leaky-bucket-algorithm/
  • Fallback pattern https://badia-kharroubi.gitbooks.io/microservices-architecture/content/patterns/communication-patterns/fallback-pattern.html

到了这里,关于高可用三大利器 — 熔断、限流和降级的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • [分布式]-限流熔断降级

    限流,顾名思义,限制系统的流量,防止用户过多地访问系统的资源,甚至是恶意地访问,比如恶意爬虫,DDOS 等;同时也防止系统承载过多流量而崩溃,从而对系统运行资源做到一个有效的管理 在分布式系统中,节点之间需要相互调用,如果调用链中一个节点宕机,将会导

    2024年02月09日
    浏览(40)
  • 简单理解微服务限流、降级、熔断

    微服务限流、降级、熔断分别都是什么意思,我们平时工作中为什么要关注这些东西呢? 公司不断的发展壮大,一开始处于蛮荒时代,咱们从单体应用过渡到微服务的时候,可能还是那一套单体的思想,再加上用户量可能也不多,直接就不去考虑起量了之后,我们需要如何处

    2024年02月09日
    浏览(42)
  • 熔断、限流、降级 —— SpringCloud Alibaba Sentinel

    Sentinel 是阿里中间件团队开源的,面向分布式服务架构的高可用流量防护组件,主要以流量为切入点,从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性 Sentinel 提供了两个服务组件: Sentinel 用来实现微服务系统中服务熔断

    2024年02月08日
    浏览(72)
  • 微服务中的熔断、降级和限流

    在现代微服务架构中,熔断、降级和限流是保障系统稳定性和可靠性的重要手段。本文将深入探讨这三种机制在微服务架构中的作用、原理以及实践方法。 1.1 作用和原理 熔断器是一种可以在服务发生故障时快速中断请求的机制,防止故障蔓延到整个系统。当服务出现异常或

    2024年02月22日
    浏览(44)
  • 第27天-熔断,降级,限流,网关流控,服务链路追踪

    1.1.1.熔断 A服务调用B服务某个功能,由于网络不稳定问题,或者B服务卡机,导致功能时间超长。如果这样的次数太多,我们就可以直接将B服务断路(A不再请求B接口),凡是调用B服务就直接返回降级数据,不必等待B服务的超长执行,这样B服务的故障问题,就不会级联影响到

    2024年02月15日
    浏览(42)
  • SpringMvc集成开源流量监控、限流、熔断降级、负载保护组件Sentinel

    前言:作者查阅了Sentinel官网、51CTO、CSDN、码农家园、博客园等很多技术文章都没有很准确的springmvc集成Sentinel的示例,因此整理了本文,主要介绍SpringMvc集成Sentinel 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的

    2024年02月05日
    浏览(63)
  • 【架构详细解读】缓存、限流、降级和熔断、负载均衡、灾备和故障转移——

    目录  架构基础 # 如何理解架构的演进? # 如何理解架构的服务化趋势? # 架构中有哪些技术点?   缓存 # 谈谈架构中的缓存应用? # 在开发中缓存具体如何实现? # 使用缓存的经验?  限流 # 什么是限流?三种限流的算法? # 限流令牌桶和漏桶对比? # 在单机情况下如何

    2024年01月16日
    浏览(46)
  • 熔断降级与限流在开源SpringBoot/SpringCloud微服务框架的最佳实践

    前期内容导读: Java开源RSA/AES/SHA1/PGP/SM2/SM3/SM4加密算法介绍 Java开源AES/SM4/3DES对称加密算法介绍及其实现 Java开源AES/SM4/3DES对称加密算法的验证说明 Java开源RSA/SM2非对称加密算法对比介绍 Java开源RSA非对称加密算法实现 Java开源SM2非对称加密算法实现 Java开源接口微服务代码框架

    2024年02月12日
    浏览(52)
  • 商城-学习整理-高级-商城业务-Sentinel&限流&熔断&降级&Sleuth+Zipkin链路追踪(二十二)

    什么是熔断 A 服务调用 B 服务的某个功能,由于网络不稳定问题,或者 B 服务卡机,导致功能时间超长。如果这样子的次数太多。我们就可以直接将 B 断路了(A 不再请求 B 接口),凡是调用 B 的直接返回降级数据,不必等待 B 的超长执行。 这样 B 的故障问题,就不会级联影

    2024年02月11日
    浏览(46)
  • 聊一聊服务治理三板斧:限流、熔断、降级和go-sentinel的实现

    我们知道,对于一个项目之初,我们不可能上来就按几千的并发去配置,为什么?两个方面,第一个是成本高。第二个是维护难度大。即便是天猫淘宝这种,也是采用的动态扩容的方式来应对双十一。那么一个项目如何应对突然的高并发,我们有哪些常用的措施和处理呢?我

    2024年01月19日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包