前言

北京時間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練手，迎接下一次革新。