一、引入Dubbo3
不会介绍 Dubbo 如何使用,咱只提一嘴,然后说如何去测试 Dubbo 服务。Dubbo3 除了保持 2.x 的经典架构之外,还以解决微服务的进程通信为主要职责,通过丰富的服务治理能力来更好的管控微服务服务集群,简称更牛逼了,原功能还在。
Dubbo 的调用流程如下:
整体流程可大致分为如下11步(以默认通信方式Netty概述下面内容):
- 首先服务提供者会启动,然后将服务注册到服务注册中心(此时什么服务的 host、port 等元数据在注册中心中,除了netty服务的信息外,还有@DubboService标志的接口也会当做服务注册上去);
- 服务消费者会定时拉取服务提供者列表;
- 当服务消费者需要调用服务提供者接口的时候,因为他不能直接远程调用提供者的接口,所以需要生成一个动态代理对象,然后通过这个代理对象去调用远程接口。
- 生成代理对象之后会走到 Cluster 层,这里会获取服务提供者列表的数据,感知到目前所能调用的服务提供者有哪些;
- 然后 Cluster 会根据指定的算法做负载均衡,选出要调用的服务提供者;
- Exchange 会根据指定的协议格式进行请求数据封装,封装成 request 请求;
- 请求封装好之后,就会通过网络通信框架,将请求发送出去(TCP嘛,长连接,懂得都懂);
- 服务提供者那边通用会有网络通信框架,他会监听指定的端口号,当接收到请求之后会将请求进行反序列化;
- 反序列化后,再根据 Exchange 根据指定协议格式将请求解析出来;
10.然后再通过动态代理对象调用服务提供者对应的接口。
二、Dubbo 接口调试方式列举
可以在网上搜到的 Dubbo 服务调试方式应该就俩吧,强行说的话可以列三个:
- Telnet
- Jmeter
- 写服务消费端进行测试
咱说说他三给我个人的感觉哈,哪不好:
-
Telnet工具,使用很简单,Windows自身就携带,直接打命令就可以了,然后去对对应服务进行测试,但是他不能结合注册中心,以我个人使用来看,不整合个人中心就不能更好的服务治理,这往往是脱离实际开发的。主要还是不是可视化!!!
-
Jmeter:Jmeter无疑是强大的测试工具,他本身是不能对Dubbo进行测试的,但是可以使用github上开源的Jmeter-plugins-for-apache-dubbo插件,遗憾的是啥?是它不支持3.x啊,官网阐述如下(当然本人也帮你们测过):
-
emmmm,编写dubbo服务消费端然后进行测试,这…这就应该把这俩服务之间的流程写完才能测试吧?我代码能力还没那么强,还是比较写一部分测一部分;而且这也对多人开发也不好测试的。
但是我很幸运,昨天晚上没啥事干想看看别人技术博文的,然后你看我瞄到了啥:
看看里面提到啥,昨晚看到的,这不今天有空测试过了就分享出来了:
(应该是最近才支持的吧,我也找不着apifox的版本迭代,现在最新是2.3.24,官网说apifox要>=2.3.10才支持)
不管了,先用起来吧。
三、Apifox 调试 Dubbo 项目
以测试为主,咱这用nacos作为注册中心进行测试一手 Apifox 是咋调试 Dubbo 服务滴:
服务提供端代码
配置文件
server:
port: 8082
spring:
application:
name: dubbo-provider-test
datasource:
password: 123456
username: root
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/mybatisplus
mybatis-plus:
type-aliases-package: com.example.mp1.entity
mapper-locations: classpath:/mapper/**/*.xml
global-config:
banner: false
db-config:
id-type: assign_id
configuration:
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
dubbo:
protocol:
name: dubbo
port: -1
application:
name: dubbo-test
registry:
address: nacos://127.0.0.1:8848
username: nacos
password: nacos
register: true
nacos:
config:
server-addr: 127.0.0.1:8848
服务接口
public interface DubboTestService {
User getUserById(Long id);
}
服务实现
@DubboService
@Service
public class DubboTestServiceImpl implements DubboTestService {
@Autowired
UserService userService;
@Override
public User getUserById(Long id) {
User user = userService.getById(id);
return user;
}
}
启动服务后,nacos 服务列表如下:
Apifox 测试
首先得创建一个Dubbo项目,即用来测试Dubbo服务用的模块
导入 Dubbo 应用数据,这个应用是指你在配置文件里配置的应用,说再直白点就是 netty 服务的元数据信息最后存在 nacos 配置中心中的服务名。
填写应用信息后然后导入进去
然后你在接口管理中就可以看到对应的服务了,easy!
测试的时候记得填对应的服务 ip:port,因为是要通过它进行远程调用的,封装一下然后向 netty 服务进行写这个请求数据,然后最后的结果再响应回来,这不就是长连接所干的通信的活吗。
这不就好了
如果不使用注册中心呢?也是可以测试的,但那就要自己去写服务接口和方法,然后去填一下服务的 ip:port ,然后进行测试,有这种图形化界面,测试起来还是方便多了的。
四、Long 数据传输可能引发精度丢失
因为我那表里的数据有些是雪花算法生成的数据嘛,然后我测试的时候发现精度丢失了,就去了解了一下。
这是由于 Dubbo 默认使用的是 Hessian 作为序列化协议,而 Hessian 在序列化长整数型的数据就会存在精度丢失。
给你看看测试哈:
看我表里是有这个记录的,第一列是id:
这里的话进行个服务测试:
可以发现,原本的 1710123046640713730 变成了 1710123046640713728,少了2,即精度丢失了嘛。
解决方式:
- 从类型本质上解决,将其换成 String 类型,这样就不会出现精度丢失了。
- 自定义序列化方式,或者使用 Dubbo 其他不会导致精度丢失的序列化协议。
emmmm,这也算是测试得出来的经验吧。