failed to connect to server /xx.xx.xx.xx:20880 client-side timeout问题分析并解决

一次离奇的排查dubbo服务问题之旅。

首先是开启服务提供者，正常启动，后来启动服务调用者，总是报错。错误如下：

2018-06-04 11:17:24,956(7063 ms)[WARN ][DubboClientReconnectTimer-thread-1]com.alibaba.dubbo.remoting.transport.
AbstractClient :  [DUBBO] client reconnect to 10.0.76.21:30000 find error . url: dubbo://10.0.76.21:30000/com.
lenovo.lps.push.common.rpc.MsgBroker?accepts=500&application=nginxKeepalivedService&check=false&codec=dubbo&dubbo
=2.5.3&heartbeat=60000&interface=com.lenovo.lps.push.common.rpc.MsgBroker&logger=log4j&methods=unsubscribe,
subscribe,publish,deleteMsg,publishJid,ack&pid=6048&retries=0&revision=2.6.6&side=consumer&timeout=10000×tamp=
1528082238672&version=1.0.0, dubbo version: 2.5.3, current host: 10.0.76.20com.alibaba.dubbo.remoting.Remoting
Exception: client(url: dubbo://10.0.76.21:30000/com.lenovo.lps.push.common.rpc.MsgBroker?accepts=500&application
=nginxKeepalivedService&check=false&codec=dubbo&dubbo=2.5.3&heartbeat=60000&interface=com.lenovo.lps.push.common.
rpc.MsgBroker&logger=log4j&methods=unsubscribe,subscribe,publish,deleteMsg,publishJid,ack&pid=6048&retries=0&
revision=2.6.6&side=consumer&timeout=10000×tamp=1528082238672&version=1.0.0) failed to connect to server /10.0.76
.21:30000 client-side timeout 3000ms (elapsed: 3000ms) from netty client 10.0.76.20 using dubbo version 2.5.3
        at com.alibaba.dubbo.remoting.transport.netty.NettyClient.doConnect(NettyClient.java:127)
        at com.alibaba.dubbo.remoting.transport.AbstractClient.connect(AbstractClient.java:280)
        at com.alibaba.dubbo.remoting.transport.AbstractClient$1.run(AbstractClient.java:145)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

整个过程非常的耗时，猜测几个可能的情况。

1、服务提供者启动失败。

经过检查，发现启动了，并且监听的是30000端口。排除这个错误。

2、服务提供者没有绑定主机ip。

经过检查，发现配置了主机ip。

3、超时

我有两个服务提供者，两个均设置的超时时间是3000ms,一个可以访问，就这个不能访问，超时应该不存在。

4、防火墙 + 端口占用

首先，单纯防火墙的问题，导致外部无法访问本机30000端口的问题是不存在的，因为本机还有其他服务也会有监听端口，而其他端口就可以正常访问，唯独30000端口只有监听，却无法接收请求。

就卡在这个端口问题上，从服务启动来看，端口绑定在30000上，不存在端口占用问题，但是通过telnet命令，返回No route to host。很奇怪。而我通过telnet 另一个服务提供者，能够成功。这说明这个服务器上肯定是有问题的。

通过telnet访问另一个服务提供者，正确得到应答。

后来发现这个服务器原来装过docker,而这个服务最初是放在docker里面的，后来部署不方便，将docker里面的服务单独拿到外面，但是端口配置没有在防火墙规则里面删除。故导致30000端口被监听，但是，最终30000端口被映射到了docker一个容器的30000端口上，因此访问本机自身的监听端口就会有问题。

最终解决办法就是在防火墙规则里面去掉docker30000端口映射的这些规则，然后service iptables reload 即可。