说明:Apache Dubbo 是一款 RPC 服务开发框架,用于解决微服务架构下的服务治理与通信问题,官方提供了 Java、Golang 等多语言 SDK 实现。
本文介绍Dubbo的简单使用及一些Dubbo功能特性,注册中心使用的是ZooKeeper,可在官网下载。
(另外,在阿里巴巴发出的《微服务治理技术白皮书》中各种注册中心的区别如下:)
首先,搭建一个ZooKeeper + Dubbo的项目
在上面提供的官网上下载ZooKeeper,解压到一个没有中文的路径下;
因为默认提供的配置文件是一个模板,解压后需要手动设置一下,将zookeeper默认的配置文件(zoo_sample.cfg)复制一份,并将文件名改为"zoo.cfg"
另外,修改zoo.cfg配置文件中的这行配置,默认的是Linux文件路径,修改为当前目录的上级目录(…/data);
启动,选择安装目录下bin文件夹下的zkServer.cmd
文件,可双击启动或者在该目录下打开CMD窗口执行
没有报错,运行结果如下,表示启动成功
如果启动失败,提示此时不应有 jdk
,参考:http://t.csdn.cn/52O2K
创建一个Zookper+Dubbo的项目,有两个微服务,一个用户服务(UserService),一个订单服务(OrderService),
订单服务(消费者,Consumer):没有Service层,直接使用用户服务查询用户信息、用户名;
用户服务(提供者,Provider):没有Controller层,提供查询用户信息、用户名的接口;
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实现类,实现两个接口,分别是查询用户名,返回固定值;查询用户,返回固定用户对象;
@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;
}
}
使用Dubbo前,需先导入依赖,我这里直接在父模块中添加,如下:
<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.0modelVersion>
<groupId>com.hzygroupId>
<artifactId>user-providerartifactId>
<version>1.0-SNAPSHOTversion>
<packaging>jarpackaging>
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.2.1.RELEASEversion>
<relativePath/>
parent>
<properties>
<java.version>8java.version>
<spring-boot.version>2.2.1.RELEASEspring-boot.version>
<dubbo.version>2.7.5dubbo.version>
<curator.version>2.12.0curator.version>
<maven.compiler.source>11maven.compiler.source>
<maven.compiler.target>11maven.compiler.target>
properties>
<dependencies>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.apache.dubbogroupId>
<artifactId>dubbo-spring-boot-starterartifactId>
<version>${dubbo.version}version>
dependency>
<dependency>
<groupId>org.apache.dubbogroupId>
<artifactId>dubbo-dependencies-zookeeperartifactId>
<version>${dubbo.version}version>
<type>pomtype>
<exclusions>
<exclusion>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-log4j12artifactId>
exclusion>
exclusions>
dependency>
<dependency>
<groupId>org.apache.curatorgroupId>
<artifactId>curator-frameworkartifactId>
<version>${curator.version}version>
dependency>
<dependency>
<groupId>org.apache.curatorgroupId>
<artifactId>curator-recipesartifactId>
<version>${curator.version}version>
dependency>
dependencies>
project>
设置各个服务的配置,两方面,一方面是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 # 接口列表和接口中的方法列表
依次 启动用户服务、订单服务,没有报错说明项目注册到zookeeper没有问题;
打开zookeeper客户端,输入 ls /
可查看到dubbo项,再输入ls /dubbo
,可查看到注册的服务;
使用Dubbo非常简单,只需如下操作:
第三步:在消费者Controller层注入(引用)UserService接口;
第四步:直接调用UserService中的接口;
重启两个服务(注意先启动提供者),使用fastRequest测试;
(获取用户名)
(获取用户信息)
可以看到两个接口都可以正常返回,说明zookeeper+dubbo的结合已完成;
以下介绍Dubbo中的一些特性,更多特性用法可在官网中查看;
上面一直提到,需要先启动提供者,再启动消费者,这是因为消费者服务依赖于提供者,在启动时Dubbo会进行检查,发现提供者找不到会报错,程序启动失败。
可在消费者这边添加如下配置,取消启动检查
# 取消消费者检查
dubbo:
consumer:
check: false
再次启动就没有问题了
地址缓存是指,消费者与提供者联系建立起来了,服务消费者会把提供者的接口地址缓存一份,此时注册中心宕机,该请求仍可以正常访问;
发送请求,没得问题;
关闭注册中心zookeeper;
两个服务一直在打印未知错误;
此时,访问刚刚的那个请求,仍然可以成功;
换个重启服务后没发过的请求,也可以访问;
使用Dubbo可以传输自定义对象,但需要注意对象需要实现序列号接口,不然会报错;
根据经验,凡是涉及到传输对象,都需要实现序列化接口,并且最好添加全参构造、无参构造,因为有些工具,底层可能是通过对象的全参构造来帮助我们实例化对象的。
Dubbo默认设置的连接超时是1秒,即当消费者发送的请求,1秒未得到返回即为超时,这个超时是可以设置的。
在提供者这边方法内设置2秒睡眠;
消费者发送请求,返回超时错误;
连接超时可以在消费者、提供者设置,并且可以在接口、方法上设置,优先级是消费者大于提供者,方法大于接口,如下我在消费者(@Reference)、提供者(@Service)双方设置超时时长;
(消费者,设置1500ms)
(提供者,设置3000ms)
(重启服务,发送请求,依旧报错,说明提供者设置的超时没有起作用,超时是以消费者的1500ms为准)
(互调设置,消费者设置3000ms,提供者1500ms,重启服务可以正常访问)
重试次数,在之前连接超时错误的信息,可以看到一个“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}”这样的,就是幂等性的;
查:多次查询(没有其他操作参与)数据库表都是一样的,所以是幂等性操作;
多版本是指,如果存在多个提供者、消费者时,可以指定版本信息,让提供者指服务指定的消费者,消费者指消费指定的服务者;
(消费者,不指定版本信息)
@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个,实现“缓更新,慢发布”,减少系统出现异常的风险,比如一些金融、支付类的软件。
可使用“loadbalance”属性设置接口的负载均衡策略,支持以下四种策略:
RandomLoadBalance:加权随机,默认算法,默认权重相同;
RoundRobinLoadBalance:加权轮询,默认权重相同;
LeastActiveLoadBalance:最少活跃优先+加权随机,能者多劳;
ConsistentHashLoadBalance:一致性Hash,确定入参,确定提供者,适用于有状态的请求;
注意使用并不是直接new它们类,而是进入到它们对应的类里面,查看它们的这行代码中写的名称
将该名称作为负载均衡属性的值
@Reference(loadbalance = "random")
private UserService userService;
在代码中打印一行标识,开启两个服务,发送十几条请求,可以看到两边服务均有访问,数量不等;
提供者,消费者两边都可以设置,都有效;
失败降级是指访问失败时,返回一个降级方案,即“打了折扣”的响应结果,使用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;
测试,连接超时,走了降级
使用场景(官方);多个服务器部署同一集群中,运行同一应用程序,如果一台服务器出现故障,其他服务器将接管负载,确保应用程序对用户仍然可用。
Failover Cluster(默认设置):失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。
其他配置如下:
使用如下:
@Reference(cluster = "failover")
private UserService userService;
同样,也是使用对应的策略,就进入到对应的类中,使用对应的名称作为属性值;
Nacos作为注册中心Dubbo使用与ZooKeeper基本相同,在使用上,不同的地方只有以下两点:
导入的依赖,配置不同;
注解不同,ZooKeeper使用@Service、@Reference注解;Nacos使用@DubboService、@DubboReference注解;
总结成一句话,Dubbo是替代Feign的;
另外提一句,Dubbo是使用自定义的协议,所以如果需要考虑提高Dubbo效率,可以从传输协议、对象序列化方式这些方面入手;
文中代码的GitHub地址:https://github.com/Heapfiy/dubbo-simple.git