一、超时时间
由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。
1、Dubbo 消费端
指定接口以及特定方法超时配置
<!--
属性覆盖规则
以 timeout 为例：
1）精确优先 （方法级优先，接口级次之，全局配置再次之）
2）消费者设置优先（如果级别一样，则消费方优先，提供方次之）
-->
<dubbo:reference interface="com.njf.gmall.service.UserService"
id="userService" check="false" timeout="4000">
<dubbo:method name="getUserAddressList" timeout="1000"></dubbo:method>
</dubbo:reference>
<!-- 配置当前消费者的统一规则，所有的服务都不检查-->
全局超时配置
<dubbo:consumer check="false" timeout="5000"></dubbo:consumer>2、Dubbo 服务端
全局超时配置
<dubbo:provider timeout="5000" />
指定接口以及特定方法超时配置
<dubbo:provider interface="com.foo.BarService" timeout="2000">
<dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>二、配置之间的关系
三、不同粒度配置的覆盖关系
以 timeout 为例，下图显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：
-
方法级优先，接口级次之，全局配置再次之。 -
如果级别一样，则消费方优先，提供方次之。
其中，服务提供方配置，通过 URL 经由注册中心传递给消费方。
配置的覆盖规则：
-
方法级配置别优于接口级别，即小 Scope 优先 -
Consumer 端配置 优于 Provider 配置 优于 全局配置， -
最后是 Dubbo Hard Code 的配置值（见配置文档）
dubbo 推荐在 Provider 上尽量多配置 Consumer 端属性
1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
2、在 Provider 配置后，Consumer 不配置则会使用 Provider 的配置值，即 Provider 配置可以作为 Consumer 的缺省值。否则，Consumer 会使用 Consumer 端的全局设置，这对于 Provider 不可控的，并且往往是不合理的
（建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置）。
理论上 ReferenceConfig 中除了 interface 这一项，其他所有配置项都可以缺省不配置，框架会自动使用 ConsumerConfig，ServiceConfig, ProviderConfig 等提供的缺省配置。
1、2.1.0 开始支持，注意声明：xmlns:p="http://www.springframework.org/schema/p"
2、引用缺省是延迟初始化的，只有引用被注入到其它 Bean，或被 getBean() 获取，才会初始化。如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：<dubbo:reference ... init="true" />
