Spring Cloud 2022.0.0正式发布：OpenFeign稳得很&全面迈向GraalVM

前言

北京时间2022-12-16，Spring Cloud 2022.0.0​（代号Kilburn）正式发布。明天就是2023 年了，怎么现在才发布 2022 版本呢？你以为一年都快结束了但Spring Cloud才开始，但其实人家早在今年的第一个月就定下了基调：

至于正式发布时间嘛，去年也差不多是这样子的，千年的2020.0.0版本发布时间是2020-12-22。

其实，Spring Cloud的发版速度慢其实是必然的，毕竟越上层技术依赖的就会越多，测试难度就越高。毕竟，Spirng Boot 3.0于2022-11-24才发布，Eureka 2.0.0也2022-12-14才发布嘛，被“逼”到了这个时间节点而已。

Netflix Eureka 2.0.0正式发布：借尸还魂还是虚晃一枪？

Spring Boot 3.0.0正式发布，Banner不再支持图片&增强可观测性

总的来讲Spring技术栈发版是非常规律和可信的，可谓业界标杆。感受下之前的版本特性：

Spring Cloud 2022.0.0正式发布：OpenFeign稳得很&全面迈向GraalVM

Spring Cloud 2021.0.0正式发布，FeignClient调用结果可一键缓存

Spring Cloud 2020.0.0正式发布，再见了Netflix

Spring改变版本号命名规则：此举对非英语国家很友好

正文

Spring Cloud 2022.0.0版本的pom依赖：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2022.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

依赖Spring Boot 3.0.0版本即可，好在这次对齐了，有进步。还记得前两个版本的依赖关系吗？

Spring Cloud 2021.0.0最低依赖Spring Boot 2.6.1（而非2.6.0）

Spring Cloud 2020.0.0最低依赖Spring Boot 2.5.1（而非2.5.0）

即使强如Spring技术团队都会因为bug导致出现这种“对不齐”的现象，洁癖患者看着着实有点小难受有木有。所以，程序员平时多多宽容自己O(∩_∩)O

老生常谈

一年一次，关于Spring Cloud，每每都有些老生常谈的议题，很基础，但又不得不知，不得不晓。

和Spring Boot的对应关系

Spring Cloud作为云计算框架，以Spring Boot作为基石，因此它和Spring Boot的版本对应关系非常重要。

按目前节奏，Spring Boot每年发布2个中版本、一个大版本升级，Spring Cloud保持每年一次大版本升级的用以匹配节奏。

版本管理

Spring Cloud管理着众多功能组件，本版本和去年2021.0.0版本对比图如下：

不管从数量上（2022更少）还是版本号上（2022均是大版本号升级），差异都还挺大的。

本次对很多模块进行了更新，笔者绘制成表格，方便你收藏：

可以看到，相较于上个版本，本次删除了spring-cloud-sleuth和spring-cloud-cloudfoundry​，以及spring-cloud-cli三个模块的管理。

what’s new（新特性）

老规矩，将我们关心的功能爽一遍。

最低版本要求

• Java 17
• Jakarta EE 9
• Spring Framework 6.x
• Spring Boot 3.x

移除掉三个模块

Spring Cloud CLI：该模块在Spring Boot CLI的基础上，简化Spring Cloud应用部署。有了它可以通过一些命令spring cloud configserver、$ spring cloud eureka快速启动一些组件

笔者体验后的感觉：生产上真是没啥用，玩玩就可以了

Spring Cloud Cloudfoundry：SC里有个枚举类CloudPlatform​能看到：

• Cloud Foundry是业界第一个开源PaaS云平台，但它可能真不太适合现在的云环境，要被列入前辈行列了，毕竟K8S势如破竹。
• Spring Cloud Sleuth：分布式链路追踪模块(Zipkin是默认实现)，遵循Google的开源项目Dapper以及OpenTracing标准。这次把这个模块干掉，当然不是放弃链路追踪功能，而是将它交给了Micrometer Tracing项目，现在日志、指标、追踪都可交给Micrometer了。

Spring Cloud Commons

要说Spring Cloud最最最重要的一个模块是什么，那便是Spring Cloud Commons。作为阻断式的大版本升级（Spring Cloud Commons从3.1.x升级到了4.0.0），必然也是大刀阔斧，甩掉包袱，主要有：

AsyncRestTemplate相关类被移除

AsyncRestTemplate&AsyncRestOperations作为异步请求器，一直依赖存在感其实蛮若的。而在Spring Framework 5.0的时候就已将它哥俩标记为@Deprecated​了，取代它们的是Spring Reactor Web提供的WebClient。

在Spring Framework 6，AsyncRestTemplate已被删除。因此Spring Cloud也移除了其相关配置类：AsyncLoadBalancerAutoConfiguration、AsyncRestTemplateCustomizer等等。

httpclient包下面的类全被被移除

如下图所示：

这个有点狠，整个被全部拿下，包括：Apache HttpCLient和OkHttp3的相关集成Factory等。之前版本中像OpenFeign就会用到它。

@EnableCircuitBreaker注解被移除

原因很简单，这个Hystrix在Spring Cloud 2022中不再被支持，这个预防针在Spring Cloud 2020就已经打过啦（当时不建议使用，现在是移除支持）。

Spring Cloud 2020.0.0正式发布，再见了Netflix

@SpringCloudApplication注解终被移除

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
public @interface SpringCloudApplication {

}

这个注解很熟悉，但又很陌生？嗯，一个典型的Spring Cloud应用注解，在之前版本更是带有@EnableCircuitBreaker​注解呢。现在@EnableDiscoveryClient和@EnableCircuitBreaker都不需要了，自然@SpringCloudApplication就没有再存在的意义了。

• @EnableDiscoveryClient：只要classpath里存在相关类，就会被自动开启

毕竟，服务发现已成微服务应用最基本的设施了嘛，默认就开启喽。当然，你可通过spring.cloud.discovery.enabled=false来显示关闭，具有更好的灵活性

• @EnableCircuitBreaker​：Hystrix自从Spring Cloud 2020.0.0版本就退出历史舞台了，取而代之的Resilience4j用不着它

此注解在早在Spring Cloud Common 3.0.1（对应Spring Cloud 2020.0.1）就被标记为了@Deprecated，直到Spring Cloud Common 4.0.0版本被从源码正式拿下。

🚀Spring Cloud OpenFeign

太多的博文拿这个标题来“做文章”：OpenFeign要退出历史舞台了？笔者的观点：这是趋势，但开发者duck不必担心，因为OpenFeign还很活跃，退出按照时间维度来讲5年打底，10年差不多。所以，该学的Feign技术还得继续，比如笔者的这个Feign专题：

另外，看看本次Spring Cloud对Feign的升级更改，就知道退出还有很长路要走：

属性配置统一为spring.cloud.openfeign前缀

之前版本feign相关的属性配置都为feign.xxx​，现在统为spring.cloud.openfeign.xxx​，队形保持和其它模块一致，更加和谐了。举例如下：

默认使用Jackson完成序列化/反序列化

在此之前，序列化和反序列化默认情况下是Feign自己实现的，我们一般会选择显示开启Jackson支持。毕竟它已成为标准组件，Spring MVC、Redis等一般都使用它完成。

为此，本版本讲Jackson正式转正：默认使用它来完成Feign的序列化/反序列化功能。具体配置差异如下图所示：

拥抱Apache HttpClient 5，移除对4的支持

弃用了对Apache HttpClient 4的支持，拥抱Apache HttpClient 5。直观的讲，HttpClientFeignConfiguration​等相关类已删除：只剩下HttpClient5FeignConfiguration

而在2021版本的Spring Cloud里它是存在的，并且默认开启的是HttpClient 4哦：

这一点与Spring Framework、Spring Boot中的变化保持一致。

@FeignClient的decode404属性改为dismiss404

@FeignClient​注解的改动如下：

修改的原因是：与上游技术（也就是原生Feign）命名保持一致。因为Feign从11.9版本起内部就做了改名：

因此Spring Cloud借这次阻断式升级，顺势将名称整规范喽，非常有追求有木有。

Feign升级到12.1版本

从上个版本的11.7升级到本版本的12.1

@FeignClient的注册不再使用懒加载

代码的改变在这里，一看便知：

很明显，如果希望加载行为保持和之前版本一致，只需加个配置​spring.cloud.openfeign.lazy-attributes-resolution = true即可.。

Spring Cloud Netflix

Spring Cloud Netflix曾作为Spring Cloud的全栈解决方案，现在唯一被“保留”下来的有且仅有Eureka了。

这一次继续砍：移除掉注解​@EnableEurekaClient​（毕竟@EnableDiscoveryClient都不需要显示指定了嘛）

Eureka升级到2.0.0

嗯，不再重复阐述了哈，笔者写了篇文章专门介绍Eureka 2.0.0：Netflix Eureka 2.0.0正式发布：借尸还魂还是虚晃一枪？

迈向GraalVM：支持AOT和Native image

Spring Boot 3.0最大看点和改动，就是对GraalVM原生镜像的支持。Spirng团队多次强调，为此付出的心血和花费精力都是最多的。

GraalVM技术是JRE的替代方案，基本原理是通过预编译AOT（Ahead Of Time）技术先编译好，这样Spring框架就可以获取到更多信息，从而启动就非常快了，这不难理解哈。

Spring团队早在2019年就开始研究对GraalVM的支持，还记得那个Spirng Native项目吗？它就是专门用于研究GraalVM的，曾经的实验性项目，现正式被Spring Boot 3.0收纳，光荣完成使命。

本次Spring Cloud 2022对各个模块（大部分模块）都添加了AOT和Native image的支持，可谓补射完了临门一脚，Spring技术栈正式迈向GraalVM，且逐渐趋于成熟。相信不远的将来会逐渐流行开来，笔者预估3年有明显变化，5年快速增长。

其它

Spring Cloud Circuitbreaker模块的Resilience4J升级到了2.0.2功能（上个版本为1.7.x）

Spring Cloud Gateway增加对Observability检测的支持

Spring Cloud Stream移除@StreamListener、@Input等注解

Spring Cloud Kubernetes移除@ConditionalOnKubernetesEnabled注解 这个注解属于Spring Cloud的：

代替者是使用Spring Boot的​@ConditionalOnCloudPlatform​注解：

总结

谈OpenFeign被淘汰还为时尚早：依旧主流，该学还得继续学； 学GraalVM已为时不晚：必然的发展趋势，早学早受益； 用Spring Cloud 2022时机基本成熟：demo练手，迎接下一次革新。