Dubbo的基本使用

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.consumer.check=false
#前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。
dubbo.registry.check=false

3、重试次数配置

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

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

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

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

示例：通过上下文

    @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。

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

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

@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