Dubbo——配置

一、配置原则

　　JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。

　　XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。

　　Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

二、启动检查

　　默认情况下，dubo将检查依赖服务在启动时是否可用。当Spring完全初始化不可用时，它将抛出一个异常以防止Spring完成初始化，以便在发布应用程序(默认设置)之前尽早发现问题：check=true.

　　你可以关掉检查check=false...例如，有些服务在运行测试时不关心它，或者由于循环依赖关系，必须首先启动测试。

　　此外，如果Springbean是延迟加载的，或者使用API编程延迟引用服务，则关闭检查，否则服务将在服务暂时不可用时抛出异常，然后获得一个空引用。如果您配置check=false，你可以得到一个推荐信。还原服务后，服务可以自动重新连接。

　　2.1 使用Spring配置文件

　　　　禁用服务的启动检查(在没有提供提供程序时抛出一些异常/错误)：

<dubbo:reference interface = "com.foo.BarService" check = "false" />

　　　　禁用所有服务的启动检查(未提供时抛出一些异常/错误)：

<dubbo:consumer check = "false" />

　　　　禁用注册中心启动检查(注册订阅失败错误)：

<dubbo:registry check="false" />

　　2.2 使用dubbo.properties

dubbo.reference.com.foo.BarService.check = false
dubbo.reference.check = false
dubbo.consumer.check = false
dubbo.registry.check = false

　　2.3 使用-d参数

java -Ddubbo.reference.com.foo.BarService.check = false
java -Ddubbo.reference.check = false
java -Ddubbo.consumer.check = false
java -Ddubbo.registry.check = false

三、超时时间

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

　　3.1 dubbo消费端

全局超时配置
<dubbo:consumer timeout="5000" />

指定接口以及特定方法超时配置
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

　　3.2 dubbo服务端

全局超时配置
<dubbo:provider timeout="5000" />

指定接口以及特定方法超时配置
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>

　　3.3 配置原则

　　　　3.3.1 dubbo推荐在Provider上尽量多配置Consumer端属性：

　　　　1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

　　　　2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

　　　　3.3.2 配置覆盖规则

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

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

　　　　3、最后是Dubbo Hard Code的配置

四、重试次数

　　当出现故障时，重试另一台服务器(默认)。通常用于幂等操作，但重试会导致更长的延迟。重试的时间可以通过retries =2(第一次除外)

　　配置：

<dubbo:service retries="2" />

　　或：

<dubbo:reference retries="2" />

　　或：

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

　　幂等和非幂等区别：https://www.cnblogs.com/lzc978/p/10386122.html

五、版本号

　　当接口实现不兼容升级时，可以使用版本号转换。不同版本的服务不相互引用。（灰度发布）

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

在低压阶段，升级到提供程序的一半到新版本。
然后将所有消费者升级到新版本。
然后将其余的一半提供程序升级到新版本。

　　5.1 服务提供者配置的旧版本：

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

　　5.2 新版本的服务提供者配置：

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

　　5.3 服务使用者配置的旧版本：

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

　　5.4 新版本的服务使用者配置：

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

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

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

六、本地存根

　　当使用RPC时，客户端通常只使用接口，但有时客户端也希望在客户机中执行部分逻辑。例如：执行ThreadLocalcache，验证参数，在调用失败时返回模拟数据，等等。

　　为了解决这个问题，您可以在api中配置存根，以便当客户端生成代理实例时，它将代理传递给Stub通过构造函数，然后可以在存根实现代码中实现您的逻辑。

　　6.1 在Spring配置文件中配置如下：

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

　　　　或

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

　　6.2 提供Stub实现

package com.foo;
public class BarServiceStub implements BarService {
    private final BarService barService;

    // The real remote proxy object is passed in through the constructor
    public BarServiceStub(BarService barService){
        this.barService = barService;
    }

    public String sayHello(String name) {
        // The following code is executed on the client. You can do local ThreadLocal caching on the client side, or verify parameters, etc.
        try {
            return barService.sayHello(name);
        } catch (Exception e) {
            // You can return the mock data.
            return "MockData";
        }
    }
}

Stub必须有一个可以传递代理的构造函数。
BarServiceStub实现BarService，它有一个在远程BarService实例中传递的构造函数

猜你喜欢