以下内容摘自雪球,在公司内部的docs上的内容总结,部分隐私信息已经处理改动
问题:
在进行项目的升级springboot的过程中遇到之前的旧项目没有进行升级,导致旧的项目想要调用新的项目的grpc接口,出现了UNKNOWN的异常
新版本的服务注册上多了enable这个字段,老版本反序列化失败,zk注册的data数据多出了一个enable字段:
完整的错误信息栈如下:
|
分析:
根据以上信息基本上可以定位到是服务的注册发现部分的问题,那么在curator 2.11.X到2.12.X的升级过程中是相互不兼容的(最起码在springboot的2.X版本中使用的curator版本是2.12.X的)
那么根据报错的信息栈,在google上搜到了一下相关信息:
在curator的官方jira上找到,有人遇见过类似问题
https://issues.apache.org/jira/browse/CURATOR-275
(curator这个玩意儿真牛逼,竟然不向下兼容)
查询
ServiceInstance的源码文档
https://curator.apache.org/apidocs/org/apache/curator/x/discovery/ServiceInstance.html
发现了这么一段话:用important标注说:enable这个字段针对于上面的那个bug,是已经通过方法的重载来兼容这个字段
但是,项目的服务注册发现并不是直接使用的自研metadata注册信息,而是采用了springboot的discover模块
那么问题至此就很明显了,对于这个enable的字段,要是想要在技术层面进行解决的话,就需要进行源码的改造
但是结合实际情况,源码改造会影响到以后的版本升级和维护,那么最好的办法就是找到一个折中的方案
解决:
基本情况已经确定:这个问题会出现在低版本调用高版本中,同版本调用没事,跨版本会出现问题
那么能做的就是在11.X的低版本调用12.X的高版本的过程中,要注意到curator的兼容
解决方案如下:
对于这个curator-x-discovery这个依赖使用2.12.0的
本地exclusion掉那个低版本的
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zookeeper-discovery</artifactId>
<exclusions>
<exclusion>
<artifactId>curator-x-discovery</artifactId>
<groupId>org.apache.curator</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<artifactId>curator-x-discovery</artifactId>
<groupId>org.apache.curator</groupId>
<version>2.12.0</version>
</dependency>
结论:
由基础架构组发布一个版本,来做低版本往高版本调用的兼容
后续的使用中针对目前各个项目组的调用情况,先将服务的下游依赖方进行版本升级,此过程需要服务的参与者都协调起来
参考链接:
https://cwiki.apache.org/confluence/display/CURATOR/Releases
https://issues.apache.org/jira/browse/CURATOR-394
https://issues.apache.org/jira/browse/CURATOR-275
https://curator.apache.org/apidocs/org/apache/curator/x/discovery/ServiceInstance.html
https://github.com/spring-cloud/spring-cloud-consul/issues/404