北京時間2020-12-22深夜,Spring Cloud 2020.0.0
版本正式發佈。2020.0.0是第一個使用新版本方案的Spring Cloud發行版本。
關於版本號這裏囉嗦幾句:在這之前,Spring Cloud的Release Train名稱採用的是倫敦地鐵站命名方式,如:Hoxton、Greenwich等。
說明:2020.0.0版本又名
Ilford
(地鐵站名),因爲此項目3月後才按照新規更名,估計是爲了團隊內溝通方便吧,你也可以理解爲它僅是一個內部代號而已,方便溝通
雖按照字母表順序排列,但仍存在兩個致命問題:
對非英語母語國家(比如天朝)非常不友好,無法快速理清版本號關係
A-Z,倘若版本號到Z了呢?如何繼續發展?你品,你細品
Spring團隊意識到了這的確是個問題,因此在今年3月份作出了改變。詳情參考我前面寫的一篇文章(強烈建議每個進來的你都瞭解下這次規則變更):Spring改變版本號命名規則:此舉對非英語國家很友好
說明:版本號規則變更適用於所有Spring技術棧,包含Spring Framework、Spring Boot、Spring Cloud、Spring Data...
文歸正傳。Spring Cloud早在年初就啓動了該版本的研發工作,並在今年4月份就已經發布了其2020.0.0-M1版本(第一個里程碑版本),直到離2020年結束不到10天了才“憋出”大招,正式RELEASE。
Spring Cloud作爲構建在Spring Boot之上的雲計算框架,我覺得本次難產的原因主要有二:
- Spring Boot 2.4.0版本2020-11-12才正式RELEASE(Spirng Framework 5.3.0版本2020-10-27才RELEASE)
1. Spring Framework 5.3.0正式發佈,在雲原生路上繼續發力
2. Spring Boot 2.4.0正式發佈,全新的配置文件加載機制(不向下兼容)
- 改動確實太大,研發、測試、文檔編寫工作量都是巨大的
從Spring Framework、Spring Boot、Spring Cloud三者的發版線路圖再一次驗證了我的那句話:你對Spring Cloud多瞭解源自於你對Spring Boot有多瞭解,你對Spring Boot多瞭解源自於你對Spring Framework有多瞭解。這就是爲何我文章花大量筆墨在Spring Framework上而非Spring Boot上的根本原因,底層通透了,上層運用自如。
版本約定
Spring Framework:5.3.2
Spring Boot:2.4.1
Spring Cloud:2020.0.0
- 以上版本爲SC“攜帶”的版本
✍正文
有個有趣的現象,截止稿前(2020-12-23 22:00:00)官網還並未同步標註好當前最新版本爲2020.0.0版(如圖):
其實早在24h之前官方博客就做出了發版宣告:
並且Maven中央倉庫也已存在最新Jar包(證明你正常引包、使用是沒問題的了):
其實,文檔層面不止官網這一處沒有sync最新版本,我就不一一例舉,畢竟不太重要。針對此現象我yy一下,是不是Spring Cloud團隊缺人人手不夠用呢?請問社招嗎?O(∩_∩)O哈哈~
Spring Cloud版本管理
版本管理對於軟件開發來說太重要,在Spring Boot出現之前依賴關係、版本管理讓人着實頭大(即使有Spring BOM存在),特別是當出現版本不適配時很容易就偷走你一下午甚至一整天的時間。
Spring Cloud作爲上層應用框架,底層版本匹配了才能正常work,其中最主要就是和Spring Boot的版本號要對齊。
與Spring Boot版本對應關係
Spring Boot的出現和流行大大緩解了上述些情況,但使用起Spring Cloud時它和Spring Boot的版本對應關係依舊是需要特別關注的。爲此我幫你總結出了這個表格:
Release Train | 發佈時間 | Spring Boot版本 | SC Commons版本
-------- | ----- | ----- | -----
2020.0.x | 2020-12 | 2.4.x | 3.0.0
Hoxton | 2019-07 | 2.2.x, 2.3.x (從SR5起) | 2.2.x
Greenwich | 2018-11 | 2.1.x | 2.1.x
Finchley | 2017-10 | 2.0.x | 2.0.x
Edgware | 2017-08 | 1.5.x | 1.3.x
Dalston | 2017-05 | 1.5.x | 1.2.x
Brixton | 2016-09 | 1.3.x | 1.1.x
Angel | 2016-05 | 1.2.x | 1.0.x
說明:對於Spring Cloud內部組件、Spring Boot、Spirng Framework、Security等這個龐大體系的版本對照關係,文章已整理好,下篇發出,請記得蒐藏哦
特別提醒:spring-cloud-starter-loadbalancer
是伴隨着Spring Cloud Commons 2.2.0版本纔開始商用的(Hoxton版本),這個版本節點請稍微關注下,因爲它替代了Ribbon。
當前支持的版本
Spring Cloud遵循Pivotal OSS support policy 協議對主要版本提供3年的支持。此外,在Spring Cloud的主要或次要版本發佈後,若存在嚴重的bug和安全問題,就會再維護一段時間(6-12個月不等)。
特別注意:這裏指的主要版本纔是3年,主要版本可不常有的哦
現在2020.0.0版本已發佈,又到了淘汰的時候。現在Spring Cloud官方還會支持的版本有:
- 2020.0版本:(支持Spring Boot 2.4.x)它是主要版本,按計劃會支持到2023年12月份
- 它是自Finchley後的又一主要版本
Hoxton版本:(支持Spring Boot 2.2.x和2.3.x)作爲Finchley發行系列的一個次要版本,它的常規維護將持續到2021年6月底。從2020-07開始進入到特殊維護期(不加新功能,只改緊急bug),2021-12月底就只會發佈重大錯誤/安全補丁了
Greenwich版本:(支持Spring Boot 2.1.x)2020-01就停止維護了,2020-12-31號也將終結它的特殊維護期
Finchley版本:(支持Spring Boot 2.0.x)它是一個主要版本的開始,2018年發佈
更老版本:嗯,忘了吧
Spring官方建議:儘量使用最新版本。不過建議歸建議,作爲只使用晚期大衆技術的我們,坐在第二排甚至第三排看戲纔有安全感。但歷史的巨浪總歸會把前排淘汰,因此早點做足準備總是好的,不至於時至被推至前排時只能裸泳。
Spring Cloud 2020.0作爲一個主要版本,帶來了衆多顯著的變化,其中進行了一些阻斷式更新(不向下兼容)是本文最大看點,來吧上菜。
阻斷式升級(不向下兼容)
差不多在去年(2019年)的這個時候,Spring Cloud在其Roadmap(之前文章有介紹過)裏就宣佈將要終結的一些庫/版本,其中最重要的就是指Spring Cloud Netflix項目進入維護模式,然後計劃在2020年完全移除。
Spring Cloud做出這樣的決定其實也是“被迫的”。我們知道Spring Cloud一直以來把Netflix OSS
套件作爲其官方默認的一站式解決方案,那時的Netflix OSS套件恨不得可以跟Spring Cloud劃等號。奈何呀,Netflix公司在2018年前後宣佈其核心組件Hystrix、Ribbon、Zuul、Archaius等均進入維護狀態。
雖然有Zuul 2.x,Archaius 2.x,但它們均不能向下兼容,無法平滑升級,因此幾乎等於無法使用
從2018年至今處於維護狀態的模塊有(包括其對應的starter,此處並未列出):
spring-cloud-netflix-archaius
spring-cloud-netflix-hystrix-contract
spring-cloud-netflix-hystrix-dashboard
spring-cloud-netflix-hystrix-stream
spring-cloud-netflix-hystrix
spring-cloud-netflix-ribbon
spring-cloud-netflix-turbine-stream
spring-cloud-netflix-turbine
spring-cloud-netflix-zuul
1、再見了,Netflix
時至今日,Spring Cloud 2020.0正式發佈,在這個主要版本里,按既定計劃終於對spring-cloud-netflix
動刀了。我幫你畫了幅spring-cloud-netflix-dependencies
的xml文件前後版本主要差異的對比圖,一目瞭然:
spring-cloud-netflix-dependencies
沒有消失哦,它依舊存在,版本號跟隨大部隊升級爲3.0.x版本舊版本的
spring-cloud-netflix-dependencies
管理着Netflix所有組件,包括Hystrix、Ribbon、Zuul、Eureka等。而自2020.0版本起,它有且只管理Eureka(包括Server和Client)
解釋說明:Feign雖然最初屬Netflix公司,但從9.x版本開始就移交給OpenFeign組織管理了,因此不再劃入Netflix管轄範疇
簡單一句話概括:Spring Cloud 2020.0.0版本徹底刪除掉了Netflix除Eureka外的所有組件。至此,我們懷着感恩的心可以對Netflix OSS套件道一聲謝謝,並可以對它說再見了。
說明:Netflix的Eureka項目仍舊是活躍狀態,這個註冊中心設計上還是蠻優秀的,綜合表現尚可,市場上競爭力依舊可圈可點,因此Spring Cloud暫還未放棄它
<pre lang="xml" data-origin="pm_code_preview" style="margin: 0px; padding: 0px; list-style: none; font-family: Courier, "Courier New", monospace; display: block;">
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
</pre>
Netflix組件替代方案
Spring Cloud既然把Netflix OSS套件大刀闊斧的砍掉了,那總歸得有替代方案吧。那是必然的,Spring Cloud團隊給我們推薦了用於替代的產品:
Netflix | 推薦替代品 | 說明
-------- | ----- | -----
Hystrix | Resilience4j | Hystrix自己也推薦你使用它代替自己
Hystrix Dashboard / Turbine | Micrometer + Monitoring System | 說白了,監控這件事交給更專業的組件去做
Ribbon | Spring Cloud Loadbalancer | 忍不住了,Spring終究親自出手
Zuul 1 | Spring Cloud Gateway | 忍不住了,Spring終究親自出手
Archaius 1 | Spring Boot外部化配置 + Spring Cloud配置 | 比Netflix實現的更好、更強大
Spring Cloud LoadBalancer是什麼?
以上替代品中,你可能最陌生、最好奇的是Spring Cloud Loadbalancer
,它一度只是Spring Cloud 孵化器裏的一個小項目,並且一度擱淺。後再經過重啓,發展,現行使其偉大使命,正式用於完全替換 Ribbon,成爲Spring Cloud負載均衡器唯一實現。
值得注意的是:Spring Cloud LoadBalancer首次引入是在Spring Cloud Commons 2.2.0時,也就是Hoxton發佈時就引入了,只不過那會還只是備胎/備選,默認依舊是Ribbon挑大樑。下截圖是在Hoxton版本的情況:
如圖,負載均衡抽象LoadBalancerClient
接口有兩個實現,而到了Spring Cloud 2020.0版本後,BlockingLoadBalancerClient
就是唯一實現了。
關於spring-cloud-loadbalancer負載均衡器的使用,官方有個極其建議教程:https://spring.io/guides/gs/spring-cloud-loadbalancer。有興趣可自己玩玩,若沒興趣,那就關注我後面文章分析吧,我會專程介紹它的
Spring Cloud Alibaba是否可作爲替代方案?
嗯,也可以。
不過它目前來說並不是Spring Cloud官方的推薦的默認方案。期待國人一起努力,能早日送Spring Cloud Alibaba上去,讓歪果仁用上咱天朝的框架,提issue必須用中文O(∩_∩)O哈哈~。
顯示導入Netflix包還能否正常work?
既想升級到最新版本的Spring Cloud,又想保持向下兼容使用Netflix的技術。雖說spring-cloud-netflix-dependencies裏不再包含netflix的核心組件,那我手動導包並指定版本號行不行?能否正常work呢?
答:我拍腦袋就給你個答案,不行。既然我沒論證過,但這麼使用太畸形了,此方案應被槍斃在萌芽中,不應該有。
另外,從此事也告訴我們:使用Spring Cloud時儘量面向它的抽象編程,這樣即使Spirng Cloud換底層組件(如換熔斷器、負載均衡器)等等,理論上對我們業務是無影響或者影響很小的,這都得益於它的Spring Cloud Commons抽象,那裏是精華。
2、Bootstrap上下文默認不再啓動
知曉原理的同學知道,Spring Cloud容器是靠Bootstrap Context
引導上下文來啓動的,對應的類是BootstrapApplicationListener
。
這在2020.0版本發生了改變,新版本的Spring Cloud不再依賴於此上下文而啓動。因此默認情況下,將不再啓動Bootstrap上下文。代碼層面的改變發生在這裏:
<pre lang="java" data-origin="pm_code_preview" style="margin: 0px; padding: 0px; list-style: none; font-family: Courier, "Courier New", monospace; display: block;">
BootstrapApplicationListener:
@Override
public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
ConfigurableEnvironment environment = event.getEnvironment();
// 在方法開頭加了這麼個判斷
if (!bootstrapEnabled(environment) && !useLegacyProcessing(environment)) {
return;
}
...
}
PropertyUtils:
// BOOTSTRAP_ENABLED_PROPERTY = spring.cloud.bootstrap.enabled
public static boolean bootstrapEnabled(Environment environment) {
return environment.getProperty(BOOTSTRAP_ENABLED_PROPERTY, Boolean.class, false) || MARKER_CLASS_EXISTS;
}
// USE_LEGACY_PROCESSING_PROPERTY = spring.config.use-legacy-processing
public static boolean useLegacyProcessing(Environment environment) {
return environment.getProperty(USE_LEGACY_PROCESSING_PROPERTY, Boolean.class, false);
}
</pre>
開啓方式
若你需要開啓Bootstrap上下文,有兩種辦法可以實現:
設置值
spring.cloud.bootstrap.enabled=true
或者spring.config.use-legacy-processing=true
即可。注意:這些個屬性值必須確保其能放進環境裏才能生效。比如靠譜的方式是:系統屬性、環境變量、命令行等引入一個Jar:
org.springframework.cloud:spring-cloud-starter-bootstrap
,然後什麼都不用做了
1. 說明:這個jar裏面有且僅有一個Marker
類,作用你懂的,此處不做過多解釋
說明:手動開啓Bootstrap上下文,證明你fallback到老的方式去加載SC,那麼一切請按照老方式做即可
3、全新的配置方式
得益於Spring Boot 2.4.x支持全新的配置文件書寫方式,自此可以使用spring.config.import
倆導入其它組建的配置。如:
spring.config.import=configserver:xxx
spring.config.import=zookeeper:
...
這麼做更具模塊化,更符合雲原生環境的要求。
4、其它
之前若要禁用Spring Cloud Config Client端的健康指示用的是
health.config.enabled=false
,現改爲management.health.config.enabled=false
。保持了和Spring Boot控制端點風格一致帶有無效字符(破折號)的端點id已經改爲符合標準的了,自此啓動時再也沒有討厭的警告了,拯救潔癖者。
bus-env -> busenv
bus-refresh -> busrefresh
service-registry -> serviceregistry
<pre lang="java" data-origin="pm_code_preview" style="margin: 0px; padding: 0px; list-style: none; font-family: Courier, "Courier New", monospace; display: block;">
// old
@Endpoint(id = "service-registry")
public class ServiceRegistryEndpoint { ... }
// new
@Endpoint(id = "serviceregistry")
public class ServiceRegistryEndpoint { ... }
</pre>
常規式升級
常規升級這塊關注點就沒那麼多了,主要對其組件如Spring Cloud Commons、Spring Cloud Kubernetes、Spring Cloud Openfeign...
等做些常規升級,乏善可陳。
值得關注的一點:Spirng Cloud所有的Module版本號均升級到了3.0.0
(大版本號的升級),除Spring Cloud Circuitbreaker/Spring Cloud Kubernetes(2.0.0)和Spring Cloud Task(2.3.0)之外。
仍舊存在的問題
雖然2020.0已經RELEASE了,但是仍存在着未解決的問題,例舉幾個此版本現存的問題:
- 若使用
spring.config.import=configserver:
來配置配置中心,此版本漏掉了支持retry參數
- 解決方案:若你要使用的話,你只得fallback到傳統方式嘍(寫在bootstrap.yaml裏)
-
spring-cloud-config-dependencies
裏出現了一個非release版本的jar(具體看下截圖)
- 解決方案:手動指定該jar的版本號
說明:M1屬於里程碑版本,還屬於較爲早起階段,可能存在bug,建議你使用時手動指定版本號替換掉這個jar
看來即使強如Spring團隊,也會出現各種各樣的紕漏呀。這麼一想的話,我又敢放心大膽的回去寫bug去嘍。
✍總結
Spring Cloud 2020.0.0是Spring Cloud的主要版本,是非常重要的存在,升級、改變也是巨大的。特別體現在Netflix模塊的全部移除、Spring Cloud啓動方式變了等等。伴隨着Spring Boot 2.4.x以及Spirng Cloud 2020.0的發佈,並且棄用Netflix OSS套件後,必將走入一個新的深度編程體驗,滿懷驚喜,很是期待。
說明:因爲此版本完全擯棄掉了Netflix的一套東西,爲了跟上時代,我會使用一段時間後,儘快寫出最新版本的系列教程,助你少踩坑
文末有提到2020.0版本雖已發佈,但仍舊存在些問題。不過話說回來,那些都屬於很小的問題,可能在下個小版本里就得到修復。但尷尬的是,距離2020年結束只有不到10天了,倘若進入到了2021年,按照版本號命名新規,彼時發出的版本將不能再叫2020.x.x而只能是2021.x.x,顯然這就屬於大版本號的迭代了,需要謹慎啊