webservice连接失败怎么办

前言：webservice连接失败的原因已经找到并且解决，我尝试把这件事记录下来，作为一个经验保存下来。今天看到携程挂了，请先饶恕我的孤陋寡闻，直到今日我才知道“携程”，笑曰：小的未曾坐过灰机啊。

今早9点时分，突然发现服务器无法正常启动了，因为服务器在启动的时候是需要通过webservice访问权限的，而程序莫名其妙的就卡在webservice的通信上面，并且发生timeout后，程序就悄悄的退出了。捕捉到的日志为：

ERROR 2015-05-28 10:40:06,482 com.honzh.socket.util.ExchangeUtil: ; nested exception is: 
java.net.ConnectException: Connection timed out: connect
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: java.net.ConnectException: Connection timed out: connect
 faultActor: 
 faultNode: 
 faultDetail: 
{http://xml.apache.org/axis/}stackTrace:java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)

此时的我毫无头绪，因为之前服务器一直运行的特别正常，呵呵，注意是“特别”啊，不曾发生过webservice的连接超时，从代码角度上看不曾有一点问题。这就如同携程网事件、支付宝事件，我个人认为，不是数据库被物理删除了（显然新手是不会拥有数据库操作权限的，不然太2了），不是被黑了，不是线路被挖断了（支付宝显然在搪塞），我认可这篇文章说的从携程故障回顾在线服务的黑天鹅，程序都不是完美的，在一定情况下发生问题是必然的。

99.9%，服务中断时间：525.6分钟/年
99.99%，服务中断时间：52.56分钟/年
99.999%，服务中断时间：5.256分钟/年

当然了，出现这些问题，我们不是坐以待毙，我们要做的，还是要保持好心态，程序员不必认为是自己的过错，保持好心态踏踏实实的解决问题就好了，如果那些领导肆无忌惮的压迫你，只能说明他就是个pig。

---

回到我解决这个问题的层面上来看，我也很着急，毕竟问题发生得太没有征兆，并且让人捉摸不透。

1. 我先来看看其他的地方可以访问这个webservice不能？

从上图可以看到，我本地就可以访问，这首先说明我的service服务没有问题，然后在我的运行服务器上再测试这个连接，就发现无法访问，那就说明问题出在服务器上。

2. 再来看看网络连接是否畅通，测试结果是畅通。

3. 再互相ping一下双方IP，发现没有丢包。

4. 运行netstat -nao，发现service的端口也没有被占用。

5. 同时告诉我通过telenet测试一下ip和端口

不通，再测试一下其他端口，发现是可以连接的，这说明端口上出现了问题。
tips：请最好不要使用默认端口！

6. 请教服务器的管理人员，他们提供的建议是修改以下内容：

虽然我并不清楚跳跃点数是做什么的？

跃点：即路由。一个路由为一个跃点。传输过程中需要经过多个网络，每个被经过的网络设备点（有能力路由的）叫做一个跃点，地址就是它的ip。跃点数是经过了多少个跃点的累加器，为了防止无用的数据包在网上流散。 为路由指定所需跃点数的整数值（范围是 1 ~ 9999），它用来在路由表里的多个路由中选择与转发包中的目标地址最为匹配的路由。所选的路由具有最少的跃点数。跃点数能够反映跃点的数量、路径的速度、路径可靠性、路径吞吐量以及管理属性。

没有看得太懂。

---

最后， service服务选择其他的端口号。
这个我尝试了一下，发现OK。

总结：我最终的选择是修改了默认的端口号，我认为这种方式更加的让人放心。最重要的是，我想无论软件项目大小，在其领域，都会遇到类似的相对的黑天鹅事件，那么我们需要做的就是摆正好心态，放松心情来处理这件问题，但是往往做起来并没有那么容易，我就受到了很大的干扰。经历就是一种经验，相信自己。