面试题：微服务架构下自研微服务熔断降级框架的设计思路

Question

在微服务架构中，阐述一下你设计自研微服务熔断降级框架时，会考虑哪些关键因素，以及如何设计其核心流程？

Answer 1

关键因素

1. 熔断策略：
   • 熔断触发条件：例如基于请求失败率，当失败请求数占总请求数的比例超过一定阈值（如 50%），或连续失败请求数达到一定数量（如 100 次），触发熔断。也可基于响应时间，平均响应时间超过设定值（如 200ms）持续一定时间触发熔断。
   • 熔断恢复策略：熔断后经过一定冷却时间（如 5 分钟），进入半熔断状态，允许少量请求试探调用，若成功则关闭熔断，若失败则继续熔断。
2. 降级策略：
   • 自动降级：当依赖服务资源紧张（如 CPU 使用率超过 80%、内存使用率超过 90%），或服务本身出现故障（如熔断后），自动执行降级逻辑。
   • 手动降级：提供管理接口，允许运维人员在监控到问题时手动触发降级，如在流量高峰时对非核心业务手动降级。
   • 降级逻辑：可返回默认值、缓存数据，或执行兜底逻辑（如记录日志后返回友好提示信息）。
3. 监控与统计：
   • 实时监控：收集每个微服务调用的请求数、成功数、失败数、响应时间等指标，实时展示在监控面板，便于及时发现问题。
   • 数据存储：将监控数据持久化存储，如使用 InfluxDB 等时间序列数据库，用于后续分析和复盘。
4. 扩展性：
   • 支持多种微服务框架：如 Spring Cloud、Dubbo 等，能够无缝集成到不同的微服务项目中。
   • 动态配置：支持通过配置中心（如 Apollo、Nacos）动态调整熔断和降级策略，无需重启服务。
5. 性能损耗：
   • 轻量级设计：框架自身的性能开销要小，对微服务的正常业务逻辑影响尽量低，例如采用异步处理监控数据统计等方式减少对主线程的阻塞。

核心流程设计

1. 请求拦截：
   • 在微服务的调用入口处（如过滤器、切面等）拦截请求，判断是否需要进行熔断和降级处理。
2. 熔断检查：
   • 查看当前服务是否处于熔断状态。若处于熔断状态，直接执行降级逻辑并返回。
   • 若未熔断，统计当前请求相关指标（如请求数、成功数、失败数等）。
3. 熔断判断：
   • 根据预设的熔断触发条件，判断是否达到熔断标准。若达到，则设置熔断状态，并记录熔断开始时间，同时执行降级逻辑并返回。
4. 正常调用：
   • 若未达到熔断标准，正常调用依赖的微服务。
5. 结果处理：
   • 若调用成功，更新成功指标。若调用失败，更新失败指标，并判断是否因失败导致达到熔断标准，若达到则触发熔断。
6. 熔断恢复：
   • 当达到熔断冷却时间后，进入半熔断状态。此时允许少量请求（如每次 10 个）试探调用依赖服务。
   • 若试探调用成功次数达到一定比例（如 80%），关闭熔断，恢复正常调用；若失败，则继续保持熔断状态。
7. 降级处理：
   • 执行预设的降级逻辑，如返回默认值、缓存数据或兜底逻辑，并记录降级相关日志。