dubbo的服务consumer与provider使用的api版本不一致，是否有影响
最近新接手一个项目，看到定义的dubbo接口有些很奇葩的设定。
一、消费端 与 服务端 调用的接口中的数据包装类型中的数据长度不一样。例如：A类(int num , String phone ，String address) version-0.2 , 消费端用的是0.1版本的A类（int num,String phone ,String address）version-0.1 ; 由于各种原因无法直接在项目上验证，因此决定自己模拟一次情况来看看实际情况,到底消费者能不能成功调用服务；
环境限定：
<groupId>io.dubbo.springboot</groupId>
<artifactId>spring-boot-starter-dubbo</artifactId>
<version>1.0.0</version>
provider 的 api包(版本为0.0.2 ，红线字段就是0.0.2版本新增的字段)：
consumer 引用的provider的api包是0.0.1版本的，也就是说没有"address"这个字段:
consumer调用provider的Controller：
@RestController
@RequestMapping("/test")
public class Controller { @Autowired
private Service service; @RequestMapping("/hello")
public String hello(){
return service.hello();
} }
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是不同版本的，可能会在业务上有影响。应该避免出现这种不规范的使用！
