超时、断路器、重试、限流与降级是保障微服务可靠性的核心模式，通过合理配置可防止故障扩散、提升系统容错能力；这些模式常组合应用于服务治理框架（如Spring Cloud、Istio），并需配合监控告警实现可观测性，确保及时发现问题并动态调整策略。
微服务架构中，服务可靠性是保障系统稳定运行的关键。由于服务之间通过网络通信，故障传播快、影响范围广，因此需要引入一系列可靠性模式来增强系统的容错能力。以下是几种常见的服务可靠性模式：
超时（Timeout）
防止调用方在等待响应时无限期阻塞。为每个远程调用设置合理的超时时间，一旦超过该时间就终止请求并返回错误或降级处理。
- 避免线程池耗尽和资源堆积
- 需根据依赖服务的正常响应时间设定合理阈值
- 可结合重试机制使用，但要注意叠加延迟风险
断路器（Circuit Breaker）
当某个服务持续失败达到一定阈值时，自动切断对该服务的调用，防止雪崩效应。一段时间后尝试半开状态探测服务是否恢复。
- 典型实现如 Hystrix、Resilience4j
- 三种状态：关闭（正常）、打开（熔断）、半开（试探）
- 适用于高依赖、易出错的远程调用场景
重试机制（Retry）
对临时性故障（如网络抖动、瞬时超载）进行自动重试，提升请求成功率。
- 应限制重试次数，避免加剧系统压力
- 建议使用指数退避策略控制重试间隔
- 仅适用于幂等操作，避免重复提交造成数据问题
限流（Rate Limiting）与降级（Fallback）
限流用于控制单位时间内允许的请求数量，防止系统被突发流量压垮；降级则是在服务不可用或响应慢时提供简化逻辑或默认结果。
- 限流可基于令牌桶、漏桶算法实现
- 降级常用于非核心功能，比如返回缓存数据或静态提示
- 两者常配合使用，在高峰时段主动牺牲部分体验保核心链路
基本上就这些。这些模式往往不是孤立使用的，而是组合集成在服务治理框架中，比如通过 Spring Cloud、Istio 或 Service Mesh 来统一实施。关键在于根据业务场景权衡可用性与一致性，提前设计好故障应对路径。不复杂但容易忽略的是监控和告警——所有可靠性模式都应有可观测性支撑，才能及时发现问题并调整策略。
