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是不同版本的，可能會在業務上有影響。應該避免出現這種不規范的使用！