dubbo的服务consumer与provider使用的api版本不一致,是否有影响
最近新接手一个项目,看到定义的dubbo接口有些很奇葩的设定。
一、消费端 与 服务端 调用的接口中的数据包装类型中的数据长度不一样。例如:A类(int num , String phone ,String address) version-0.2 , 消费端用的是0.1版本的A类(int num,String phone )version-0.1 ; 由于各种原因无法直接在项目上验证,因此决定自己模拟一次情况来看看实际情况,到底消费者能不能成功调用服务;
环境限定:
<groupId>io.dubbo.springboot</groupId>
</artifactId>
</version>
provider 的 api包(版本为0.0.2 ,红线字段就是0.0.2版本新增的字段):
consumer 引用的provider的api包是0.0.1版本的,也就是说没有"address"这个字段:
consumer调用provider的Controller:
1 @RestController
2 @RequestMapping("/test")
3 public class Controller {
4
5 @Autowired
6 private Service service;
7
8 @RequestMapping("/hello")
9 public String hello(){
10 return service.hello();
11 }
12
13
14 }
consuer的Service:
@org.springframework.stereotype.Service
public class Service {
@Reference
private TestService testService;
public String hello(){
TestParam param=TestParam.builder().age(20).name("李二").build();
return testService.test(param).getMsg();
}
}
注意: controller是注入的spring的service, 然后在service里再注入dubbo的TestService.为什么不直接在controller立注入dubbo的TestService了?因为直接在controller层是无法注入dubbo的服务的,具体原因是因为spring与dubbo生命周期问题。详情就不赘述了,记住一点,不能在controller直接注入dubbo的服务来使用.
provider 的 TestService的实现:
import com.alibaba.dubbo.config.annotation.Service;
import com.zxl.dubbo.dto.Response;
import com.zxl.dubbo.dto.TestParam;
@Service
public class TestServiceImpl implements TestService {
@Override
public Response test(TestParam param) {
return Response.builder().code(200).msg("hello").data(null).build();
}
}
就是直接返回一个hello.
现在我们来看一下结果,我是通过访问controller提供的url来触发调用provider:
可以看到,成功返回了消息内容“hello”.
那么问题来了,consumer与provider两端使用的 TestParam的属性内容都不一样,是如何成功解析传给provider的消息了?
```````, 花了好几个小时去debug看,由于中间步骤很多,这里就不贴图描述了。能解析成功的最主要原因是采用了hessian序列化。具体为什么hessian序列化能实现这种不同版本的兼容,下面贴一个关于hessian序列化的连接: https://www.jianshu.com/p/6a36dd1fcca8
里面关键的部分就是下面这一句:
。从目前得到的信息可以看出,服务端与消费端使用的bean版本不同,并没有影响到服务的调用,原因就是由于hessian序列化。为了证实这种情况,修改序列化方式,再进行测试:
配置中修改序列化方式,使用java自带的序列化:
dubbo:
application:
name: consumer
registry:
address: zookeeper://127.0.0.1:2181
protocol:
name: dubbo
port: 20888
serialization: java
scan: com.zxl.dubbo
访问url,查看结果:
返回消息明确说了是由于“解码失败”。
综合以上可以得出结论:dubbo采用默认的hessian序列方式,可以兼容消费端与服务端使用的bean版本不同。
虽然这种情况不会影响服务调用,但是由于两端使用的bean是不同版本的,可能会在业务上有影响。应该避免出现这种不规范的使用!