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

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

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

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

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

2. 启动检查

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

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

dubbo.consumer.check=false

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

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

Dubbo消费端

Dubbo服务端

通过上面的配置，我们可能产生疑惑，如果多方都配置了属性，那么会以哪个为准？这就涉及到配置覆盖关系

以 timeout 为例，显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：

方法级优先，接口级次之，全局配置再次之。

如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过 URL 经由注册中心传递给消费方。

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

4. 重试次数

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

5. 多版本

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

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

在低压力时间段，先升级一半提供者为新版本

再将所有消费者升级为新版本

然后将剩下的一半提供者升级为新版本

老版本服务提供者配置：

新版本服务提供者配置：

老版本服务消费者配置：

新版本服务消费者配置：

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

6. 本地存根

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

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

业务逻辑放在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 "容错数据";        }    }}

转载地址：http://scaux.baihongyu.com/

你可能感兴趣的文章