问题引出，从dubbo2升级到了dubbo3版本，出现了一些消费方调用超时的现象，通过日志发现异常信息中的timeout竟然是1000ms，明明在暴漏接口的时候指定了超时时间，为什么没有生效。

经过debug分析调试后，找到了timeout无法获取预期值的源头，同时发现了两个关键可疑点：

• 从可疑点一，仔细研读计算超时时间的方法，挖掘出Dubbo配置的四层覆盖关系，最终我们巧妙利用不同层级的特性，解决了超时时间失效的问题。
• 从可疑点二中，发现类名使用了新版本的服务发现类进行了远超调用，联想到了应用级注册和接口级注册的因素，最终找到了解决失效时间的解决方案。

消费方在发起远超调用时，超时时间的逻辑：

• 首先，整体分为三大块，分别为方法级别、服务级别、实例级别。
• 然后在每一块内部，按照先消费方后提供方的顺序进行取值。

四个层级关系：

• System Properties，最高优先级，一般会在启动命令中通过JVM的-D参数进行指定。
• Externalized Configuration，优先级次之，外部化配置，可以直接从统一的配置中心加载配置。
• API/XML/注解，优先级再次之，开发直接写在代码中的一些配置。
• Local File，优先级最低，一般是项目中默认的一份基础配置，当前边三个层级都没配置的时候会读取。

学习来源：极客时间