前言

北京時(shí)間2022-12-16，Spring Cloud 2022.0.0?（代號(hào)Kilburn）正式發(fā)布。明天就是2023 年了，怎么現(xiàn)在才發(fā)布 2022 版本呢？你以為一年都快結(jié)束了但Spring Cloud才開始，但其實(shí)人家早在今年的第一個(gè)月就定下了基調(diào)：

至于正式發(fā)布時(shí)間嘛，去年也差不多是這樣子的，千年的2020.0.0版本發(fā)布時(shí)間是2020-12-22。

其實(shí)，Spring Cloud的發(fā)版速度慢其實(shí)是必然的，畢竟越上層技術(shù)依賴的就會(huì)越多，測(cè)試難度就越高。畢竟，Spirng Boot 3.0于2022-11-24才發(fā)布，Eureka 2.0.0也2022-12-14才發(fā)布嘛，被“逼”到了這個(gè)時(shí)間節(jié)點(diǎn)而已。

Netflix Eureka 2.0.0正式發(fā)布：借尸還魂還是虛晃一槍？

Spring Boot 3.0.0正式發(fā)布，Banner不再支持圖片&增強(qiáng)可觀測(cè)性

總的來講Spring技術(shù)棧發(fā)版是非常規(guī)律和可信的，可謂業(yè)界標(biāo)桿。感受下之前的版本特性：

Spring Cloud 2022.0.0正式發(fā)布：OpenFeign穩(wěn)得很&全面邁向GraalVM

Spring Cloud 2021.0.0正式發(fā)布，F(xiàn)eignClient調(diào)用結(jié)果可一鍵緩存

Spring Cloud 2020.0.0正式發(fā)布，再見了Netflix

Spring改變版本號(hào)命名規(guī)則：此舉對(duì)非英語國家很友好

正文

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版本即可，好在這次對(duì)齊了，有進(jìn)步。還記得前兩個(gè)版本的依賴關(guān)系嗎？

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）

即使強(qiáng)如Spring技術(shù)團(tuán)隊(duì)都會(huì)因?yàn)閎ug導(dǎo)致出現(xiàn)這種“對(duì)不齊”的現(xiàn)象，潔癖患者看著著實(shí)有點(diǎn)小難受有木有。所以，程序員平時(shí)多多寬容自己O(∩_∩)O

老生常談

一年一次，關(guān)于Spring Cloud，每每都有些老生常談的議題，很基礎(chǔ)，但又不得不知，不得不曉。

和Spring Boot的對(duì)應(yīng)關(guān)系

Spring Cloud作為云計(jì)算框架，以Spring Boot作為基石，因此它和Spring Boot的版本對(duì)應(yīng)關(guān)系非常重要。

按目前節(jié)奏，Spring Boot每年發(fā)布2個(gè)中版本、一個(gè)大版本升級(jí)，Spring Cloud保持每年一次大版本升級(jí)的用以匹配節(jié)奏。

版本管理

Spring Cloud管理著眾多功能組件，本版本和去年2021.0.0版本對(duì)比圖如下：

不管從數(shù)量上（2022更少）還是版本號(hào)上（2022均是大版本號(hào)升級(jí)），差異都還挺大的。

本次對(duì)很多模塊進(jìn)行了更新，筆者繪制成表格，方便你收藏：

可以看到，相較于上個(gè)版本，本次刪除了spring-cloud-sleuth和spring-cloud-cloudfoundry?，以及spring-cloud-cli三個(gè)模塊的管理。

what’s new（新特性）

老規(guī)矩，將我們關(guān)心的功能爽一遍。

最低版本要求

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

移除掉三個(gè)模塊

Spring Cloud CLI：該模塊在Spring Boot CLI的基礎(chǔ)上，簡化Spring Cloud應(yīng)用部署。有了它可以通過一些命令spring cloud configserver、$ spring cloud eureka快速啟動(dòng)一些組件

筆者體驗(yàn)后的感覺：生產(chǎn)上真是沒啥用，玩玩就可以了

Spring Cloud Cloudfoundry：SC里有個(gè)枚舉類CloudPlatform?能看到：

• Cloud Foundry是業(yè)界第一個(gè)開源PaaS云平臺(tái)，但它可能真不太適合現(xiàn)在的云環(huán)境，要被列入前輩行列了，畢竟K8S勢(shì)如破竹。
• Spring Cloud Sleuth：分布式鏈路追蹤模塊(Zipkin是默認(rèn)實(shí)現(xiàn))，遵循Google的開源項(xiàng)目Dapper以及OpenTracing標(biāo)準(zhǔn)。這次把這個(gè)模塊干掉，當(dāng)然不是放棄鏈路追蹤功能，而是將它交給了Micrometer Tracing項(xiàng)目，現(xiàn)在日志、指標(biāo)、追蹤都可交給Micrometer了。

Spring Cloud Commons

要說Spring Cloud最最最重要的一個(gè)模塊是什么，那便是Spring Cloud Commons。作為阻斷式的大版本升級(jí)（Spring Cloud Commons從3.1.x升級(jí)到了4.0.0），必然也是大刀闊斧，甩掉包袱，主要有：

AsyncRestTemplate相關(guān)類被移除

AsyncRestTemplate&AsyncRestOperations作為異步請(qǐng)求器，一直依賴存在感其實(shí)蠻若的。而在Spring Framework 5.0的時(shí)候就已將它哥倆標(biāo)記為@Deprecated?了，取代它們的是Spring Reactor Web提供的WebClient。

在Spring Framework 6，AsyncRestTemplate已被刪除。因此Spring Cloud也移除了其相關(guān)配置類：AsyncLoadBalancerAutoConfiguration、AsyncRestTemplateCustomizer等等。

httpclient包下面的類全被被移除

如下圖所示：

這個(gè)有點(diǎn)狠，整個(gè)被全部拿下，包括：Apache HttpCLient和OkHttp3的相關(guān)集成Factory等。之前版本中像OpenFeign就會(huì)用到它。

@EnableCircuitBreaker注解被移除

原因很簡單，這個(gè)Hystrix在Spring Cloud 2022中不再被支持，這個(gè)預(yù)防針在Spring Cloud 2020就已經(jīng)打過啦（當(dāng)時(shí)不建議使用，現(xiàn)在是移除支持）。

Spring Cloud 2020.0.0正式發(fā)布，再見了Netflix

@SpringCloudApplication注解終被移除

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

}

這個(gè)注解很熟悉，但又很陌生？嗯，一個(gè)典型的Spring Cloud應(yīng)用注解，在之前版本更是帶有@EnableCircuitBreaker?注解呢?，F(xiàn)在@EnableDiscoveryClient和@EnableCircuitBreaker都不需要了，自然@SpringCloudApplication就沒有再存在的意義了。

• @EnableDiscoveryClient：只要classpath里存在相關(guān)類，就會(huì)被自動(dòng)開啟

畢竟，服務(wù)發(fā)現(xiàn)已成微服務(wù)應(yīng)用最基本的設(shè)施了嘛，默認(rèn)就開啟嘍。當(dāng)然，你可通過spring.cloud.discovery.enabled=false來顯示關(guān)閉，具有更好的靈活性

• @EnableCircuitBreaker?：Hystrix自從Spring Cloud 2020.0.0版本就退出歷史舞臺(tái)了，取而代之的Resilience4j用不著它

此注解在早在Spring Cloud Common 3.0.1（對(duì)應(yīng)Spring Cloud 2020.0.1）就被標(biāo)記為了@Deprecated，直到Spring Cloud Common 4.0.0版本被從源碼正式拿下。

??Spring Cloud OpenFeign

太多的博文拿這個(gè)標(biāo)題來“做文章”：OpenFeign要退出歷史舞臺(tái)了？筆者的觀點(diǎn)：這是趨勢(shì)，但開發(fā)者duck不必?fù)?dān)心，因?yàn)镺penFeign還很活躍，退出按照時(shí)間維度來講5年打底，10年差不多。所以，該學(xué)的Feign技術(shù)還得繼續(xù)，比如筆者的這個(gè)Feign專題：

另外，看看本次Spring Cloud對(duì)Feign的升級(jí)更改，就知道退出還有很長路要走：

屬性配置統(tǒng)一為spring.cloud.openfeign前綴

之前版本feign相關(guān)的屬性配置都為feign.xxx?，現(xiàn)在統(tǒng)為spring.cloud.openfeign.xxx?，隊(duì)形保持和其它模塊一致，更加和諧了。舉例如下：

默認(rèn)使用Jackson完成序列化/反序列化

在此之前，序列化和反序列化默認(rèn)情況下是Feign自己實(shí)現(xiàn)的，我們一般會(huì)選擇顯示開啟Jackson支持。畢竟它已成為標(biāo)準(zhǔn)組件，Spring MVC、Redis等一般都使用它完成。

為此，本版本講Jackson正式轉(zhuǎn)正：默認(rèn)使用它來完成Feign的序列化/反序列化功能。具體配置差異如下圖所示：

擁抱Apache HttpClient 5，移除對(duì)4的支持

棄用了對(duì)Apache HttpClient 4的支持，擁抱Apache HttpClient 5。直觀的講，HttpClientFeignConfiguration?等相關(guān)類已刪除：只剩下HttpClient5FeignConfiguration

而在2021版本的Spring Cloud里它是存在的，并且默認(rèn)開啟的是HttpClient 4哦：

這一點(diǎn)與Spring Framework、Spring Boot中的變化保持一致。

@FeignClient的decode404屬性改為dismiss404

@FeignClient?注解的改動(dòng)如下：

修改的原因是：與上游技術(shù)（也就是原生Feign）命名保持一致。因?yàn)镕eign從11.9版本起內(nèi)部就做了改名：

因此Spring Cloud借這次阻斷式升級(jí)，順勢(shì)將名稱整規(guī)范嘍，非常有追求有木有。

Feign升級(jí)到12.1版本

從上個(gè)版本的11.7升級(jí)到本版本的12.1

@FeignClient的注冊(cè)不再使用懶加載

代碼的改變?cè)谶@里，一看便知：

很明顯，如果希望加載行為保持和之前版本一致，只需加個(gè)配置?spring.cloud.openfeign.lazy-attributes-resolution = true即可.。

Spring Cloud Netflix

Spring Cloud Netflix曾作為Spring Cloud的全棧解決方案，現(xiàn)在唯一被“保留”下來的有且僅有Eureka了。

這一次繼續(xù)砍：移除掉注解?@EnableEurekaClient?（畢竟@EnableDiscoveryClient都不需要顯示指定了嘛）

Eureka升級(jí)到2.0.0

嗯，不再重復(fù)闡述了哈，筆者寫了篇文章專門介紹Eureka 2.0.0：Netflix Eureka 2.0.0正式發(fā)布：借尸還魂還是虛晃一槍？

邁向GraalVM：支持AOT和Native image

Spring Boot 3.0最大看點(diǎn)和改動(dòng)，就是對(duì)GraalVM原生鏡像的支持。Spirng團(tuán)隊(duì)多次強(qiáng)調(diào)，為此付出的心血和花費(fèi)精力都是最多的。

GraalVM技術(shù)是JRE的替代方案，基本原理是通過預(yù)編譯AOT（Ahead Of Time）技術(shù)先編譯好，這樣Spring框架就可以獲取到更多信息，從而啟動(dòng)就非?？炝耍@不難理解哈。

Spring團(tuán)隊(duì)早在2019年就開始研究對(duì)GraalVM的支持，還記得那個(gè)Spirng Native項(xiàng)目嗎？它就是專門用于研究GraalVM的，曾經(jīng)的實(shí)驗(yàn)性項(xiàng)目，現(xiàn)正式被Spring Boot 3.0收納，光榮完成使命。

本次Spring Cloud 2022對(duì)各個(gè)模塊（大部分模塊）都添加了AOT和Native image的支持，可謂補(bǔ)射完了臨門一腳，Spring技術(shù)棧正式邁向GraalVM，且逐漸趨于成熟。相信不遠(yuǎn)的將來會(huì)逐漸流行開來，筆者預(yù)估3年有明顯變化，5年快速增長。

其它

Spring Cloud Circuitbreaker模塊的Resilience4J升級(jí)到了2.0.2功能（上個(gè)版本為1.7.x）

Spring Cloud Gateway增加對(duì)Observability檢測(cè)的支持

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

Spring Cloud Kubernetes移除@ConditionalOnKubernetesEnabled注解 這個(gè)注解屬于Spring Cloud的：

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

總結(jié)

談OpenFeign被淘汰還為時(shí)尚早：依舊主流，該學(xué)還得繼續(xù)學(xué)； 學(xué)GraalVM已為時(shí)不晚：必然的發(fā)展趨勢(shì)，早學(xué)早受益； 用Spring Cloud 2022時(shí)機(jī)基本成熟：demo練手，迎接下一次革新。