使用断路器、超时重试、降级和资源隔离等机制提升微服务稳定性，防止故障扩散。
微服务架构中，服务间依赖复杂，网络波动、服务宕机等问题难以避免。容错处理的核心目标是提升系统的稳定性和可用性，防止故障在服务链路中扩散。以下是经过验证的容错处理最佳实践。
使用断路器模式防止级联失败
当某个下游服务响应缓慢或频繁失败时，持续重试会拖垮上游服务资源，导致雪崩效应。断路器能及时中断对故障服务的调用。
- 采用如 Hystrix（已停更）或 Resilience4j 等库实现断路器逻辑
- 设置合理阈值：例如连续 5 次失败后触发断路，进入“打开”状态
- 断路期间快速失败或返回兜底数据，避免线程阻塞
- 定时进入“半开”状态试探服务是否恢复
合理配置超时与重试机制
默认无限制等待会耗尽连接池和线程资源。必须为每个远程调用设定边界。
- 根据服务 SLA 设置调用超时时间，例如 800ms 内必须响应
- 重试应谨慎：仅对幂等操作或可预期瞬时故障（如网络抖动）启用
- 使用指数退避策略，避免短时间内大量重试冲击故障服务
- 结合熔断状态决定是否允许重试，避免在断路时仍尝试调用
提供降级策略保障核心功能
在非关键服务不可用时，系统应能切换到简化流程或缓存数据，保证主干业务可用。
- 定义 fallback 方法返回默认值、本地缓存或简化逻辑
- 区分核心与非核心依赖，优先保障登录、下单等主流程
- 前端可配合展示“信息暂不可用”提示，而非页面崩溃
隔离资源避免相互影响
一个慢服务可能占用全部线程池，导致其他正常服务也无法处理请求。
- 通过线程池或信号量隔离不同依赖，例如为用户服务和订单服务分配独立资源
- 限制并发调用数，防止突发流量压垮下游
- 使用舱壁模式（Bulkhead）控制资源使用上限
基本上就这些。关键不是堆砌技术，而是理解服务间的依赖关系，针对性地设置保护机制。配合监控告警，能更快发现并定位问题。容错设计要平衡稳定性与用户体验，做到故障可容忍、影响可控制。不复杂但容易忽略。
