一个dubbo配置超时的问题。求助。

Question

最近有个dubbo的项目，有超时的问题。看了下配置文件
dubbo:reference 里配置的时间300秒 dubbo:registry 里也配置了一个超时时间3秒 各种超时问题

另一个环境两个的时间是反过来配置的，目前没发现这类问题。

想问下大神们，这两个地方配置的timeout作用分别是什么？

Answer 1

在工作和学习的过程中,具体运用Dubbo的时候遇到了很多的问题,这些问题一方面让自己进一步了解所谓的dubbo,另一方面通过对它们的总结和分析能够在工作中加倍的提高效率,接下来将会对遇到的和别人总结的一些常见的问题进行汇总.

1.增加提供服务版本号和消费服务版本号.

    这个具体来说不算是一个问题,而是一种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供一个服务进行相关的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时候我们可以通过给提供方增加版本的方式来区分.这样能够剩下很多的物理资源,同时为今后更换接口定义发布在线时，可不停机发布，使用版本号.



    引用只会找相应版本的服务,例如

dubbo服务的版本号在项目中非常实用,如果后续系列允许的话,我会专门对dubbo的版本进行一个详细的文章说明.

2.dubbo reference注解问题

   @Reference只能在springbean实例对应的当前类中使用，暂时无法在父类使用；如果确实要在父类声明一个引用，可通过配置文件配置dubbo:reference，然后在需要引用的地方跟引用springbean一样就可以了.

3.服务超时问题.

此问题也是在项目中非常常见的一个问题,但是这个问题背后可能是各种原因导致.

     目前如果存在超时，情况基本都在如下：

(1) 一种情况是服务请求超时.

   客户端耗时大，也就是超时异常时的client elapsedxxx，这个是从创建Future对象开始到使用channel发出请求的这段时间，中间没有复杂操作，只要CPU没问题基本不会出现大耗时，顶多1ms属于正常IOThread繁忙，默认情况下，dubbo协议一个客户端与一个服务提供者会建立一个共享长连接，如果某个客户端处于特别繁忙而且一直往一个服务提供者塞请求，可能造成IOThread阻塞，一般非常特殊的情况才会出现服务端工作线程池中线程全部繁忙，接收消息后塞入队列等待，如果等待时间比预想长会引起超时网络抖动，如果上述情况都排除了，还出现在请求发出后，服务接收请求前超过预想时间，只能归类到网络抖动了，需要SA一起查看问题服务自身耗时大，这个需要应用自身做好耗时统计，当出现这种情况的时候需要用数据来说明问题及规划优化方案，建议采用缓存埋点的方式统计服务中各个执行阶段的耗时情况，最终如果超过预想时间则把缓存统计的耗时情况打日志，减少日志量，且能够得到更明确的信息现在我们应用使用过程中发现两种类型的耗时，一种我们目前只能归类到网络抖动，后续需要找运维一起关注这个问题，另外一种是由于一些历史原因，数据库查询容易发生抖动，总有一个时间点会突然多出很多超时。



    (2) 二大类的情况是调用的版本不对.

在上面我们已经说了具体的版本问题,如果你调用的对方版本不对的话,就相当于你的消费者没有提供者.所以会出现超时,此时只需要把版本对应好即可.

(3)提供者的服务被禁止.

这是一种人为的控制,通过监控中心我们可以对具体的服务,以及它的权重进行控制,当我将一个具体的服务禁止之后消费者就调不到相关的服务,此时就会出现超时的问题.解决方案,取消禁止即可.注意这里有一定时间的缓存,实际操作的时候应该注意.

4.服务保护

     服务保护的原则上是避免发生类似雪崩效应，尽量将异常控制在服务周围，不要扩散开。说到雪崩效应，还得提下dubbo自身的重试机制，默认3次，当失败时会进行重试，这样在某个时间点出现性能问题，然后调用方再连续重复调用，很容易引起雪崩，建议的话还是很据业务情况规划好如何进行异常处理，何时进行重试。服务保护的话 考虑服务的dubbo线程池类型（fix线程池的话考虑线程池大小）、数据库连接池、dubbo连接数限制是否都合适.

5.注册中心的分组group和服务的不同实现group

       这两个东西完全不同的概念，使用的时候不要弄混了。registry上可以配置group，用于区分不同分组的注册中心，比如在同一个注册中心下，有一部分注册信息是要给开发环境用的，有一部分注册信息时要给测试环境用的，可以分别用不同的group区分开，目前对这个理解还不透彻，大致就是用于区分不同环境。service和reference上也可以配置group，这个用于区分同一个接口的不同实现，只有在reference上指定与service相同的group才会被发现。



    以上为5类我们所遇到的问题,总结下来为了以后的路走的更顺畅.

在工作和学习的过程中,具体运用Dubbo的时候遇到了很多的问题,这些问题一方面让自己进一步了解所谓的dubbo,另一方面通过对它们的总结和分析能够在工作中加倍的提高效率,接下来将会对遇到的和别人总结的一些常见的问题进行汇总.

1.增加提供服务版本号和消费服务版本号.

    这个具体来说不算是一个问题,而是一种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供一个服务进行相关的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时候我们可以通过给提供方增加版本的方式来区分.这样能够剩下很多的物理资源,同时为今后更换接口定义发布在线时，可不停机发布，使用版本号.



    引用只会找相应版本的服务,例如

dubbo服务的版本号在项目中非常实用,如果后续系列允许的话,我会专门对dubbo的版本进行一个详细的文章说明.

2.dubbo reference注解问题

   @Reference只能在springbean实例对应的当前类中使用，暂时无法在父类使用；如果确实要在父类声明一个引用，可通过配置文件配置dubbo:reference，然后在需要引用的地方跟引用springbean一样就可以了.

3.服务超时问题.

此问题也是在项目中非常常见的一个问题,但是这个问题背后可能是各种原因导致.

     目前如果存在超时，情况基本都在如下：

(1) 一种情况是服务请求超时.

   客户端耗时大，也就是超时异常时的client elapsedxxx，这个是从创建Future对象开始到使用channel发出请求的这段时间，中间没有复杂操作，只要CPU没问题基本不会出现大耗时，顶多1ms属于正常IOThread繁忙，默认情况下，dubbo协议一个客户端与一个服务提供者会建立一个共享长连接，如果某个客户端处于特别繁忙而且一直往一个服务提供者塞请求，可能造成IOThread阻塞，一般非常特殊的情况才会出现服务端工作线程池中线程全部繁忙，接收消息后塞入队列等待，如果等待时间比预想长会引起超时网络抖动，如果上述情况都排除了，还出现在请求发出后，服务接收请求前超过预想时间，只能归类到网络抖动了，需要SA一起查看问题服务自身耗时大，这个需要应用自身做好耗时统计，当出现这种情况的时候需要用数据来说明问题及规划优化方案，建议采用缓存埋点的方式统计服务中各个执行阶段的耗时情况，最终如果超过预想时间则把缓存统计的耗时情况打日志，减少日志量，且能够得到更明确的信息现在我们应用使用过程中发现两种类型的耗时，一种我们目前只能归类到网络抖动，后续需要找运维一起关注这个问题，另外一种是由于一些历史原因，数据库查询容易发生抖动，总有一个时间点会突然多出很多超时。



    (2) 二大类的情况是调用的版本不对.

在上面我们已经说了具体的版本问题,如果你调用的对方版本不对的话,就相当于你的消费者没有提供者.所以会出现超时,此时只需要把版本对应好即可.

(3)提供者的服务被禁止.

这是一种人为的控制,通过监控中心我们可以对具体的服务,以及它的权重进行控制,当我将一个具体的服务禁止之后消费者就调不到相关的服务,此时就会出现超时的问题.解决方案,取消禁止即可.注意这里有一定时间的缓存,实际操作的时候应该注意.

4.服务保护

     服务保护的原则上是避免发生类似雪崩效应，尽量将异常控制在服务周围，不要扩散开。说到雪崩效应，还得提下dubbo自身的重试机制，默认3次，当失败时会进行重试，这样在某个时间点出现性能问题，然后调用方再连续重复调用，很容易引起雪崩，建议的话还是很据业务情况规划好如何进行异常处理，何时进行重试。服务保护的话 考虑服务的dubbo线程池类型（fix线程池的话考虑线程池大小）、数据库连接池、dubbo连接数限制是否都合适.

5.注册中心的分组group和服务的不同实现group

       这两个东西完全不同的概念，使用的时候不要弄混了。registry上可以配置group，用于区分不同分组的注册中心，比如在同一个注册中心下，有一部分注册信息是要给开发环境用的，有一部分注册信息时要给测试环境用的，可以分别用不同的group区分开，目前对这个理解还不透彻，大致就是用于区分不同环境。service和reference上也可以配置group，这个用于区分同一个接口的不同实现，只有在reference上指定与service相同的group才会被发现。



    以上为5类我们所遇到的问题,总结下来为了以后的路走的更顺畅.