Hystrix通过统计失败率、超时、拒绝等指标间接判断服务健康，异常仅作为失败信号；熔断器依据请求量阈值和错误率自动切换OPEN/HALF_OPEN/CLOSED状态，而非直接识别异常类型。
Hystrix 本身不直接“识别异常类型”来判断服务健康，而是通过统计请求结果（成功、失败、超时、拒绝等）的比率和频次，间接反映服务健康状态。异常只是触发失败计数的信号之一，关键在失败是否持续、是否达到熔断阈值。
异常如何影响健康状态统计
Hystrix 将以下情况统一归类为“失败（failure）”，计入熔断器的失败计数器：
- 远程调用抛出未被捕获的受检/非受检异常（如 IOException、TimeoutException、RuntimeException）
- 命令执行超时（
execution.isolation.thread.timeoutInMilliseconds超过） - 线程池或信号量满载导致请求被拒绝（
REJECTED_THREAD_EXECUTION或REJECTED_SEMAPHORE_EXECUTION） - fallback 方法自身也抛出异常（此时视为降级失败，仍算作整体失败）
只要单次执行落入以上任一情形，Hystrix 就会标记该请求为失败，并更新 Metrics（如失败率、10秒内失败数）。这些指标才是健康状态的依据，不是异常堆栈本身。
真正决定健康状态的是熔断器开关逻辑
健康状态最终体现为熔断器的开关状态（OPEN / HALF_OPEN / CLOSED），它由以下规则驱动：
- 当单位时间（默认10秒）内失败请求数 ≥
circuitBreaker.requestVolumeThreshold（默认20），且失败率 ≥circuitBreaker.errorThresholdPercentage（默认50%），则熔断器跳闸为 OPEN - 进入 OPEN 状态后，所有请求直接走 fallback，不再发起真实调用
- 等待
circuitBreaker.sleepWindowInMilliseconds（默认5000ms）后，自动转为 HALF_OPEN，放行少量试探请求 - 若试探请求成功，恢复为 CLOSED；若继续失败，则重置为 OPEN
也就是说，异常只是“输入信号”，健康状态是熔断器根据统计规律自主决策的结果，不是人工配置某种异常就立刻判定不健康。
如何让异常更合理地参与健康评估
避免无关异常干扰健康判断，可做针对性处理：
-
区分业务异常与系统异常：对明确的业务失败（如用户不存在、参数校验不通过），不应计入 Hystrix 失败统计。可在
run()中捕获并返回正常结果，或使用@HystrixCommand(ignoreExceptions = {UserNotFoundException.class}) -
显式控制超时异常权重：超时（
TimeoutException）默认计入失败。若某接口天然慢但稳定，可适当调大execution.isolation.thread.timeoutInMilliseconds，避免误判 - 检查 fallback 是否可靠：如果 fallback 方法频繁抛异常，会导致“降级也失败”，加剧熔断器维持 OPEN 状态。应确保 fallback 是轻量、无外部依赖的兜底逻辑
-
结合 Actuator 暴露健康端点：启用
management.endpoint.health.show-details=always，访问/actuator/health可看到hystrix健康指示器，其状态取决于当前熔断器是否 OPEN —— 这才是对外暴露的“服务健康”结论
监控层面看健康状态更直观
单靠日志查异常效率低，应依赖实时指标：
- 访问
/actuator/hystrix.stream（需开启spring-boot-starter-actuator和 Hystrix 配置）获取原始流数据 - 接入 Turbine 聚合多个服务的 stream，再通过 Hystrix Dashboard 可视化查看：每个 command 的 Success %、Error %、Mean latency、QPS、Circuit state
- 重点关注 Error % 是否持续高于阈值、Circuit state 是否频繁跳变 —— 这比翻找某次
NullPointerException更能说明服务健康趋势
