servicecomb-java-chassis
servicecomb-java-chassis copied to clipboard
apache
微服务调用出现低概率 连接超时io.netty.channel.ConnectTimeoutException，状态码490，服务端未收到请求。
--- 上图为metric日志报错截图。
定位过程： 1、观察到客户端请求失败，查看interfacelog，发现错误码为490；客户端运行无明显运行异常日志 2、查看服务端运行日志，无任何异常信息，服务端未收到请求，时间点前后无任何异常日志打印。 3、查看metric日志，见上面截图，RestClientInvocation:]|Failed to send request, local:not connected, remote:/10.33.8.46:8082. io.netty.channel.ConnectTimeoutException: connection timed out: /10.33.8.46:8082 4、观察服务端出现问题时间点前后日志，服务可以正常收到来自上述客户端的请求，并能处理成功。
以上，请专家帮忙指点可能是哪里问题？观察过自测环境和现网，均有低概率发生。十分感谢~
除了二楼给出的可能性，还有一种可能是 consumer 端和 provider 端的连接超时配置没配好，HTTP1.1 长连接复用场景下 consumer 端准备复用长连接发请求时 provider 端判定连接 idle timeout 主动断连，导致网络发送失败。 具体原因可以考虑 tcpdump 抓包分析，以下是我说的这种可能性的修复方法：
- consumer业务调用超时时间：
servicecomb.request.timeout - client端网络连接 idle timeout：
servicecomb.rest.client.connection.idleTimeoutInSeconds - server端网络连接 idle timeout：
servicecomb.rest.server.connection.idleTimeoutInSeconds
实际使用的时候注意配置 consumer业务调用超时时间 < client端网络连接 idle timeout < server端网络连接 idle timeout。此时连接超时断连也是 client 端主动发起的，这样才能确保 consumer 调用 provider 时不会出现 client 端尝试复用的HTTP连接恰好被 server 端超时断开的情况，进而导致请求调用失败。
至于这三个配置项之间间隔多少，建议自己摸索一下，保险一点的可以设置 10 秒以上（随口估计的，不保证没问题 : )）。
参考：
注意：以上说明适用于 Rest over Vertx 传输方式，HTTP1.1 的场景，如果使用的是 HTTP2，或者server端传输方式选择的是 REST over Servlet，就请结合实际分析配置。
close old issues, please feel free to submit a new one if the problem still exists.