Dubbo在开发中的一些常用配置

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

介绍Dubbo在开发中的一些常用配置，文中内容主要参考dubbo文档配置和示例两节，详细可移步访问 传送站

1. 属性配置方法及加载顺序

属性常用配置方法主要有三种：

第一种是通过启动时在虚拟机参数中加上相关信息

第二种也是最常用的是通过xml方式配置，随着springboot和dubbo的集成，这种方式在springboot项目中表现为通过application.properties来配置，两者优先级相同；

第三种是在classpath 根目录下的创建 dubbo.properties，dubbo启动时，如果没有其他配置文件，会自动加载该配置。

2. 启动检查

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。

可在xml和properties文件中进行配置，以显式关闭启动检查

<dubbo:consumer check="false" />

dubbo.consumer.check=false

3. 超时设置 & 配置覆盖关系

由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。缺省使用<dubbo:consumer>的timeout，目前默认为1000。

Dubbo消费端

<dubbo:consumer timeout="5000" />
<dubbo:reference interface="com.foo.BarService" timeout="2000">
<dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

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

建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如调用的超时时间，合理的重试次数，等等；如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。另外，在服务提供方配置后，消费方不配置则会使用服务提供方的配置值，即服务提供方配置可以作为消费方的缺省值。否则，消费方会使用消费方的全局设置，这对于服务提供方是不可控的，并且往往是不合理的。

4. 重试次数

失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。

<dubbo:service retries="2" />

<dubbo:reference retries="2" />

<dubbo:reference>
<dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

5. 多版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

可以按照以下的步骤进行版本迁移：

在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本

老版本服务提供者配置：

<dubbo:service interface="com.foo.BarService" version="1.0.0" />

新版本服务提供者配置：

<dubbo:service interface="com.foo.BarService" version="2.0.0" />

老版本服务消费者配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

新版本服务消费者配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

如果不需要区分版本，可以按照以下的方式配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

6. 本地存根

远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，比如：做 ThreadLocal 缓存，提前验证参数，调用失败后伪造容错数据等等，此时就需要在 API 中带上 Stub，客户端生成 Proxy 实例，会把 Proxy 通过构造函数传给 Stub ，然后把 Stub 暴露给用户，Stub 可以决定要不要去调 Proxy。

服务提供方（服务消费方也可配置）

<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />

业务逻辑放在Stub类中实现

package com.foo;
public class BarServiceStub implements BarService {
private final BarService barService; // 构造函数传入真正的远程代理对象
public (BarService barService) {
this.barService = barService;
} public String sayHello(String name) {
// 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
try {
return barService.sayHello(name);
} catch (Exception e) {
// 你可以容错，可以做任何AOP拦截事项
return "容错数据";
}
}
}