hyperf 3.0 集成 sentinel 实现熔断降级，核心是明确调用方为熔断主体、按异常比例（如60秒内失败率≥50%且请求数≥5）触发熔断、并为每个资源定制同步或异步降级逻辑，同时需手动完成资源定义、规则加载、监控上报及协程安全的 exit 释放。
Hyperf 3.0 集成 Sentinel 实现接口异常触发的熔断降级，核心在于：明确“谁来熔断”“依据什么熔断”“熔断后怎么降级”，且需适配 Hyperf 的协程与 DI 特性。Sentinel 官方未原生支持 Hyperf，但可通过 sentinel-php（社区维护）或轻量封装 Sentinel Java 控制台 + HTTP 规则下发 方式落地，生产环境推荐后者以保障稳定性与可观测性。
一、确认熔断主体：是调用方还是被调用方？
服务熔断本质是调用方主动保护自身。例如：
- Hyperf 服务 A 调用外部 HTTP 接口 B，B 响应异常率高 → A 应对 B 的调用做熔断；
- Hyperf 服务 A 提供 /api/order 接口，被其他服务调用 → 熔断规则应由调用方配置，A 本身只需提供降级响应逻辑（如返回默认订单数据）；
- 若想在 A 内部对自身某个耗时方法做保护，需手动定义资源并埋点，而非依赖自动 URL 资源。
二、配置异常比例熔断策略（最常用）
针对接口异常（如 HTTP 5xx、远程调用抛出 Exception、超时等），使用 Error Ratio 策略：
- 统计窗口：建议设为 60 秒（避免抖动误判）；
- 异常比例阈值：0.5（即 50% 请求失败就熔断）；
- 最小请求数：必须 ≥5（防止低流量下偶然失败就触发）；
- 熔断持续时间：60 秒（Open 状态时长）；
- 半开探测：60 秒后允许 1 个请求试探，成功则恢复，失败则重置计时器。
⚠️ 注意：Hyperf 中需确保异常被 Sentinel 正确捕获 —— 所有被保护的调用必须包裹在 SphU.entry() 或使用 @SentinelResource 注解（需自行适配注解解析器）。
三、实现降级逻辑（Fallback）
熔断触发后不能直接报错，要返回兜底数据。在 Hyperf 中推荐两种方式：
-
同步降级：在
try-catch(BlockException)中构造响应，例如：return $this->response->success(['code' => 200, 'data' => ['order_id' => 'fallback_'.uniqid()] ])； -
异步降级（适合 Feign 类调用）：在客户端调用失败回调中执行降级，例如使用
GuzzleHttp\Exception\RequestException捕获后返回缓存或默认值； - 不建议全局统一 fallback handler，应按资源粒度定制，比如支付失败返回“支付暂不可用”，查询失败返回“暂无数据”。
四、Hyperf 适配关键点
不同于 Spring Cloud Alibaba，Hyperf 需手动完成以下集成：
-
资源定义：对每个需保护的 HTTP 接口或客户端方法，显式调用
SphU.entry("resource_name")，资源名建议含服务+接口标识，如"user-service-getUserInfo"； -
规则加载：通过 Sentinel 控制台配置规则，或在启动时调用
DegradeRuleManager.loadRules()加载本地规则； -
监控上报：启用
sentinel-dashboard，Hyperf 进程需定时向控制台推送 metrics（可基于crontab或Timer::tick实现）； -
协程安全：确保
Entry对象在协程内正确exit()，避免资源泄漏 —— 建议配合defer或finally块释放。
