Java 服务调用下游接口注意点

目录1. 必须设置超时2. 重试策略不能无脑重试3. 熔断、降级、隔离4. 限流5. 异常处理区分不同失败类型6. 请求参数与响应处理7. 线程池注意8. 超时时间的设计链路整体考虑9. 资源与连接池HTTP 客户端10. 业务层面幂等、数据一致性11. 监控告警面试口述版本高频追问1. 必须设置超时重中之重第一优先级问题不设置超时线程会无限阻塞等待下游返回线程池线程被占住不释放最终线程池打满、队列积压整个服务雪崩。这是线上最常见故障实践不管是 RestTemplate、OkHttp、HttpClient、Dubbo必须配置连接超时、读取超时。connectTimeout建立网络连接超时readTimeout接口响应读取超时业务接口 RT 上限示例普通业务接口connect 2sread 3‑5s大文件导出类接口 read 适当放大。超时不是越大越好下游慢我们及时失败释放线程保护自己。面试一句话调用下游一定要设置超时防止线程无限阻塞耗尽线程池。2. 重试策略不能无脑重试什么场景可以重试幂等接口查询接口。不能重试非幂等写接口下单、扣款重试会重复创建订单、重复扣款。重试注意点只对特定异常重试网络异常、连接超时业务返回业务异常不要重试。比如下游返回参数错误再重试多少次都失败。一定要加退避策略间隔时间不要立刻疯狂重试避免把下游打垮。设置最大重试次数不能无限重试。重试带来的负载要算到下游 QPS 评估。Spring Retry / Resilience4j / Dubbo 自带重试都可以实现。金融系统写接口优先关闭自动重试。3. 熔断、降级、隔离Resilience4j/Sentinel下游故障不能把故障传导到本服务。熔断 CircuitBreaker下游大量失败打开熔断直接本地快速失败不去调用下游保护自己也保护下游。舱壁隔离 Bulkhead调用下游的请求单独隔离线程池下游慢只占隔离池不会占用业务核心线程池不会影响别的业务。很多人忽略如果不做舱壁下游全部卡死自己业务线程池全部占满其他无关接口全部挂掉。汇丰金融项目很看重故障隔离不能一个第三方挂掉把整个服务拖垮。4. 限流对下游做限流控制发给下游最大 QPS防止我方流量打垮下游。自己服务入口也要限流防止外部流量进来大量调用下游把下游打崩。5. 异常处理区分不同失败类型调用下游会出现多种失败分开处理不要一把全部 catch (Exception) 笼统处理网络异常连接失败、超时、socket 异常HTTP 状态码4xx客户端错误参数错、5xx下游服务报错业务码http200但是 body 里面业务 code 代表业务失败返回体解析异常返回 JSON 格式不对解析报错实践打印完整日志请求参数、响应体、耗时、traceId方便排查不要吞异常需要告警区分是我方参数错误还是下游故障。坑只判断 http 状态码 200 就认为成功忽略业务 code。6. 请求参数与响应处理请求体过大注意序列化避免大对象序列化耗 CPU做好响应解析保护不要直接强转防止返回格式变更导致解析异常大返回体注意内存溢出风险传递链路 traceId方便全链路追踪。7. 线程池注意和前面线程池知识点联动高频考点调用下游 IO 操作会阻塞当前线程。两种情况在同步接口里面调用下游占用 web 容器线程Tomcat 线程下游慢会耗尽 tomcat 线程接口全部卡死。在自定义异步线程池调用下游占业务线程池线程如果没有超时线程池耗尽。最佳实践调用下游必须设置超时如果大量调用第三方建议用单独隔离的线程池舱壁第三方故障不会污染核心业务线程池。8. 超时时间的设计链路整体考虑链路总耗时 多个下游调用时间总和。例如网关整体超时 10s内部服务调用下游每个接口不能设置 8s多个调用叠加直接超时。每个下游接口超时要小于整体链路超时。9. 资源与连接池HTTP 客户端OkHttp、HttpClient 一定要配置连接池复用 TCP 连接不要每次请求新建连接。设置最大连接数避免创建大量 TCP 连接出现 too many open files。10. 业务层面幂等、数据一致性调用写接口下游要支持幂等传入唯一业务 id防止重试造成重复数据调用失败要考虑回滚、补偿、本地记录调用日志后续定时任务重试补偿金融场景不能简单调用失败就直接丢弃要落地本地记录异步补偿。11. 监控告警需要监控这些指标下游调用 QPS调用耗时 p50/p95/p99失败率超时、5xx、业务异常熔断状态失败率到达阈值要告警不要等到业务报错才发现第三方挂了。面试口述版本B5 级别可以直接复述调用下游接口首先必须设置连接超时、读取超时防止下游响应慢把我方线程无限阻塞耗尽线程池或者 Tomcat 线程造成服务雪崩。然后是重试查询类接口可以重试写接口不能随便重试需要下游支持幂等重试要加退避限制最大次数。我们会使用 Sentinel 或者 Resilience4j 做熔断和舱壁隔离把对下游的调用隔离在独立线程池下游故障不会扩散到核心业务。做好异常分类处理区分网络异常、HTTP 状态码、业务错误码打印完整请求响应日志带上 traceId 方便排查。HTTP 客户端要使用连接池复用 TCP 连接。同时评估整体链路超时单个下游超时不能超过链路总时间。金融写场景调用失败不能直接丢弃落库做补偿对下游调用做监控监控耗时、失败率配置告警。高频追问Q调用下游没设置超时会发生什么线程会一直阻塞等待响应线程不会释放。同步接口会耗尽 Tomcat 容器线程异步任务会耗尽业务线程池。最终整个服务无法处理新请求雪崩。Q熔断和舱壁的区别熔断统计失败率失败多了直接拒绝发起调用保护下游和自己。舱壁 Bulkhead线程池隔离限制调用该下游最多占用多少线程。哪怕下游全部卡死最多耗尽隔离池的线程不影响其他业务。两个组件配合使用。Q为什么写接口不能随便重试如果接口非幂等重试会造成重复下单、重复扣款等脏数据如果要重试下游必须支持幂等传入唯一业务标识。