第二章：（3）Dubbo 常用配置之 超时&配置覆盖关系

一、超时时间

　　由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。

　　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 经由注册中心传递给消费方。

　　配置的覆盖规则：

　　1) 方法级配置别优于接口级别，即小Scope优先

　　2) Consumer端配置 优于 Provider配置 优于 全局配置，

　　3) 最后是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" />