合理配置超时是保障微服务稳定的关键，需明确连接、读取、请求及调用链超时场景；通过OpenFeign、OkHttp、Resilience4j等框架设置具体超时值；结合重试机制避免资源耗尽，并利用上下文传递全链路超时，确保服务契约一致。
微服务中的超时控制是保障系统稳定性和防止级联故障的关键措施。合理配置超时时间，能有效避免请求长时间挂起，释放资源并及时失败转移。
1. 明确各类超时场景
在微服务架构中，常见的超时包括：
- 连接超时（Connect Timeout）：建立网络连接的最大等待时间，通常设置为较短时间（如1-3秒），防止因目标服务不可达而长时间阻塞。
- 读取超时（Read Timeout）：连接建立后，等待响应数据的时间。根据业务复杂度可设为几秒到十几秒。
- 全局请求超时（Request Timeout）：从发起请求到收到响应的总耗时限制，包含重试时间。
- 下游服务调用链超时：多个服务串联调用时，整体链路的超时应小于上游服务的超时，避免“超时传递”。
2. 在常见框架中配置超时
不同技术栈提供各自的超时配置方式：
-
OpenFeign（Spring Cloud）：
在 application.yml 中配置： feign:
client:
config:
default:
connectTimeout: 3000
readTimeout: 6000 -
OkHttp / Retrofit：
通过 OkHttpClient.Builder 设置： new OkHttpClient.Builder()
.connectTimeout(3, TimeUnit.SECONDS)
.readTimeout(6, TimeUnit.SECONDS) -
Hystrix（已归档，但仍部分使用）：
配置 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 控制熔断超时。 -
Resilience4j：
使用 TimeLimiter 模块定义异步调用超时，可在配置文件中指定 duration。
3. 结合重试机制设计超时策略
超时不合理的重试会加剧系统压力。建议：
- 设置最大重试次数（如1-2次），且总重试时间不超过上游接口的超时限制。
- 使用指数退避策略，避免瞬时流量冲击。
- 对幂等性操作才启用重试。
4. 全链路超时传递与上下文控制
使用 OpenTracing 或 Spring WebFlux + Reactor Context 传递超时上下文。例如，在 Gateway 层设定请求最大存活时间，下游服务根据剩余时间决定是否处理或快速失败。
可通过 HTTP 头（如 Deadline 或 X-Request-Timeout）传递截止时间，各服务自行计算可用窗口。
基本上就这些。关键是根据业务容忍度设定合理阈值，并定期压测验证。超时不只是一组数字，而是服务契约的一部分。
