Dubbo+Zookeeper使用_dubbo zookeeper配置

说明：Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。

本文介绍Dubbo的简单使用及一些Dubbo功能特性，注册中心使用的是ZooKeeper，可在官网下载。

（另外，在阿里巴巴发出的《微服务治理技术白皮书》中各种注册中心的区别如下：）

环境搭建

首先，搭建一个ZooKeeper + Dubbo的项目

（1）下载ZooKeeper

在上面提供的官网上下载ZooKeeper，解压到一个没有中文的路径下；

因为默认提供的配置文件是一个模板，解压后需要手动设置一下，将zookeeper默认的配置文件（zoo_sample.cfg）复制一份，并将文件名改为"zoo.cfg"

另外，修改zoo.cfg配置文件中的这行配置，默认的是Linux文件路径，修改为当前目录的上级目录（…/data）；

启动，选择安装目录下bin文件夹下的zkServer.cmd文件，可双击启动或者在该目录下打开CMD窗口执行

没有报错，运行结果如下，表示启动成功

如果启动失败，提示此时不应有 jdk，参考：http://t.csdn.cn/52O2K

（2）创建项目

创建一个Zookper+Dubbo的项目，有两个微服务，一个用户服务（UserService），一个订单服务（OrderService），

• 订单服务（消费者，Consumer）：没有Service层，直接使用用户服务查询用户信息、用户名；

• 用户服务（提供者，Provider）：没有Controller层，提供查询用户信息、用户名的接口；

订单服务（OrderService）

Controlle层，两个接口，一个用于查找用户名，一个用于查找用户。实现暂时空着，待会儿使用Dubbo调用用户服务对应的接口

@RestController
@RequestMapping("order")
public class OrderController {

    @GetMapping("/name")
    public String getUserName(Integer id){
        return userService.getUserName(id);
    }

    @GetMapping("/user")
    public User getUser(Integer id){
        return userService.getUser(id);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

用户服务（UserService）

UserService实现类，实现两个接口，分别是查询用户名，返回固定值；查询用户，返回固定用户对象；

@Service
public class UserServiceImpl implements UserService {


    @Override
    public String getUserName(Integer id) {
        return "getUserName";
    }

    @Override
    public User getUser(Integer id) {
        User user = new User(30, "张三", "12456");
        return user;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

（3）配置

使用Dubbo前，需先导入依赖，我这里直接在父模块中添加，如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.hzy</groupId>
    <artifactId>user-provider</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.1.RELEASE</version>
        <relativePath/>
    </parent>

    <properties>
        <java.version>8</java.version>
        <spring-boot.version>2.2.1.RELEASE</spring-boot.version>
        <dubbo.version>2.7.5</dubbo.version>
        <curator.version>2.12.0</curator.version>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
    </properties>
    
    <dependencies>
        <!--MVC框架-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!--dubbo-->
        <dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>${dubbo.version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo-dependencies-zookeeper</artifactId>
            <version>${dubbo.version}</version>
            <type>pom</type>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>${curator.version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>${curator.version}</version>
        </dependency>
    </dependencies>
</project>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

设置各个服务的配置，两方面，一方面是zookeeper，一方面是dubbo的，如下：

（OrderService）

server:
  port: 8081
spring:
  application:
    name: dubbo-consumer
dubbo:
  registry:
    address: zookeeper://localhost:2181  # 连接到注册中心
  protocol:
    name: dubbo # 指定的协议
    port: 28081  # 指定的端口
  scan:
    basePackages: com.hzy.controller # 接口列表和接口中的方法列表
1
2
3
4
5
6
7
8
9
10
11
12
13

（UserService）

server:
  port: 8082
spring:
  application:
    name: dubbo-provider
dubbo:
  registry:
    address: zookeeper://localhost:2181  # 连接到注册中心
  protocol:
    name: dubbo # 指定的协议
    port: 28082  # 指定的端口
  scan:
    basePackages: com.hzy.controller # 接口列表和接口中的方法列表
1
2
3
4
5
6
7
8
9
10
11
12
13

（4）启动

依次 启动用户服务、订单服务，没有报错说明项目注册到zookeeper没有问题；

打开zookeeper客户端，输入 ls /可查看到dubbo项，再输入ls /dubbo，可查看到注册的服务；

（5）使用

使用Dubbo非常简单，只需如下操作：

• 第一步：修改提供者Service注解，改为Dubbo依赖提供的；

• 第二步：将提供者的UserService接口复制一份到消费者这边来，注意结构要平行相同；

• 第三步：在消费者Controller层注入（引用）UserService接口；

• 第四步：直接调用UserService中的接口；

（6）测试

重启两个服务（注意先启动提供者），使用fastRequest测试；

（获取用户名）

（获取用户信息）

可以看到两个接口都可以正常返回，说明zookeeper+dubbo的结合已完成；

Dubbo特性

以下介绍Dubbo中的一些特性，更多特性用法可在官网中查看；

（1）启动检查

上面一直提到，需要先启动提供者，再启动消费者，这是因为消费者服务依赖于提供者，在启动时Dubbo会进行检查，发现提供者找不到会报错，程序启动失败。

可在消费者这边添加如下配置，取消启动检查

# 取消消费者检查
dubbo:
  consumer:
    check: false
1
2
3
4

再次启动就没有问题了

（2）地址缓存

地址缓存是指，消费者与提供者联系建立起来了，服务消费者会把提供者的接口地址缓存一份，此时注册中心宕机，该请求仍可以正常访问；

发送请求，没得问题；

关闭注册中心zookeeper；

两个服务一直在打印未知错误；

此时，访问刚刚的那个请求，仍然可以成功；

换个重启服务后没发过的请求，也可以访问；

（3）对象传输

使用Dubbo可以传输自定义对象，但需要注意对象需要实现序列号接口，不然会报错；

根据经验，凡是涉及到传输对象，都需要实现序列化接口，并且最好添加全参构造、无参构造，因为有些工具，底层可能是通过对象的全参构造来帮助我们实例化对象的。

（4）连接超时

Dubbo默认设置的连接超时是1秒，即当消费者发送的请求，1秒未得到返回即为超时，这个超时是可以设置的。

在提供者这边方法内设置2秒睡眠；

消费者发送请求，返回超时错误；

连接超时可以在消费者、提供者设置，并且可以在接口、方法上设置，优先级是消费者大于提供者，方法大于接口，如下我在消费者（@Reference）、提供者（@Service）双方设置超时时长；

（消费者，设置1500ms）

（提供者，设置3000ms）

（重启服务，发送请求，依旧报错，说明提供者设置的超时没有起作用，超时是以消费者的1500ms为准）

（互调设置，消费者设置3000ms，提供者1500ms，重启服务可以正常访问）

（5）重试次数

重试次数，在之前连接超时错误的信息，可以看到一个“Tried 3 times”，表示尝试了3次，默认重试2次；

同样，这个也可以在消费者、提供者双方设置

（提供者）

// 设置重试10次
@Service(timeout = 3000, retries = 10)
1
2

（消费者）

// 设置重试5次
@Reference(timeout = 1500, retries = 5)
private UserService userService;
1
2
3

同样，优先级是消费者大于提供者；

注意

需要注意哦，不是所有操作都可以设置重试次数的，应该需要考虑当前请求所对应的操作是否为幂等性操作，即执行一次或多次结果都相同，不然会造成数据混乱。以数据库的增删改查操作为例：

• 增：每增加一条数据，数据库表都是变化的，所以为非幂等性；

• 删：与增同理，是非幂等性；

• 改：视情况而定，看SQL语句是怎么写的，如果是"number + 1"这样的，是非幂等性；如果是“set name = #{name} where id = #{id}”这样的，就是幂等性的；

• 查：多次查询（没有其他操作参与）数据库表都是一样的，所以是幂等性操作；

（6）多版本

多版本是指，如果存在多个提供者、消费者时，可以指定版本信息，让提供者指服务指定的消费者，消费者指消费指定的服务者；

（消费者，不指定版本信息）

@Reference(timeout = 3000, retries = 5)
private UserService userService;
1
2

（提供者，指定版本信息“V1.0”）

@Service(timeout = 3000, retries = 10, version = "V1.0")
1

请求失败，提示没有可用的提供者；

修改消费者版本号为“V1.0”；

@Reference(timeout = 3000, retries = 5,version = "V1.0")
1

请求访问成功；

使用Dubbo的这种特性，可以实现灰度发布，即版本更新不是一下全部更新，而是在系统中设置多个版本，如新版本的接口设置10个，旧版本的接口设置5个，实现“缓更新，慢发布”，减少系统出现异常的风险，比如一些金融、支付类的软件。

（7）负载均衡

可使用“loadbalance”属性设置接口的负载均衡策略，支持以下四种策略：

• RandomLoadBalance：加权随机，默认算法，默认权重相同；

• RoundRobinLoadBalance：加权轮询，默认权重相同；

• LeastActiveLoadBalance：最少活跃优先+加权随机，能者多劳；

• ConsistentHashLoadBalance：一致性Hash，确定入参，确定提供者，适用于有状态的请求；

注意使用并不是直接new它们类，而是进入到它们对应的类里面，查看它们的这行代码中写的名称

将该名称作为负载均衡属性的值

@Reference(loadbalance = "random")
private UserService userService;
1
2

在代码中打印一行标识，开启两个服务，发送十几条请求，可以看到两边服务均有访问，数量不等；

提供者，消费者两边都可以设置，都有效；

（8）失败降级

失败降级是指访问失败时，返回一个降级方案，即“打了折扣”的响应结果，使用mock属性设置，如下：

@Reference(mock = "return 请求错误")
private UserService userService;
1
2

另外，还可以有其他几种用法：

#  调用失败，返回请求错误
mock = "return 请求错误"

# 不发起远程调用，直接返回null，不管请求成功与否，都返回null
mock = "force:return null"

# 发起远程调用，失败后返回null
mock = "fail:return null"

# 发起远程调用，失败后抛异常
mock = "throw"

# 调用失败后使用自己实现的降级方案
mock = "自定义类的全限定类名"
1
2
3
4
5
6
7
8
9
10
11
12
13
14

其中，最后一种方法最好用，搞一下

---

降级降级方案，实现接口就可以

public class UserServiceMock implements UserService {
    @Override
    public String getUserName(Integer id) {
        return "降级方案";
    }

    @Override
    public User getUser(Integer id) {
        return new User(-1,"降级对象","降级密码");
    }
}
1
2
3
4
5
6
7
8
9
10
11

mock设置为降级方案的全限定类名

    @Reference(mock = "com.hzy.mock.UserServiceMock")
    private UserService userService;
1
2

测试，连接超时，走了降级

（9）集群容错

使用场景（官方）；多个服务器部署同一集群中，运行同一应用程序，如果一台服务器出现故障，其他服务器将接管负载，确保应用程序对用户仍然可用。

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

其他配置如下：

使用如下：

@Reference(cluster = "failover")
private UserService userService;
1
2

同样，也是使用对应的策略，就进入到对应的类中，使用对应的名称作为属性值；

Nacos+Dubbo

Nacos作为注册中心Dubbo使用与ZooKeeper基本相同，在使用上，不同的地方只有以下两点：

• 导入的依赖，配置不同；

• 注解不同，ZooKeeper使用@Service、@Reference注解；Nacos使用@DubboService、@DubboReference注解；

总结

总结成一句话，Dubbo是替代Feign的；

另外提一句，Dubbo是使用自定义的协议，所以如果需要考虑提高Dubbo效率，可以从传输协议、对象序列化方式这些方面入手；

文中代码的GitHub地址：https://github.com/Heapfiy/dubbo-simple.git