一、引入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，这也算是测试得出来的经验吧。