第三章 Dubbo配置实战

最新推荐文章于 2024-03-27 19:34:01 发布

原创最新推荐文章于 2024-03-27 19:34:01 发布 · 309 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #dubbo #rpc

重温dubbo 专栏收录该内容

4 篇文章

订阅专栏

本文介绍了Dubbo的配置实战，包括启动时检查的作用与配置，超时设置，重试次数设定，以及如何实现多版本服务。通过示例展示了如何在不同层级配置这些参数，确保服务的稳定性和容错能力。

Dubbo都有哪些配置？提供了哪些功能？

3.1 启动时检查

3.1.1 作用

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true”。
在这里插入图片描述
可以通过 check=“false” 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。即使服务不可用，依然会创建代理对象。
另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check=“false”，总是会返回引用（代理对象的引用），当服务恢复时，能自动连上。

3.1.2 示例

通过 spring 配置文件

关闭某个服务的启动时检查 (没有提供者时报错)：
<dubbo:reference interface="com.foo.BarService" check="false" />
关闭所有服务的启动时检查 (没有提供者时报错)：
<dubbo:consumer check="false" />
关闭注册中心启动时检查 (注册订阅失败时报错)：
<dubbo:registry check="false" />

通过 dubbo.properties

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

通过 -D 参数

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

3.1.3 配置的含义

dubbo.reference.check=false，强制改变所有 reference 的 check 值，就算配置中有声明，也会被覆盖。
dubbo.consumer.check=false，是设置 check 的缺省值，如果配置中有显式的声明，如：<dubbo:reference check=“true”/>，不会受影响。
dubbo.registry.check=false，前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。

3.2 超时设置

方法调用超时时间(毫秒)
可以在多处设置timeout属性值。记住优先级：1.方法级别 > 接口级别 > 全局配置（缺省配置） 2.级别一样时，消费者 > 提供者参考第二章

3.2.1 示例

在dubbo:reference（服务消费者引用服务配置。对应的配置类： org.apache.dubbo.config.ReferenceConfig）中设置timeout的值：

可选
缺省使用dubbo:consumer的timeout

dubbo:consumer（服务消费者缺省值配置。配置类： org.apache.dubbo.config.ConsumerConfig 。同时该标签为 dubbo:reference 标签的缺省值设置。）中设置timeout的值：

可选
缺省值是1000

dubbo:service和dubbo:provider也可配置timeout值，它们的缺省值为1000。

3.3 重试次数设置

远程服务调用重试次数，不包括第一次调用，不需要重试请设为0。

具体设置方式跟设置timeout的方式一样。
retries缺省值为2。
如果重试失败，会去主动去其他机器请求服务。（失败策略）
最终返回给调用方的错误日志是最后一次请求所产生的错误异常结果。
幂等操作可以设置重试次数。

3.4 多版本

3.4.1 作用

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。（一个接口多个实现，实现灰度发布）
可以按照以下的步骤进行版本迁移：

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

3.4.2 示例

老版本服务提供者配置：
<dubbo:service interface=“com.foo.BarService” id=“..." version="1.0.0" />
新版本服务提供者配置：
<dubbo:service interface=“com.foo.BarService" id=“..." 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="*" />

3.5 本地存根

3.5.1 作用

提供方想在客户端实现部分逻辑
Stub放在API包中提供给客户端

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

3.5.2 示例

Stub的实现:

package com.foo;  //API包
// 在 interface 旁边放一个 Stub 实现，它实现 BarService 接口，并有一个传入远程 BarService 实例的构造函数
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 "容错数据";
        }
    }
}

在 spring 配置文件中按以下方式配置：服务端和客户端都可以配置stub参数，优先级规则同之前所讲的配置一致
<dubbo:service interface="com.foo.BarService" stub="true" />
或
<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />