dubbo的服务consumer与provider使用的api版本不一致，是否有影响

　　　　　　　　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>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是不同版本的，可能会在业务上有影响。应该避免出现这种不规范的使用！