Sentinel 和 Hystrix 有什么区别？它们分别解决什么问题？
简化版
Hystrix 和 Sentinel 都是服务治理组件，用来处理熔断、降级、隔离等稳定性问题。Hystrix 更早，核心是线程池/信号量隔离、熔断和 fallback，但已停止维护。Sentinel 是阿里开源组件，除了熔断降级，还强调流量控制、系统自适应保护、热点参数限流、实时监控和动态规则，和 Spring Cloud Alibaba 生态结合更紧密。现在 Java 微服务里更常见 Sentinel。
详细版
Hystrix 的设计重点是隔离和熔断。它通过命令模式包装远程调用，可以为不同依赖配置线程池隔离或信号量隔离；当错误率超过阈值时熔断，直接走 fallback，避免故障扩散。
Sentinel 的核心抽象是资源和规则。任何接口、方法、URL 都可以定义为资源，再配置流控规则、熔断规则、热点参数规则、系统保护规则和授权规则。Sentinel 支持控制台动态配置和实时监控，流控维度更丰富。
区别可以从维护状态、功能范围、隔离方式、规则动态性、生态集成来讲。Hystrix 偏调用隔离，Sentinel 偏流量治理和运行时规则控制。
完整版教学
一、二者共同解决的问题
微服务系统中，一个服务会调用很多下游依赖。下游变慢、错误率升高或流量突增时，如果没有治理，调用方可能被拖垮。Hystrix 和 Sentinel 都是为了解决这类稳定性问题：快速失败、熔断降级、资源保护、避免雪崩。
它们都不是业务框架，而是保护框架。业务代码仍然要决定 fallback 返回什么、哪些接口能降级、哪些接口必须失败。治理组件提供的是机制，不替业务承担语义。
二、Hystrix 的特点
Hystrix 来自 Netflix 早期微服务实践，典型用法是把一次远程调用包装成 HystrixCommand。它支持线程池隔离和信号量隔离。线程池隔离能把不同依赖放到不同线程池，某个依赖慢了不会占满主业务线程；信号量隔离开销更低，但隔离强度弱一些。
Hystrix 还支持熔断、fallback、请求缓存、请求合并和指标监控。它的强项是依赖调用隔离和故障兜底。不过 Hystrix 已经停止维护，新的项目通常不会优先选它。
三、Sentinel 的特点
Sentinel 更强调流量治理。它把需要保护的对象称为资源，比如一个接口、一个方法、一个服务调用。围绕资源可以配置流控规则、熔断降级规则、热点参数限流、系统自适应保护、黑白名单授权等。
Sentinel 的优势是规则动态化和可观测性。通过控制台可以实时看到 QPS、通过量、拒绝量、响应时间等，也能动态调整规则。它在流量控制方面比 Hystrix 更丰富，比如按 QPS、并发线程数、调用关系、热点参数做控制。
四、关键区别怎么比较
第一，维护状态不同。Hystrix 已停止维护，Sentinel 仍在国内 Java 微服务生态中广泛使用。第二，功能重心不同。Hystrix 重在隔离、熔断和 fallback；Sentinel 重在流控、熔断、热点参数和系统保护。第三，隔离模型不同。Hystrix 强调线程池隔离，Sentinel 主要通过并发线程数、流控规则和熔断规则保护资源，不以线程池隔离为核心。
第四，规则管理不同。Hystrix 配置相对偏静态，Sentinel 更强调动态规则和控制台。第五，生态不同。Hystrix 常见于早期 Spring Cloud Netflix，Sentinel 常见于 Spring Cloud Alibaba。
五、如何选择
新项目如果在 Java 和 Spring Cloud Alibaba 生态里，通常优先考虑 Sentinel。它对限流、热点参数、动态规则和监控支持更适合现代治理需求。如果维护老系统，仍可能遇到 Hystrix，需要理解它的线程池隔离和熔断模型。
但选择组件不是只看名字。更重要的是治理策略：哪些资源要保护，阈值怎么定，fallback 是否正确，规则如何发布，误限流如何处理，监控和告警是否完整。组件只是载体。
六、面试追问与工程边界
常见追问是 Sentinel 能不能替代所有稳定性设计。不能。它能做限流、熔断、降级规则，但超时、重试、幂等、容量规划、压测、灰度发布、监控告警仍然需要独立设计。稳定性是体系，不是装一个组件。
另一个追问是线程池隔离和信号量隔离区别。线程池隔离隔离性强，一个依赖慢不会占用主线程，但线程切换和资源成本高；信号量隔离轻量，适合低延迟调用，但慢调用仍可能占用业务线程。Hystrix 面试里这个点很常见。
七、落地设计清单
如果面试官问到实际选型，可以从现状出发。新系统在 Spring Cloud Alibaba 生态中，Sentinel 更适合做运行时流控、熔断降级、热点参数限流和动态规则管理。老系统如果已经使用 Hystrix，就要重点维护线程池隔离、fallback 正确性和监控迁移。不要只回答“Hystrix 停更，Sentinel 更新”，还要说明功能重心变化。
使用 Sentinel 时，第一步是定义资源，不能只把所有流量归到一个大资源。URL、方法、下游依赖、热点参数都可以是资源。第二步是配置规则，如 QPS 流控、并发线程数、慢调用比例熔断、异常比例熔断、热点参数限流。第三步是验证 fallback 和 BlockException 处理，确保限流或熔断时用户得到可接受的响应。
八、常见误区和组件边界
第一个误区是装了 Sentinel 就等于高可用。Sentinel 解决的是流量治理和熔断降级，但它不替代容量规划、压测、超时、重试、幂等、灰度、监控和业务降级预案。稳定性是体系工程，组件只是执行规则的工具。
第二个误区是忽略隔离差异。Hystrix 的线程池隔离能把慢依赖从线程层面隔开，但成本较高；Sentinel 更偏规则控制和并发保护，不是同样的线程池模型。如果系统强依赖线程池隔离，迁移时要重新评估资源隔离方案，不能简单替换包名。
九、常见误区与追问
这道题不能只背概念，要把「Sentinel 与 Hystrix 对比」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | Hystrix 偏线程隔离和熔断，已停止维护；Sentinel 覆盖流控、熔断、热点参数和控制台，国内生态更活跃 | 不要停在名词解释 |
| 流程机制 | 定义保护资源 -> 配置限流或熔断规则 -> 运行时统计指标 -> 触发限流熔断降级 -> 控制台观察和调整规则 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 热点参数限流如按商品 ID 保护 sku=1001，Sentinel 支持更直接，Hystrix 原生能力较弱 | 治理组件是为了控制故障半径，不是让下游无限扛流量 |
Sentinel 与 Hystrix 对比 面试拆解：
1. 定义保护资源
2. 配置限流或熔断规则
3. 运行时统计指标
4. 触发限流熔断降级
5. 控制台观察和调整规则记忆钩子：先定位治理目标，再拆限流、熔断、降级、重试、追踪、灰度和幂等边界；回答时要紧扣「Sentinel 与 Hystrix 对比」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：Sentinel 只是 Hystrix 的替代品。 Sentinel 更强调流量控制、热点参数、系统自适应保护和动态规则。
- 误区：Hystrix 还能作为新项目首选。 Hystrix 已停止维护，新项目通常不建议优先选择。
- 误区：线程隔离一定比信号量隔离好。 线程隔离更强但成本高，信号量轻量但隔离弱。
- 追问：Sentinel 核心能力有哪些？ 流控、熔断降级、热点参数、系统保护、实时监控和规则推送。
- 追问：Hystrix 的核心模型是什么？ Command 包装调用，配合线程池/信号量隔离、熔断和 fallback。
- 追问：如何选型？ Spring Cloud Alibaba 体系优先 Sentinel，老 Netflix 体系可能维护 Hystrix 存量。
十、加强记忆
Hystrix 偏“依赖隔离 + 熔断 fallback”，Sentinel 偏“流量控制 + 熔断降级 + 动态规则”。Hystrix 是早期 Netflix 体系且已停止维护，Sentinel 在 Spring Cloud Alibaba 生态更常用。回答时按共同目标、功能重心、隔离方式、动态规则、生态维护状态来比较。