Spring Cloud 微服務項目更新升級到版本2020.0.0以後
與Spring Boot版本對應關係
Spring Boot的出現和流行大大緩解了上述些情況,但使用起Spring Cloud時它和Spring Boot的版本對應關係依舊是需要特別關注的。爲此我幫你總結出了這個表格:https://my.oschina.net/zengfr
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 |
阻斷式升級(不向下兼容)
差不多在去年(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
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-netflix-dependencies
沒有消失哦,它依舊存在,版本號跟隨大部隊升級爲3.0.x版本- 舊版本的
spring-cloud-netflix-dependencies
管理着Netflix所有組件,包括Hystrix、Ribbon、Zuul、Eureka等。而自2020.0版本起,它有且只管理Eureka(包括Server和Client)
Bootstrap上下文默認不再啓動
知曉原理的同學知道,Spring Cloud容器是靠Bootstrap Context
引導上下文來啓動的,對應的類是BootstrapApplicationListener
。
這在2020.0版本發生了改變,新版本的Spring Cloud不再依賴於此上下文而啓動。因此默認情況下,將不再啓動Bootstrap上下文。代碼層面的改變發生在這裏:
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); }
開啓方式
若你需要開啓Bootstrap上下文,有兩種辦法可以實現:
- 設置值
spring.cloud.bootstrap.enabled=true
或者spring.config.use-legacy-processing=true
即可。注意:這些個屬性值必須確保其能放進環境裏才能生效。比如靠譜的方式是:系統屬性、環境變量、命令行等 - 引入一個Jar:
org.springframework.cloud:spring-cloud-starter-bootstrap
,然後什麼都不用做了- 說明:這個jar裏面有且僅有一個
Marker
類,作用你懂的,此處不做過多解釋
- 說明:這個jar裏面有且僅有一個
說明:手動開啓Bootstrap上下文,證明你fallback到老的方式去加載SC,那麼一切請按照老方式做即可
3、全新的配置方式
得益於Spring Boot 2.4.x支持全新的配置文件書寫方式,自此可以使用spring.config.import
倆導入其它組建的配置。如:
- spring.config.import=configserver:xxx
- spring.config.import=zookeeper:
- ...
這麼做更具模塊化,更符合雲原生環境的要求。
最新 Maven 依賴管理方式:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>2020.0.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
...
</dependencies>
https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2020.0-Release-Notes
https://docs.spring.io/spring-cloud/docs/current/reference/html/
k8s
究竟是何方神聖?下面我就拿 K8S
以及 Istio
的概念和 Spring Cloud
對比一下:
k8s概念 | spring cloud概念 | 功能 |
---|---|---|
pod | container | 部署的基本單位 |
service | eureka | 服務註冊與發現 |
ingress | zuul | 網關路由、反向代理 |
dns server | feign | 負載均衡 |
config map | config | 配置管理 |
istio envoy | hystrix | 熔斷降級 |
istio envoy | seluth & zipkin | 鏈路追蹤 |
deployment | 災備擴容 | |
StatefullSet | 有狀態集羣 |
以上的比較並不充分體現兩者的差異,也不完全準確,僅供參考。