分享、成长，拒绝浅藏辄止。关注公众号【BAT的乌托邦】，回复关键字专栏有Spring技术栈、中间件等小而美的原创专栏供以避免费学习。本文已被 www.yourbatman.cn 收录。java

✍前言

你好，我是YourBatman。程序员

北京时间2020-12-22深夜，Spring Cloud 2020.0.0版本正式发布。2020.0.0是第一个使用新版本方案的Spring Cloud发行版本。spring

关于版本号这里啰嗦几句：在这以前，Spring Cloud的Release Train名称采用的是伦敦地铁站命名方式，如：Hoxton、Greenwich等。编程

说明：2020.0.0版本又名Ilford（地铁站名），由于此项目3月后才按照新规改名，估计是为了团队内沟通方便吧，你也能够理解为它仅是一个内部代号而已，方便沟通bootstrap

虽按照字母表顺序排列，但仍存在两个致命问题：安全

对非英语母语国家（好比天朝）很是不友好，没法快速理清版本号关系
A-Z，假若版本号到Z了呢？如何继续发展？你品，你细品

Spring团队意识到了这的确是个问题，所以在今年3月份做出了改变。详情参考我前面写的一篇文章（强烈建议每一个进来的你都了解下此次规则变动）：Spring改变版本号命名规则：此举对非英语国家很友好markdown

说明：版本号规则变动适用于全部Spring技术栈，包含Spring Framework、Spring Boot、Spring Cloud、Spring Data...app

文归正传。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

一、再见了，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暂还未放弃它

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
复制代码

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负载均衡器的使用，官方有个极其建议教程：spring.io/guides/gs/s…

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抽象，那里是精华。

二、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，而后什么都不用作了
1. 说明：这个jar里面有且仅有一个Marker类，做用你懂的，此处不作过多解释

说明：手动开启Bootstrap上下文，证实你fallback到老的方式去加载SC，那么一切请按照老方式作便可

三、全新的配置方式

得益于Spring Boot 2.4.x支持全新的配置文件书写方式，自此可使用spring.config.import俩导入其它组建的配置。如：

spring.config.import=configserver:xxx
spring.config.import=zookeeper:
...

这么作更具模块化，更符合云原生环境的要求。

四、其它

以前若要禁用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

// old
@Endpoint(id = "service-registry")
public class ServiceRegistryEndpoint { ... }

// new
@Endpoint(id = "serviceregistry")
public class ServiceRegistryEndpoint { ... }
复制代码

常规式升级

常规升级这块关注点就没那么多了，主要对其组件如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，显然这就属于大版本号的迭代了，须要谨慎啊。

你以为Spring Cloud团队在2020年还会发版吗？欢迎在评论区留下你的见解。

✔✔✔推荐阅读✔✔✔

【Spring类型转换】系列：

【Jackson】系列：

【数据校验Bean Validation】系列：

【新特性】系列：

【程序人生】系列：

还有诸如【Spring配置类】【Spring-static】【Spring数据绑定】【Spring Cloud Netflix】【Feign】【Ribbon】【Hystrix】...更多原创专栏，关注BAT的乌托邦回复专栏二字便可所有获取，也可加我fsx1056342982，交个朋友。

有些已完结，有些连载中。我是A哥(YourBatman)，我们下期见

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

✍前言