spring-boot-starter 由 2.2.13.RELEASE 升级到 2.6.15 的踩坑经历

上一次把 spring-boot-starter 由 2.1.4.release 升级到 2.2.13.RELEASE，本以为稳妥了，经验丰富的网友给我留言：直接升到 2.6.x 没有问题。

网友的宝贵经验可不能浪费，今天俺也来试试。

一个成功，一个失败，踩的坑真不少。

一、升级成功的案例

先找一个小项目，把 spring-boot-starter 由 2.2.13.RELEASE 升级到 2.6.15。

由于项目中只用到了一个 spring-cloud 相关的框架 spring-cloud-starter-openfeign，因此没有单独对 spring-cloud-dependencies 进行依赖管理，而是提高了 spring-cloud-starter-openfeign 的版本号。然后更新项目的依赖，运行项目。

更新依赖后，有一处代码报错，RedisTemplate模板的，在旧版本的游标 Cursor 调用 close() 方法后会抛 IOException，而这个版本不抛异常。把这个捕捉异常的去掉即可。

运行项目，控制台报了一个错，大概意思是：创建Bean失败，这是为什么呢？

从错误栈来看，问题出现在 Spring Cloud 自动配置类 ConfigurationPropertiesRebinderAutoConfiguration，其内部使用 ConfigurationPropertiesBeans 类时发生了类加载失败...有可能是Spring Cloud 版本不兼容。

如果使用不兼容版本的 Spring Cloud，它与 Spring Boot 2.6.15 不兼容，就有可能导致 ConfigurationPropertiesBeans 类无法正确加载。

这么说还是 spring-cloud-starter-openfeign 的版本不兼容，我找的版本号不对呗。

这个好办，去掉 spring-cloud-starter-openfeign 的版本号，增加 spring-cloud-dependencies的依赖管理，让它来管理 spring-cloud 相关框架的版本。

既然 spring boot 2.6.x 对应的 spring cloud 依赖管理是 2021.0.x ，干脆就用最高版本 2021.0.8。

   <dependencies>

       <dependency>

           <groupId>org.springframework.cloud</groupId>

           <artifactId>spring-cloud-dependencies</artifactId>

           <version>2021.0.8</version>

           <type>pom</type>

           <scope>import</scope>

       </dependency>

   </dependencies>

再次更新 Maven 依赖，重新启动项目，项目运行成功。

如果每个项目都能这样升级，那是不是太简单了，事实很快打脸。

二、项目升级失败的案例

这个项目比较复杂，不是单一的小项目，是一个微服务集群项目，有服务发现注册组件、配置中心、负载均衡和子项目一二三四五六个。

啥也不说，一上来就把父 pom 文件的 spring-boot-starter-parent 版本由 2.2.13.release 升级到 2.6.15，spring-cloud-dependencies 版本由 Hoxton.SR4 升级到 2021.0.8。

更新 Maven 后，有一个项目报错了，负载均衡项目，咋回事？

调查之后才发现，负载均衡用到了 spring-cloud-starter-netflix-zuul 这个框架，这个框架在 Spring Cloud 2020.0.0 版本及之后的版本中不再支持。主要是因为 Netflix 停止维护 Zuul，而 Spring 团队推荐使用更现代且功能强大的 Spring Cloud Gateway 作为 API 网关解决方案。

好吧，先舍弃这个项目，运行其他项目试试看。

首先运行的项目是服务注册中心，运行失败。

提示信息大概意思是：如果你不使用配置中心，请使用下面命令将其关掉。

spring.cloud.config.discovery.enabled = false

我一个服务注册中心，哪里用什么配置呀？

调查之后发现，父 pom 中引入 spring-cloud-config-client 框架作为公共依赖。

以前为了偷懒，把大部分项目能用到的框架都放在父 pom里了，现在这招不行了，一个一个移除 ，一个一个添加到需要的项目里。

父POM 移除多余的框架后，公共依赖加上服务注册中心的 pom 只剩下孤零零的一个 spring-cloud-starter-netflix-eureka-server 框架，运行成功了。

终于向成功迈进了一小步，有点沾沾自喜。

接着运行配置服务器，配置中心有两个框架，一个 spring-cloud-config-server 框架用于配置服务，一个 spring-cloud-starter-netflix-eureka-client 用于把本项目注册到注册中心，这个项目也运行成功了。

迈向成功的小步走得有点快，成功越来越近了。

接下来启动一个接口项目，还没运行，项目就报错了。

打开报错的类，发现 org.apache.commons.lang.StringUtils 这个工具类不见了，可能由于框架变更的缘故，这个类被遗弃了，只能将它改为单独引入的 org.apache.commons.lang3 框架，涉及的类还不少，批量替换了好几十个类文件，一个一个改可是要累死的。

还有一个错误提示，大概意思是缺少 validation-api 架包。它缺我就加吧。

  <groupId>javax.validation</groupId>

  <artifactId>validation-api</artifactId>

使用 maven 更新框架后，再次启动，可以启动了，但在快成功的时候，还是报错了。

就这样，一会儿缺这一会儿缺那，更新maven，启动项目，调整框架所在的项目...

反反复复很多次之后，这个接口还是没有启动起来。怎么回事呢。

细看控制台，数据库连接都是失败的，看来是没有找到配置文件呀。

此时又接到其他任务，项目框架升级的事情只能告一段落，但是为了升级有点结果，只能退而求其次，最后挣扎了一下，把 spring-boot-starter由 2.2.13.RELEASE 升级到 2.3.12.release， spring-cloud-dependencies 依赖管理由Hoxton.SR4升级到Hoxton.SR9。

升级到这个版本，我就无需调整负载均衡的项目，因为 Hoxton.SR9 的下一个版本才是 Spring Cloud 2020.0.0。

本次升级任务就这样草草结束。

三、最后总结

框架升级不是一件容易的事情。简单的小一点的项目，涉及框架少的项目，spring-boot-starter 升级到 2.6.15 可以一次成功，比如我升级的第一个项目，里面涉及的 spring-boot 相关依赖有两个，Spring-Cloud 相关依赖只有一个，其他都是第三方框架。

第二个项目情况就复杂得多，不仅框架多，里面的关联关系也多，有些框架在某个版本突然不支持了，不仅代码要改，在升级前必须学会新框架的使用，用新框架代替旧框架，这个动静就大了，这都是升级的成本和代价。

最后再回顾回顾官网文档：

https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2021.0-Release-Notes

https://github.com/spring-cloud/spring-cloud-release/wiki/Historical-Versions

多看看官网文档，踩坑的时候才能觉知的快一点，陷的浅一点。这次踩坑就到这里吧。