高可用的三大利器是熔断、限流和降级。它们都是在分布式系统中用于保障系统稳定性和可用性的重要策略。

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

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

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

本篇主要介绍熔断相关内容。

熔断（Circuit Breaker Pattern）

在现代分布式架构中，一个服务通常会与多个外部服务进行交互，这些外部服务可能是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已经宣布不维护了.

附上，一张网上广泛流传的对比表格 [1]

熔断要考虑的问题

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

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

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

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

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

参考文献

1. sentinel 限流熔断神器详细介绍 https://blog.csdn.net/a745233700/article/details/122733366
2. Release It! Second Edition https://pragprog.com/titles/mnee2/release-it-second-edition/