说明：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);
}
}
用户服务（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;
}
}
（3）配置
使用Dubbo前，需先导入依赖，我这里直接在父模块中添加，如下：
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">
设置各个服务的配置，两方面，一方面是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 # 接口列表和接口中的方法列表
（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 # 接口列表和接口中的方法列表
（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
再次启动就没有问题了
（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)
（消费者）
// 设置重试5次
@Reference(timeout = 1500, retries = 5)
private UserService userService;
同样，优先级是消费者大于提供者；
注意
需要注意哦，不是所有操作都可以设置重试次数的，应该需要考虑当前请求所对应的操作是否为幂等性操作，即执行一次或多次结果都相同，不然会造成数据混乱。以数据库的增删改查操作为例：
增：每增加一条数据，数据库表都是变化的，所以为非幂等性； 删：与增同理，是非幂等性； 改：视情况而定，看SQL语句是怎么写的，如果是"number + 1"这样的，是非幂等性；如果是“set name = #{name} where id = #{id}”这样的，就是幂等性的； 查：多次查询（没有其他操作参与）数据库表都是一样的，所以是幂等性操作；
（6）多版本
多版本是指，如果存在多个提供者、消费者时，可以指定版本信息，让提供者指服务指定的消费者，消费者指消费指定的服务者；
（消费者，不指定版本信息）
@Reference(timeout = 3000, retries = 5)
private UserService userService;
（提供者，指定版本信息“V1.0”）
@Service(timeout = 3000, retries = 10, version = "V1.0")
请求失败，提示没有可用的提供者；
修改消费者版本号为“V1.0”；
@Reference(timeout = 3000, retries = 5,version = "V1.0")
请求访问成功；
使用Dubbo的这种特性，可以实现灰度发布，即版本更新不是一下全部更新，而是在系统中设置多个版本，如新版本的接口设置10个，旧版本的接口设置5个，实现“缓更新，慢发布”，减少系统出现异常的风险，比如一些金融、支付类的软件。
（7）负载均衡
可使用“loadbalance”属性设置接口的负载均衡策略，支持以下四种策略：
RandomLoadBalance：加权随机，默认算法，默认权重相同； RoundRobinLoadBalance：加权轮询，默认权重相同； LeastActiveLoadBalance：最少活跃优先+加权随机，能者多劳； ConsistentHashLoadBalance：一致性Hash，确定入参，确定提供者，适用于有状态的请求；
注意使用并不是直接new它们类，而是进入到它们对应的类里面，查看它们的这行代码中写的名称
将该名称作为负载均衡属性的值
@Reference(loadbalance = "random")
private UserService userService;
在代码中打印一行标识，开启两个服务，发送十几条请求，可以看到两边服务均有访问，数量不等；
提供者，消费者两边都可以设置，都有效；
（8）失败降级
失败降级是指访问失败时，返回一个降级方案，即“打了折扣”的响应结果，使用mock属性设置，如下：
@Reference(mock = "return 请求错误")
private UserService userService;
另外，还可以有其他几种用法：
# 调用失败，返回请求错误
mock = "return 请求错误"
# 不发起远程调用，直接返回null，不管请求成功与否，都返回null
mock = "force:return null"
# 发起远程调用，失败后返回null
mock = "fail:return null"
# 发起远程调用，失败后抛异常
mock = "throw"
# 调用失败后使用自己实现的降级方案
mock = "自定义类的全限定类名"
其中，最后一种方法最好用，搞一下
降级降级方案，实现接口就可以
public class UserServiceMock implements UserService {
@Override
public String getUserName(Integer id) {
return "降级方案";
}
@Override
public User getUser(Integer id) {
return new User(-1,"降级对象","降级密码");
}
}
mock设置为降级方案的全限定类名
@Reference(mock = "com.hzy.mock.UserServiceMock")
private UserService userService;
测试，连接超时，走了降级
（9）集群容错
使用场景（官方）；多个服务器部署同一集群中，运行同一应用程序，如果一台服务器出现故障，其他服务器将接管负载，确保应用程序对用户仍然可用。
Failover Cluster（默认设置）：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。
其他配置如下：
使用如下：
@Reference(cluster = "failover")
private UserService userService;
同样，也是使用对应的策略，就进入到对应的类中，使用对应的名称作为属性值；
Nacos+Dubbo
Nacos作为注册中心Dubbo使用与ZooKeeper基本相同，在使用上，不同的地方只有以下两点：
导入的依赖，配置不同； 注解不同，ZooKeeper使用@Service、@Reference注解；Nacos使用@DubboService、@DubboReference注解；
总结
总结成一句话，Dubbo是替代Feign的；
另外提一句，Dubbo是使用自定义的协议，所以如果需要考虑提高Dubbo效率，可以从传输协议、对象序列化方式这些方面入手；
文中代码的GitHub地址：https://github.com/Heapfiy/dubbo-simple.git
精彩文章
您阅读本篇文章共花了：
发表评论