Dubbo的基本使用

Charge8

已于 2022-07-10 13:04:46 修改

阅读量2.7k

点赞数 1

分类专栏： # Dubbo 文章标签： Dubbo的基本使用

于 2022-07-07 16:56:44 首次发布

本文链接：https://blog.csdn.net/qq_42402854/article/details/125662325

版权

Dubbo 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Apache Dubbo官网中文文档：

v2.7：https://dubbo.apache.org/zh/docs/v2.7/user/preface/background/

跟着官方文档了解Dubbo的基本使用。

一、Dubbo的基本使用

1、配置项信息

在 dubbo.properties配置文件中，如果我们没有指定配置项，Dubbo都会有默认值。

注意：配置项的覆盖关系

方法级优先，接口级次之，全局配置文件再次之。
如果级别一样，则服务消费方优先，服务提供方次之。

2、启动时检查

在启动时检查依赖的服务是否可用

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

可以通过 check=“false” 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check=“false”，总是会返回引用，当服务恢复时，能自动连上。

示例：通过 dubbo.properties方式

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

3、重试次数配置

服务消费方配置 dubbo服务重试次数。

Dubbo 服务在尝试调用一次之后，如出现非业务异常(服务突然不可用、超时等)，Dubbo 默认会进行额外的最多 2次重试。

重试次数支持两种自定义配置：

通过注解/xml进行固定配置；
通过上下文进行运行时动态配置

示例：通过上下文

    @Reference
    private DemoService demoService;

    @GetMapping("/sayHelloRetries")
    public String sayHello() {
        // dubbo服务调用前，通过RpcContext动态设置本次调用的重试次数
        RpcContext rpcContext = RpcContext.getContext();
        rpcContext.setAttachment("retries", "5");
        return demoService.sayHello("dubbo RPC调用");
    }

4、多协议

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

在 dubbo.properties配置文件中，指定多协议配置：

# Dubbo Protocol
#dubbo.protocol.name=dubbo
#dubbo.protocol.port=20880

dubbo.protocols.p1.id=dubbo1
dubbo.protocols.p1.name=dubbo
dubbo.protocols.p1.port=20881
dubbo.protocols.p1.host=0.0.0.0

dubbo.protocols.p3.id=dubbo2
dubbo.protocols.p3.name=dubbo
dubbo.protocols.p3.port=20882
dubbo.protocols.p3.host=0.0.0.0

在这里插入图片描述

也可以在导出服务时，指定某个服务单独使用某个协议。

@org.apache.dubbo.config.annotation.Service(protocol = {"p1"})
public class DemoServiceImpl implements DemoService {
...
}

5、多版本

在 Dubbo 中为同一个服务配置多个版本，可以用 version 区分。
当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

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

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

（1）facade-api新建一个接口，服务提供者创建多个版本的实现该接口的服务类。

Version1DemoServiceImpl
Version2DemoServiceImpl
Version3DemoServiceImpl

@org.apache.dubbo.config.annotation.Service(version = "v1.0.0")
public class Version1DemoServiceImpl implements VersionDemoService {

    @Override
    public String sayHello(String name) {
        URL url = RpcContext.getContext().getUrl();
        System.out.println("=======provider===sayHello方法调用=== name ->" + name);
        System.out.println("=======provider===sayHello方法调用=== url -> " + url);
        return "Hello v1.0.0" + name;
    }
}

（2）服务消费方指定版本号引入服务调用。

    @Reference(version = "v1.0.0")
    private VersionDemoService versionDemoService1;
    @Reference(version = "v2.0.0")
    private VersionDemoService versionDemoService2;
    // 如果不需要区分版本,指定*
    @Reference(version = "*")
    private VersionDemoService versionDemoService3;

    @GetMapping("/sayHello/v1")
    public String sayHello1() {
        return versionDemoService1.sayHello("dubbo RPC调用v1");
    }

    @GetMapping("/sayHello/v2")
    public String sayHello2() {
        return versionDemoService2.sayHello("dubbo RPC调用v2");
    }

    @GetMapping("/sayHello/v3")
    public String sayHello3() {
        return versionDemoService3.sayHello("dubbo RPC调用v3");
    }

注意：

zk注册中心发现，只有v1.0.0进行了注册，网上发现 2.7.5和2.7.6 如果一个接口有两个实现类，尽管version或者group不同，只能注册其中一个服务。使用xml可用。这里先了解使用。

在这里插入图片描述

6、服务分组

使用服务分组区分服务接口的不同实现。

当一个接口有多种实现时，可以用 group 区分。

（1）导出服务

@org.apache.dubbo.config.annotation.Service(group = "GroupDemo1")

（2）引入服务

@Reference(group = "GroupDemo1")

和多版本类似。
在这里插入图片描述

7、服务超时

在服务提供者和服务消费者上都可以配置服务超时时间。可以指定 timeout。

消费者调⽤⼀个服务，分为三步：

消费者发送请求（⽹络传输）
服务端执⾏服务
服务端返回响应（⽹络传输）

@org.apache.dubbo.config.annotation.Service(timeout = 6000)

@Reference(timeout = 3000)

8、负载均衡

Dubbo 提供的集群负载均衡策略，一般配置服务消费方。

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。

8.1 负载均衡策略

Random LoadBalance：随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance ：轮询，按公约后的权重设置轮询比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance：最少活跃调用数
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance：一致性 Hash
一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

8.2 示例

   @Reference(loadbalance = "roundrobin")
    private DemoService demoService;
    @Reference(loadbalance = "consistenthash")
    private DemoService demoService2;
   
    @GetMapping("/sayHello/roundrobin")
    public String sayHello() {
        for (int i = 0; i < 10; i++) {
            System.out.println((demoService.sayHello("随机 负载均衡")));
            try {
                Thread.sleep(1 * 1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        return "success";
    }

    @GetMapping("/sayHello/consistenthash")
    public String sayHello2() {
        // 一致性hash算法测试
        for (int i = 0; i < 10; i++) {
            System.out.println((demoService2.sayHello(i%5+"一致性hash算法 负载均衡")));
            try {
                Thread.sleep(1 * 1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        return "success";
    }

在这里插入图片描述

9、集群容错

集群调用失败时，Dubbo 提供的容错方案。

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/fault-tolerent-strategy/

集群容错表示：服务消费者在调⽤某个服务时，这个服务有多个服务提供者，在经过负载均衡后选出其中⼀个服务提供者之后进⾏调⽤，但调⽤报错后，Dubbo所采取的后续处理策略。缺省为 failover 重试。

集群容错模式：

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

重试次数配置如下：

@org.apache.dubbo.config.annotation.Service(timeout = 6000, retries = 2)

@Reference(timeout = 3000, retries = 2)

…等，查看文档

在这里插入图片描述

10、服务降级

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/service-downgrade/

服务降级表示：服务消费者在调⽤某个服务提供者时，如果该服务提供者报错了，所采取的措施。

集群容错和服务降级的区别在于：

集群容错是整个集群范围内的容错
服务降级是单个服务提供者的⾃身容错

对于程序员的 Dubbo RPC使用还是比较简单。更多使用查看官方文档。

11、本地伪装/服务降级

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-mock/

本地伪装通常用于服务降级，比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过 Mock 数据返回授权失败。

Dubbo中 Mock的功能相对于本地存根更简单⼀点，Mock其实就是Dubbo中的服务容错的解决方案。

    /**
     * mock方式有很多，查看文档
     */
    @Reference(timeout = 2000, mock = "force: return '本地伪装'")
    private DemoService demoService;

12、本地存根

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-stub/

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

简单理解，本地存根就是⼀段逻辑，这段逻辑是在服务消费端执行的。

12.1 示例

1）创建一个stub实现接口，放到api或者消费端都可以。

public class DemoServiceStub implements DemoService {

    private final DemoService demoService;

    // 构造函数传入真正的远程代理对象
    public DemoServiceStub(DemoService demoService){
        this.demoService = demoService;
    }

    @Override
    public String sayHello(String name) {
        // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
        try {
            return demoService.sayHello(name); // safe  null
        } catch (Exception e) {
            // 你可以容错，可以做任何AOP拦截事项
            return "容错数据";
        }
    }
}

2）消费端调用

      //@Reference(timeout = 2000, stub = "com.charge.learn.dubbo27.study.api.stub.DemoServiceStub")
    @Reference(timeout = 2000, stub = "true") //为true时，DemoServiceStub必须与接口位于同一个包。
    private DemoService demoService;