「AI投研邦」团体会员上线！75折解锁会员权益、PDF版研报、AI峰会....
06-18
近年来，谷歌、微软、阿里巴巴、腾讯等各大厂商都对可用性概念进行了提升。高可用性（HA）是指系统或服务在发生故障或异常情况时继续提供稳定可靠运行的能力。
在武侠世界中，“利器”通常指的是上乘、出众的兵器；武器对于战士的重要性不言而喻。拥有一把优秀的武器可以让战士在战斗中更加得心应手，更加强大。
。在分布式系统追求高可用的背景下，熔断、限流、降级这三个重要策略可以说是三大利器。
断路器：断路器是一种防止故障蔓延的策略。当服务失败或超时时，断路器会快速打开并失败，拒绝后续请求，避免请求堆积和资源耗尽。
断路器会暂时阻止服务并在一段时间后尝试恢复服务。保险丝的状态变化可用于监控系统健康状况并提供警报信息。
速率限制：速率限制是一种控制系统请求流量的策略。通过设置请求速率阈值，限制可以限制每个客户端或用户在特定时间段内可以发出的请求数量。
这可以防止过多的请求淹没系统，从而保护系统免受过载和压力冲击。限流可以平滑流量，避免突发流量对系统的影响。
降级（Fallback）：降级是在遇到特殊业务或异常情况时保持系统可用的策略。当服务不可用时，降级服务将替换部分基本功能或恢复至预设的默认值，以保证系统仍能提供有限的功能或服务；或者优先考虑某些事件场景（例如：双十一），将计算资源投入到面向业务的服务中，并降级边缘服务。
断路器 在分布式架构中，一个服务通常会与多个外部服务进行交互。这些外部服务可能是RPC接口、数据库、第三方API等。
例如，在支付过程中，您可能需要调用银联提供的API；而要查询某个产品的价格，可能需要查询营销活动。但除了自身的服务之外，依赖的外部服务的稳定性并不能得到绝对的保证。
当依赖的第三方服务变得不稳定时，例如第三方服务器过载，服务本身调用第三方服务的响应时间就会变长，甚至产生级联效应。这样一来，服务自身的线程可能会积压，最终可能会耗尽业务自身的线程池，导致服务本身不可用。
Circuit Breaker就是为了应对此类第三方服务的不稳定性而设计的。它可以帮助系统在出现问题时保持高可用性，防止故障进一步蔓延，同时在一段时间后重试恢复正常运行。
避免局部不稳定因素导致整个分布式系统出现雪崩。作为保护服务本身的一种手段，通常配置在客户端（调用方）。
断路器模式最初是由 Michael Nygard 在他的书《Release It!》 中推荐的。它可以防止应用程序重复尝试执行可能失败的操作，从而允许应用程序继续执行，而无需等待故障修复或浪费 CPU 周期来确定故障是否持续存在。
断路器模式还使应用程序能够检测故障是否已解决。如果问题似乎已解决，应用程序可以尝试调用该操作。
注：此设计也是 Fail-Fast 原则的典型应用。它强调，当遇到错误或异常时，系统应该尽早检测并迅速失败，而不是继续执行可能导致更严重后果的操作。
这一原则的目的是尽早发现问题并及时处理，避免故障进一步扩大，从而提高系统的稳定性和可靠性。熔断模式中最关键的设计在于熔断的三种状态： 关闭状态：来自应用程序的请求由 Proxy 操作。
代理维护最近失败次数的计数，如果对操作的调用不成功，则增加该计数。如果给定时间段内最近失败次数超过指定阈值，则 Proxy 将进入 Open 状态。
此时Proxy会启动一个超时定时器。当计时器达到阈值时，Proxy 将进入 Half-Open 状态。
（这里Proxy指的是Resilience4j、Sentinel、Hystrix等框架） Open状态：来自应用程序的请求立即失败，并向应用程序返回异常。半开放状态：应用程序允许有限数量的请求通过并调用操作。
如果这些请求成功，它将切换到 Closed 状态（故障计数器被重置），假设导致故障的故障已被修复。如果任何请求失败，则认为故障仍然存在，因此它会回退到 Open 状态并重新启动超时计时器，为系统提供更多时间从故障中恢复。
。很多开源框架都基于这三种状态设计了熔断器，例如：Resilience4j、Sentinel、Hystrix；实际使用时，推荐使用Sentinel和Resilience4j，因为Hystrix已经宣布不再维护。
附上一张网上广为流传的对照表。 1 开源框架只是断路器机制的代码实现。
更重要的是根据常见的业务实践来设计相关的熔断策略。以下是针对特定业务设计断路器时的一些常见注意事项： 如何处理断路器异常：第三方服务处于断路器 Open 状态时如何返回服务。
例如：使用默认值替换第三方服务返回的结果；返回异常页面，通知用户稍后重试；异常往往是多种多样的，也可以考虑针对不同的异常设置不同的处理方式。应记录详细日志：注意异常日志的记录，确保关键信息写入日志。
线上故障往往异常且多样；良好的日志格式/日志设计可以快速定位问题并按预期监控熔断策略。断路器状态的转变需要写详细，方便审查断路器策略。
是否需要诊断定时程序：当断路器处于Open状态时，考虑是否需要定时程序来测试第三方服务是否恢复并转换为Half-Open状态，以更灵活地恢复服务。熔断管理工具：由于异常情况多种多样，某些情况下熔断会被意外触发；此时管理员可以使用熔断工具来恢复相关状态并处理熔断策略的问题。
关注第三方服务的时间消耗：有时第三方服务可以正常返回但耗时较长，可能会导致自身服务超时；此时应进行相关的超时断路器处理，并注意这种隐藏的超时异常。速率限制：无论服务器硬件多么强大，有限的资源只能处理有限的请求。
如果简单理解Rate Limit的话，如果在限定时间内请求数量超过了服务的处理数量，新的请求就会被自动丢弃。传入请求以确保有限请求的高可用性。
结合日常例子进行类比，很容易理解。一家餐厅只有5张四人桌，最理想的情况是20人。
如果50个人进来点餐，那么大家就无法正常吃饭了。 。
因此，有必要限制进入的人数，保证正常就餐。同样，对于系统来说，一次性接受超过硬件所能承载的资源，会导致资源的激烈竞争，导致请求服务的延迟、异常等，无法提供高可用的服务。
因此，对服务进行限流保护是提供高可用性的重要策略。以下是常见的限流算法： 固定窗口计数器限流算法（Fixed Window Counter）：限制固定时间窗口内的请求数量。
例如，1秒内最多允许处理10个请求，当窗口满时，后续请求将被拒绝。滑动窗口计数器算法：设置一个滑动时间窗口，计算时间窗口内的请求数量，并将其限制在指定范围内。
与固定窗口计数算法相比，滑动窗口算法可以实现更灵活的流量控制。令牌桶：令牌桶算法通过将请求放入令牌桶来控制流量。
每个请求都需要从令牌桶中获取令牌。如果桶中没有足够的令牌，则请求将被拒绝。
令牌桶算法可以对突发流量进行一定程度的处理，平滑请求的速率。令牌桶是一个固定容量的桶，它以恒定的速率（即令牌生成速率）生成令牌并将其放入桶中。
一个桶中可以存放的最大令牌数就是该桶的容量。当桶满时，多余的令牌将被丢弃。
每当请求到达时，如果令牌桶中有足够的令牌，则该请求将获得令牌并被处理。如果存储桶中没有可用的令牌，则请求将被延迟或丢弃。
令牌桶可以应用于固定窗口计数限流算法和滑动窗口计数限流算法。固定窗口计数限流时，令牌桶按照固定的速率生成令牌；滑动窗口计数限流时，令牌桶按照滑动时间窗口的速率生成令牌。
令牌桶算法的优点是可以平滑处理突发流量。即使短时间内有大量请求到达，令牌桶算法仍然可以保持相对稳定的速率来处理这些请求。
另外，令牌桶算法还可以允许一定程度的突发流量，因为桶中积累的令牌可以处理突发请求。令牌桶算法的缺点是在某些情况下可能会导致请求延迟。
如果请求到达时存储桶中没有足够的令牌，则请求将因等待令牌而延迟，从而可能导致响应时间增加。漏桶：漏桶算法将请求放入漏桶中，请求以恒定的速率从漏桶中流出。
如果漏桶已满，多余的请求将被拒绝。漏桶算法可以用来平滑流量，防止突发请求造成的资源浪费。
漏桶是具有泄漏开口的固定容量的桶。桶底部的泄漏会以固定速率（即生成代币的速率）漏水。
每个请求都会向漏桶添加一个令牌。如果漏桶已满（即桶内的令牌数量达到最大容量），新的令牌将被丢弃。
当请求到达时，如果漏桶中有可用的令牌，则处理该请求，并将漏桶中的令牌数量减一。如果漏桶中没有足够的令牌，则请求将被丢弃或延迟。
漏桶算法的优点是能够以固定的速率处理请求，从而平滑流量，防止突然的请求对系统造成过大的压力。另外，漏桶算法还可以控制流出速率，避免资源浪费；但漏桶算法的缺点是处理突发流量的能力比较差。
如果漏桶中的令牌数量耗尽，突发流量的请求将被丢弃，这可能会导致某些请求的延迟。 Fallback（后备） 不知道大家有没有经验。
在楼下沙县店吃面的时候，如果店里人不多，店员会给我们端上一盘小菜；但是如果人多的话，如果你想吃小菜，你可以到窗口去用蝴蝶装置去拿。从另一个角度来看，这其实可以称为服务降级。
服务降级往往是指面对系统过载、资源不足、有计划的大型活动（双十一）等情况，有意识地降低系统的部分功能或服务质量，以保证系统的核心功能和关键服务能够持续运行。运行正常。
例如，支持商家调整商品价格是电子商务系统中非常常见的功能。不过，双十一深夜期间，商家往往会达成协议，在深夜后的一段时间内不再对商品进行调价。
用服务来保证零点活动的高效执行。所以降级是一种非常规的应对措施，不应该是一个长期的解决方案。
一旦情况发生变化，应恢复降级的服务，确保系统能够正常提供所有功能和服务。降级本身的实现是根据具体的业务规则进行编码的。
常见的设计有： 交换机硬编码：通过参数来标识是否降级，通过服务中的if来确定标识，执行降级相关服务的业务逻辑。如果需要在短时间内降级，这可能是最直接、最常见的选择。
AOP拦截：通过AOP切面编程拦截服务请求，并根据业务需求调用降级服务请求进行服务降级。由于采用了AOP切面技术，对代码的侵入性较小，但代码的可读性较差；如果没有一些评论，不熟悉相关业务的开发者会忽略降级拦截。
策略/工厂设计模式：在设计服务时使用工厂或策略设计模式，根据降级的业务需求生成策略/工厂的具体服务，从而实现服务降级逻辑。代码逻辑实现会比较复杂，可能会带来更多的类，可读性对于不熟悉设计模式的开发人员来说会造成混乱。
三人的关系就写到这里了。有些读者可能会感到困惑，比如：降级和熔断是同一个东西吗？熔断后执行政策是否等于降级？要深入探讨这些问题本身，我们还是要回到文章开头的三大策略来提出我们面临和解决的高可用问题。
熔断是为了防止故障蔓延而进行的策略设计，而降级是针对特殊场景下服务功能/质量的调整策略。因此可以看出，降级说明中提到的双十一午夜前关闭商户调价的功能显然不是为了防止故障蔓延的措施，而是为了保证其他以业务为中心的功能的性能（不是断路器、主动改变）；同样，还可以举个例子：当调用某个服务失败时，切换到备份服务器作为断路器的处理策略。
此时，所提供的服务功能可能不会发生变化，但会启动断路器（不属于该服务）的技术处理策略。降级）。
两者不是一回事。但如果考虑到当出现熔断时，应对的方式是调整某些产品功能和服务，其实可以看作是熔断或者降级，所以有些文章也提到了熔断的概念降级。
限流降级呢？熔断和限流怎么样？这里我就不详细说了。总之，三者不是一回事，但在某些场景下是相互支持的。
熔断、限流、降级的概念更多的是对分布式系统高可用设计中应该考虑的方面的指导。它们的核心目的是实现系统的高可用性。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-06
06-18
06-17
06-18
06-21
06-21
06-06
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用