对dubbo服务调用超时的思考

今天在需求上线前，测试时发现之前经常碰到的一个问题就是，一个项目的服务引用另一个项目服务时，会发生服务调用超时的问题，在我的需求中，导致连接超时抛出异常，抛出的异常如图所示：

去查看程序的配置文件，可以看到我们程序设置的超时时间为30秒，重新尝试连接的次数为0次，如图：
看到这里，解决了一次调用失败，是否会再次尝试调用的疑惑。

接下来引发了下面几个问题的思考：

1.调用其他项目的服务超时，是因为什么导致的？

导致这个错误，其本质就是调用的服务执行太慢，方法超出设定的时间，那么影响程序执行的时间与什么有关呢。第一是网络问题，远程调用服务离不开网络，调用的服务不在同一台服务器上，如果在同一个机房（局域网下），就会通过网络进行连接。如果不在同一个局域网下，那么就需要跨局域网访问（局域网很快），导致连接时间加长。第二影响程序执行的就是电脑的性能。比如cpu，内存的占有情况，线程的个数等等（这个时候如果服务器在做压测，就极可能发生这种情况）。
不知道会不会还有其他原因。

2.生产上会出现服务调用超时的情况吗？如果发生，对我的程序会带来什么影响？

一般来说，生产上不会存在这种问题，发生的概率很低，生产的几台服务，要么是发不在同一台机器上要么是在同一个机房中（局域网下），因此网络的连接是非常快的。但是即使概率再低，也有0.01%的概率可能发生，当发生时，对我程序会带来什么影响呢？
第一日志错误表中有一条UN的错误信息，第二是程序异常导致下面的代码不会继续执行，具体没执行的代码具体分析。

那么又有一个问题，既然抛出了异常，调用的服务会执行成功吗？
一般情况下，只要程序不出现错误，就能执行成功，只是时间的问题。

3. 对于dubbo.retrie属性，在什么情况下适用于将其属性值设置为0，什么情况下可以设置为>0.

面对不同的需求，我们需要使用不同的配置。retries>0只适用于查询的服务，多次查询程序执行的结果是一致的。而大多数情况下都是置为0的，因为程序用于增删改的情况，只能做一次尝试，做多次尝试会导致数据失控。

4.在参考博客中，有一个特别好的问题？

问：在自己的服务调用对方的dubbo服务时，需要try catch 超时吗？

这次公司项目做测试，遇到的一个问题，问题虽小，却要深入思考起来，的确是收获挺大。本人小白，才刚开始写博客，以上留下的几个问题还请大佬指教??????

参考博客： https://blog.csdn.net/wzygis/article/details/80336164