Dubbo学习笔记(二) Dubbo的基本配置

Check启动检查

根据之前的学习，我们简单理解的Dubbo远程调用的基本流程，服务提供者注册到注册中心，然后服务消费者通过监听注册中心达到远程调用的目的，那么如果注册中心中没有消费者对应的接口会怎么样呢？

开启Zookeeper，在不运行服务提供者的情况下直接运行消费者，结果是：

// 抛出了异常信息
java.lang.reflect.InvocationTargetException: null
// 其中可以看到有价值的异常信息为：
Failed to check the status of the service site.hanzhe.service.UserService. No provider available for the service site.hanzhe.service.UserService from the url zookeeper://127.0.0.1:2181/com.alibaba.dubbo ......

大致含义为我们通过@Reference注解进行远程调用，但是注册中心中并没有对应的服务所以报错

这样依赖我们就知道了远程调用是在程序初始化的时候就已经与远程服务建立连接了，现在我们不希望它初始化时连接，我们希望在真正用到它的时候再进行连接，这样我们提供者就可以随时注册上去提供服务，想要实现这个功能可以利用注解中的check属性：

@RestController
public class UserController {
    @Reference(check = false)
    private UserService userService;

    @GetMapping("/selectUser")
    public List<UserEntity> selectUse() {
        return userService.selectList();
    }
}

check属性为启动检查，默认值为true，当我们设置为false之后启动就不报错了，然后随时启动提供者进行远程调用

通过设置@Reference的check属性可以关闭启动检查，但是如果我们程序中存在着大量的远程接口就不方便操作了，这里Dubbo为我们提供了一个全局的消费者配置：

# 通过设置dubbo.consumer.check属性来设置消费者所有远程接口的启动检查
dubbo:
  consumer:
    check: false

这时候我们在移除@Reference的check属性，也可以实现相同的功能，且一劳永逸！

Timeout超时时间

Dubbo是一款RPC远程调用框架，远程调用肯定离不开网络，那么如果在远程调用的时候时间过长应该怎么处理？

做一个测试，在服务提供者中返回结果之前做一个阻塞效果：

@Service
@com.alibaba.dubbo.config.annotation.Service
public class UserServiceImpl implements UserService {

    @Override
    public List<UserEntity> selectList() {
        UserEntity entity1 = new UserEntity("马保国", "69", "男");
        UserEntity entity2 = new UserEntity("张全蛋", "31", "男");
        try {
            // 这里让该线程睡2秒钟
            Thread.sleep(2000);
        } catch (InterruptedException e) { }
        return Arrays.asList(entity1, entity2);
    }

}

然后在消费者进行远程调用测试，抛出了如下异常：

com.alibaba.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer ...

简单来说就是服务端响应太慢请求超时了，通过查看官网可知道默认的超时时间为1000ms，也就是说当请求超过1秒就会被抛弃，但是有些时候1秒有些太短，这里在消费者方通过@Reference的timeout属性手动设置超时时间：

@RestController
public class UserController {
    @Reference(check = false, timeout = 3000)
    private UserService userService;

    @GetMapping("/selectUser")
    public List<UserEntity> selectUse() {
        return userService.selectList();
    }
}

在远程调用时设置超时时间为三秒，这样一来就可以调用成功了！和检查属性一样，超时时间也可以全局设置：

# 通过设置dubbo.consumer.check属性来设置消费者所有远程接口的启动检查
dubbo:
  consumer:
    check: false
    timeout: 3000

Retries请求重发

我们可以通过延长请求超时时间来提高稳定率，但如果出现了意外情况在规定的时间内也没能完成操作，那么我们就需要进行重发进行操作了：

@RestController
public class UserController {
    // retries当请求失败后，重新发送该请求，设置重发次数最多为2次
    // 加上本身的一次也就是一共3次请求，如果3次都失败那就是真正的失败
    @Reference(check = false, retries=2)
    private UserService userService;

    @GetMapping("/selectUser")
    public List<UserEntity> selectUse() {
        return userService.selectList();
    }
}

我们在服务提供者中使用打印语句来观察请求的次数，可以看到的确调用了三次：

关于请求重发

并不是所有请求都可以进行请求重发的，原则上只有幂等可以设置重发，非幂等不可以设置重发

• 幂等：类似delete、update、select操作多次执行并不会对数据造成影响
• 非幂等：类似inert操作多次执行可能会造成不可控的后果

当然这只是原则，实际上还需要根据业务逻辑来判断是否可以使用，例如UPDATE user SET number = number + #{number} .. 就不适合重发

Version多版本

服务提供者通过实现接口，暴露出接口的实现类，从而在消费者端实现远程调用，在服务者暴露接口时可以针对某一个接口暴露多个实现类，每个实现类有着自己的版本号，通过版本号来控制调用哪个实现

@Service
// 设置当前service实现版本为v1
@com.alibaba.dubbo.config.annotation.Service(version="v1")
public class UserServiceImpl implements UserService {

    @Override
    public List<UserEntity> selectList() {
        UserEntity entity1 = new UserEntity("马保国", "69", "男");
        UserEntity entity2 = new UserEntity("张全蛋", "31", "男");
        return Arrays.asList(entity1, entity2);
    }

}

@Service
// 复制一个实现，修改版本为v2，并修改数据内容
@com.alibaba.dubbo.config.annotation.Service(version="v1")
public class UserServiceImpl implements UserService {

    @Override
    public List<UserEntity> selectList() {
        UserEntity entity1 = new UserEntity("马保国", "69", "女");
        UserEntity entity2 = new UserEntity("张全蛋", "31", "女");
        return Arrays.asList(entity1, entity2);
    }

}

然后在消费者端通过修改Reference注解的version属性来控制调用：

@RestController
public class UserController {
    @Reference(check = false, retries=2, version = "v1")
    private UserService userService;

    @GetMapping("/selectUser")
    public List<UserEntity> selectUse() {
        return userService.selectList();
    }
}

启动当前消费者，然后将v1修改为v2，修改端口号来启动第二个消费者，分别调用两个接口，结果为：

Stub本地存根

本地存根，指的是除开远程调用的实现之外，自己本地也有实现，且可以根据参数来决定是否使用本地实现

在消费者端创建一个接口的实现类：

// 这个实现类就是本地存根类
public class UserServiceImpl implements UserService {
    // 这里用来存放远程调用的service对象
    private final UserService userService;
    // 远程对象通过构造方法传入
    public UserServiceImpl(UserService userService) {
        this.userService = userService;
    }
    // 复写方法中根据各种情况来判断是否使用远程实例
    @Override
    public List<UserEntity> selectList() {
        try {
            return userService.selectList();
        } catch (Exception e) {
            System.err.println("远程调用出现异常！");
            return null;
        }
    }

}

然后在controller位置的@Reference注解使用stub属性，属性值为本地存根的类的全路径名：

@RestController
public class UserController {

    @Reference(check = false, stub = "site.hanzhe.service.impl.UserServiceImpl")
    private UserService userService;

    @GetMapping("/selectUser")
    public List<UserEntity> selectUse() {
        return userService.selectList();
    }

}

可以在服务提供者的位置模拟异常来查看是否设置成功