HTTP调用既然是网络请求,就可能超时,超时错误分两种,connect timeout和read timeout,前者可能是网络问题,或者服务端连接池不够用了。后者是连接已经建立了,但是服务端太忙了,不能及时处理完你的请求。
因此在实际开发中都需要注意考虑这些超时的处理措施。
框架设置的默认超时时间是否合理?
网络不稳定性,超时后可以通过定时任务请求重试 这时,就要注意考虑服务端接口幂等性设计,即是否允许重试?
框架是否会像浏览器那样限制并发连接数,以免在高并发下,HTTP调用的并发数成为瓶颈!
虽然应用层是HTTP协议,但网络层始终是TCP/IP协议。TCP/IP是面向连接的协议,在传输数据之前需先建立连接。 网络框架都会提供如下超时相关参数:
比如60s。TCP三次握手正常建立连接所需时间很短,在ms级最多到s级,不可能需要十几、几十秒,多半是网络或防火墙配置问题。这时如果几秒还连不上,那么可能永远也连不上。所以设置特别长的连接超时无意义,1~5秒即可。 如果是纯内网调用,还可以设更短,在下游服务无法连接时,快速失败
服务一般会有多个节点,若别的客户端通过负载均衡连接服务端,那么客户端和服务端会直接建立连接,此时出现连接超时大概率是服务端问题 而若服务端通过Nginx反向代理来负载均衡,客户端连接的其实是Nginx,而非服务端,此时出现连接超时应排查Nginx
client接口内部通过HttpClient
调用服务端接口server,客户端读取超时2秒,服务端接口执行耗时5秒。
调用client接口后,查看日志:
SocketTimeoutException
,即读取超时Tomcat Web服务器是把服务端请求提交到线程池处理,只要服务端收到请求,网络层面的超时和断开便不会影响服务端的执行。因此,出现读取超时不能随意假设服务端的处理情况,需要根据业务状态考虑如何进行后续处理。
比如100ms。
发生读取超时,网络层面无法区分如下原因:
但TCP是连接建立完成后才传输数据,对于网络情况不是特差的服务调用,可认为:
HTTP请求一般需要获得结果,属同步调用。 若超时时间很长,在等待 Server 返回数据同时,Client 线程(通常为 Tomcat 线程)也在等待,当下游服务出现大量超时,程序可能也会受到拖累创建大量线程,最终崩溃。
评论可能会有人问了,若把读取超时设为2s,而服务端接口需3s,不就永远拿不到执行结果? 的确,因此设置读取超时要结合实际情况:
连接超时代表建立TCP连接的时间,读取超时代表了等待远端返回数据的时间,也包括远端程序处理的时间。在解决连接超时问题时,我们要搞清楚连的是谁;在遇到读取超时问题的时候,我们要综合考虑下游服务的服务标准和自己的服务标准,设置合适的读取超时时间。此外,在使用诸如Spring Cloud Feign等框架时务必确认,连接和读取超时参数的配置是否正确生效。
为Feign配置超时参数的难点在于,Feign自身有两个超时参数,它使用的负载均衡组件Ribbon本身还有相关配置。这些配置的优先级是啥呢?
在配置文件仅指定服务端地址的情况下:
clientsdk.ribbon.listOfServers=localhost:45678
得到如下输出:
[21:46:24.222] [http-nio-45678-exec-4] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController:26 ] -
执行耗时:222ms 错误:Connect to localhost:45679 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1]
failed: Connection refused (Connection refused) executing
POST http://clientsdk/feignandribbon/server
Feign默认读取超时是1秒,如此短的读取超时算是“坑”。
可以设置如下参数:
feign.client.config.default.readTimeout=3000
feign.client.config.default.connectTimeout=3000
修改配置后重试,得到如下日志:
[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] - 执行耗时:3006ms 错误:Read timed out executing POST http://clientsdk/feignandribbon/server
3秒读取超时生效。 注意:这里有一个大坑,如果希望只修改读取超时,可能会只配置这么一行:
feign.client.config.default.readTimeout=3000
测试会发现,这样配置无法生效。
查看FeignClientFactoryBean
源码
ConnectTimeout
、ReadTimeout
,Request.Options才会被覆盖
想针对单独的Feign Client设置超时时间,可以把default替换为Client的name:
feign.client.config.default.readTimeout=3000
feign.client.config.default.connectTimeout=3000
feign.client.config.clientsdk.readTimeout=2000
feign.client.config.clientsdk.connectTimeout=2000
[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] -
执行耗时:2006ms 错误:Read timed out executing
POST http://clientsdk/feignandribbon/server
参数首字母要大写,和Feign的配置不同。
ribbon.ReadTimeout=4000
ribbon.ConnectTimeout=4000
可以通过日志证明参数生效:
[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] -
执行耗时:4003ms 错误:Read timed out executing
POST http://clientsdk/feignandribbon/server
谁会生效?
clientsdk.ribbon.listOfServers=localhost:45678
feign.client.config.default.readTimeout=3000
feign.client.config.default.connectTimeout=3000
ribbon.ReadTimeout=4000
ribbon.ConnectTimeout=4000
最终生效的是Feign的超时:
[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] -
执行耗时:3006ms 错误:Read timed out executing
POST http://clientsdk/feignandribbon/server
在LoadBalancerFeignClient
源码
如果Request.Options
不是默认值,就会创建一个FeignOptionsClientConfig
代替原来Ribbon的DefaultClientConfigImpl
,导致Ribbon的配置被Feign覆盖:
但若这么配置,最终生效的还是Ribbon的超时(4秒),难点Ribbon又反覆盖了Feign?不,这还是因为坑点二,单独配置Feign的读取超时无法生效:
clientsdk.ribbon.listOfServers=localhost:45678
feign.client.config.default.readTimeout=3000
feign.client.config.clientsdk.readTimeout=2000
ribbon.ReadTimeout=4000