介绍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 "容错数据";
}
}
}