dubbo超时配置不生效排查

起因

服务在领取卡券时，调其它服务dubbo接口，经常出现超时（基本每天都有），然后告警。

日志和告警就不看了，大致意思就是调用超时。

初次修复

针对调用超时告警，引起超时的两个点，有可能调用会员三方权益系统的服务引发超时，也有可能调用卡券系统系统超时，都在一条链路上，

做了一次修复，回顾下最开始的改动，修改dubbo单接口的配置，2000ms->5000ms。

<dubbo:reference interface="com.xxx.xxx.xxx.xxx" id="xxx"
                         timeout="${dubbo.timeout:1000}" retries="${dubbo.retries:1}"  registry="registry" check="false">
    <dubbo:method name="releaseCoupon" timeout="5000" retries="0"/>
</dubbo:reference>

另一个相关服务也做了修改，这里不展示了，当时在本机这么测试没有问题，嗯，然后就跟着当时的一个迭代版本发布上去了。

发上去之后，情况并没有好转，还是有收到发生调用超时告警，这个告警就持续了一段时间，基本上每天都有吧，大家也没管。近期在整理接口耗时优化的时候，正好一起把这个问题盘一下

再次排查问题

1、是哪个环节的配置没有生效呢？带着问题回归dubbo本质，借助工具查看起注册中心服务信息，一环一环排查，先来看下客户端网关到权益系统 超时时间是否生效了？

生产环节查询超时时间设置，

解释一下，这里由于配置有优先级关系， consumer > provider， 所以调用的超时时间是 5000没有问题，按照配置走的

在权益系统中领券接口会调用 releaseCoupon方法，这个方法有些类型的券会继续http调用第三方公司服务会导致最高耗时接近4000ms ，在5000ms允许范围内，按理不应该出现调用超时告警。

但在权益系统也设置了releaseCoupon方法的超时时间，看注册中心，没有相关timeout相关参数，看来这里的配置 的确没有生效

借助工具查看权益系统作为releaseCoupon 的消费方，超时时间没有生效，或者被覆盖了？

带着怀疑，查看了权益系统中有哪些地方调用 使用了该接口，搜了一下真是有的，只有我们关心的那个依赖征对methods做了配置，其他地方可能当时第一次解决这个问题的时候，没有注意到

怀疑这两个地方依赖服务时，由于有先后关系，会不会是之前设置了超时时间，后面又被没设置的给覆盖了 dubbo consumer在zk上的路径信息

（对一个dubbo provider服务，这里多出@Reference引入依赖，但在zk上只注册一条consumer路径信息，所以会出现覆盖）

虽然猜测到了问题，还是要在测试环境验证下

思路：修改上述两处对指定方法的超时时间，并且设置不一样，以示区别，

一个5600，一个5000，

查看注册中心 服务消费者信息，两台consumer的timeout都为 5600 ，说明有覆盖配置问题

问题已经定位，当前这个问题，打算直接定义好服务provider上releaseCoupon方法的超时时间，从源头控制一切，这也比较符合dubbo最佳实践中的意见， provider最了解自己的服务，自己做好参数控制

当然还有一种就是在 消费者端引用的地方都设置下超时时间，但这不是最好的方法，毕竟底层卡券系统，很多其他服务都会调用，也给别人考虑下。直接将provider超时时间改成5000ms。

配置没有问题，Service支持 methods属性配置，但是结果不生效，查看注册中心这个服务的提供者信息，timeout属性也没有，之前没配置这个的时候，起码还有 default.timeout=2000属性

于是查看当前依赖的dubbo版本中ServiceAnnotationBeanPostProcesser这里面解析的时候 并没有对 methods属性做解析支持，从而导致注解上这个配置没有生效

当前依赖dubbo版本 为 2.7.2

网上查询下 dubbo ServiceAnnotationBeanPostProcessor methods 也确实存在这个bug, dubbo官方在2.7.2版本没有支持，在dubbo- 2.7.4版本修复了

能解释上面我们配置不生效的问题了

之前下载了dubbo最新的源码，查看了 ServiceAnnotationBeanPostProcessor

查看 ServiceClassPostProcessor 的确增加了 methods属性支持

由于当前dubbo-2.7.2版本，不能直接升级到最新的版本，所以从provider不太好通过配置来解决这个超时时长

以上引入服务的配置这些问题，在以往的开发过程中都没见到过的，

嗯，或许有人会问，spring里面的注入的service不都是单例的吗，service只会加载一次，怎么会出现覆盖了。

我的理解是，@Reference是通过动态代理去调用的服务，spring每次扫描到注解的时候都会基于当前的配置去生成代理服务，所以会覆盖

最后解决：还是从消费端vip-biz-thirdrights通过@Reference声明了该服务 都要设置一遍 methods = {@Method(name = "releaseCoupon", timeout = 5000)}

问题总结

1、在使用@Reference引入三方服务，并且有特殊设置时，需要在所有引入的地方都要统一设置，避免spring先后加载问题出现覆盖配置

2、多处引入同一个外部service时，可考虑创建公共的Helper或者Manager封装其业务操作，这样配置也都统一了