外观
一句话答案
→ 每个被调用的服务分配独立线程池
核心要点
| 维度 | Sentinel | Resilience4j | Hystrix |
|---|---|---|---|
| 维护状态 | 阿里巴巴活跃维护 | 社区活跃维护 | Netflix 已停止维护（2018） |
| 隔离策略 | 信号量隔离（基于并发数） | 信号量隔离 | 线程池隔离 + 信号量隔离 |
| 熔断策略 | 慢调用比例 / 异常比例 / 异常数 | 基于失败率 / 慢调用率 | 基于失败率 |
| 限流 | 内置（QPS、并发数、关联限流） | 内置（Rate Limiter） | 不支持（需自行实现） |
| 流量整形 | 支持（匀速排队、预热） | 不支持 | 不支持 |
| 热点参数 | 支持（按参数限流） | 不支持 | 不支持 |
| 系统自适应 | 支持（CPU/Load 自适应限流） | 不支持 | 不支持 |
| Dashboard | 自带控制台（实时监控 + 动态规则） | 无（需搭配 Prometheus + Grafana） | Hystrix Dashboard + Turbine |
| 规则持久化 | 支持（Nacos / Apollo / ZK） | 需自行实现 | 配置文件 |
| 编程模型 | 注解 + API + Dashboard 动态配置 | 函数式编程（装饰器模式） | 注解 + HystrixCommand |
| 设计理念 | 面向流量治理的完整方案 | 轻量级弹性库 | 熔断 + 隔离 |
| 性能开销 | 低（滑动窗口，无线程池切换） | 极低（纯函数式） | 较高（线程池隔离有上下文切换开销） |
| Spring Cloud 集成 | Spring Cloud Alibaba | Spring Cloud Circuit Breaker | Spring Cloud Netflix（已废弃） |
隔离策略对比详解：
Hystrix 线程池隔离：
→ 每个被调用的服务分配独立线程池
→ 优点：完全隔离，一个服务慢不会影响其他服务的线程
→ 缺点：线程池数量多 → 上下文切换开销大 → CPU 消耗高
→ 缺点：线程池大小难以合理设定
Sentinel / Resilience4j 信号量隔离：
→ 使用信号量（计数器）限制并发数
→ 优点：轻量级，无线程切换开销
→ 缺点：不能完全隔离慢调用（慢调用仍会占用调用方线程）
→ 适合：大部分微服务场景（结合熔断一起使用）选型建议：
Spring Cloud Alibaba 技术栈 → Sentinel（功能最全面，Dashboard 强大）
Spring Boot 原生 / 轻量级需求 → Resilience4j（轻量、函数式、无外部依赖）
老项目迁移 → 从 Hystrix 迁移到 Sentinel 或 Resilience4j追问与易错
追问方向：
- Sentinel 和 Hystrix 区别？
- 滑动窗口怎么实现？
- 规则怎么持久化？
易错点：
- ❌ Sentinel 只能限流——还支持熔断和系统保护
- ❌ 规则配在代码里——应推送到配置中心
💡 记忆锚点
三代熔断限流框架演进：Hystrix(已停更,线程池隔离重但隔离好) -> Sentinel(阿里出品,滑动窗口+信号量轻量,功能最全:限流+熔断+热点+系统保护+Dashboard) -> Resilience4j(函数式极轻量,无Dashboard)。Spring Cloud Alibaba生态选Sentinel，轻量级选Resilience4j。