一、超时时间
由于网络或服务端不可靠,会导致调用出现一种不确定的中间状态(超时)。为了避免超时导致客户端资源(线程)挂起耗尽,必须设置超时时间。
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” />