Spring Cloud 2020.0.0正式发布对开发者有哪些影响

时间：2026-08-21 16:42

北京时间 2020 年 12 月 22 日深夜，Spring Cloud 2020 0 0 版本正式发布。2020 0 0 是首个采用全新版本命名方案的 Spring Cloud 发行版。除了更直观、对开发者更友好的命名方式外，这次发布还全面告别了 Netflix 技术栈，并且属于一个长期维护的主要

北京时间 2020 年 12 月 22 日深夜，Spring Cloud 2020.0.0 版本正式发布。2020.0.0 是首个采用全新版本命名方案的 Spring Cloud 发行版。除了更直观、对开发者更友好的命名方式外，这次发布还全面告别了 Netflix 技术栈，并且属于一个长期维护的主要版本。那么，这一变化对 Java 开发者和微服务架构实践到底意味着什么？今天我们邀请到开源社区活跃作者 YourBatman 和 Spring Cloud Alibaba committer 冷冷，一起为大家解读此次 Spring Cloud 版本升级中的关键变化，更重要的是聊聊开发者后续应该如何应对和完成技术选型。

Spring Cloud 版本管理

在 Spring Cloud 2020.0.0 正式发布之前，Spring Cloud 的 Release Train 命名一直采用伦敦地铁站名称，并按照字母顺序排列，例如：Hoxton、Greenwich、Ilford 等。这种版本命名方式虽然有特色，但也存在两个明显问题：

对于非英语母语国家的开发者，比如中国开发者，并不友好，难以快速判断版本之间的先后关系和兼容性
英文字母只有 26 个，如果版本迭代到了 Z 之后，后续又该如何持续命名和扩展？

Spring Cloud 遵循Pivotal OSS support policy 协议，对主要版本提供三年的官方支持。此外，在 Spring Cloud 的主要版本或次要版本发布后，如果出现严重 bug 或安全漏洞，官方通常还会继续提供一段额外维护周期（一般为 6-12 个月）。可参考下表：

核心变化解读

作为一个主要版本，Spring Cloud 2020.0.0 带来了大量值得关注的变化。其中最受开发者关注的，是若干不向下兼容的阻断式更新。对于使用 Spring Cloud 微服务体系的团队来说，这次升级具有明显的里程碑意义。

核心变化一：再见了，Netflix

早在 2018 年，Spring Cloud 就在其 Roadmap 中明确表示，将逐步终结部分库与版本的演进，其中最核心的一项，就是 Spring Cloud Netflix 项目进入维护模式，并计划在 2020 年彻底移除。

Spring Cloud 做出这一决定，某种程度上并不完全是主动选择。长期以来，Spring Cloud 都把 Netflix OSS 套件视为官方默认的一站式微服务解决方案，在当时的技术语境下，Netflix OSS 几乎就等同于 Spring Cloud。然而，Netflix 公司在 2018 年前后宣布，其核心组件 Hystrix、Ribbon、Zuul、Archaius 等均进入维护状态，这也直接影响了 Spring Cloud 的后续技术路线。

到了今天，随着 Spring Cloud 2020.0 正式发布，在这个主要版本中，官方终于按照既定计划对 spring-cloud-netflix 动手了。我帮你画了一幅 spring-cloud-netflix-dependencies 的 xml 文件前后版本主要差异对比图，变化一目了然：

旧版本中的 spring-cloud-netflix-dependencies 统一管理 Netflix 全部核心组件，包括 Hystrix、Ribbon、Zuul、Eureka 等；而从 2020.0 版本开始，它只保留并管理 Eureka（含 Server 和 Client）。

核心变化二：继续推动业界标准，完善抽象定义

对于大多数 Spring Cloud 应用开发者来说，spring-cloud-commons 模块可能并不熟悉。但这个模块其实是 Spring Cloud 技术栈的核心基础，它提供了服务注册与发现、负载均衡、上下文管理等能力的统一抽象。像 spring cloud alibaba 这样的整套生态实现，本质上也是对 spring-cloud-commons 的具体落地。此次版本更新，也对上下文启动器的默认启动行为、负载均衡器核心代码等进行了相应调整和演进。

spring-cloud-commons
  ├── actuator
  ├── circuitbreaker
  ├── discovery
  ├── hypermedia
  ├── loadbalancer
  └── serviceregistry

核心变化三：强推 reactive 异步体系

reactor 是 reactive（反应式编程）的重要实现框架，也是 Pivotal 团队的核心作品之一。

无论是 Spring Cloud Gateway，还是 Spring Cloud Loadbalancer，这些关键组件都构建在 reactor 编程模型之上。这意味着 Spring Cloud 正在持续强化对异步化、非阻塞式、高并发编程体系的支持。

此外，Spring 官方布道师 Josh Long 最近还出版了《Reactive Spring》一书。如果你希望深入理解 Reactor 和 Spring Reactive 体系，不妨系统阅读这本书。

核心变化四：更好地拥抱云原生能力

Spring Cloud 2020 构建在 Spring Boot 2.4 之上，因此具备更强的配置文件处理机制，能够更好地适配云原生场景，例如可以直接对接 kubernetes 的 configMap 配置；同时还内置了 Docker 镜像构建与分层分析优化能力，进一步提升微服务部署效率。

如果你的团队正在使用 kubernetes，那么 spring-cloud-kubernetes 也会成为替代 Netflix 生态的一个不错选择。

组件替代方案

既然 Spring Cloud 已经大刀阔斧地裁剪了 Netflix 套件，那么自然需要一套新的替代方案。答案是肯定的，Spring Cloud 团队也给出了官方推荐的替代组件：

Spring Cloud LoadBalancer

在这些替代方案中，你可能最陌生、也最感兴趣的就是 Spring Cloud Loadbalancer。它最初只是 Spring Cloud 孵化器 中的一个小项目，并且一度被搁置。后来随着项目重启和持续发展，它开始承担更重要的职责，最终被正式用于完全替换 Ribbon，成为 Spring Cloud 负载均衡器的唯一实现。

如图所示，负载均衡抽象 LoadBalancerClient 接口曾经有两个实现；而在 Spring Cloud 2020.0 版本之后，BlockingLoadBalancerClient 成为了唯一实现。

目前，Spring Cloud LoadBalancer 仅支持轮询负载均衡策略。相比 Ribbon 提供的多种高可用负载均衡策略，它在能力层面仍然相对简单。

Spring Cloud Circuit Breaker

Circuit Breaker 提供了对多个断路器组件实现的统一抽象，允许开发人员根据团队熟悉度和业务场景，自由选择适合的断路器组件来完成微服务容错开发。

这里重点介绍一下 Sentinel 和 Resilience4j。Sentinel 作为 Spring Cloud Alibaba 的重要组件，只需引入 spring-cloud-starter-alibaba-sentinel，即可获得熔断降级、流量控制等能力，并且提供可视化控制台。作为同类方案，Resilience4j 是基于函数式设计的轻量级容错库，也支持熔断、限流、隔离等能力。不过，官方提供的 spring-cloud-starter-circuitbreaker-resilience4j 插件能力相对有限，且无法直接通过控制台管理；如果需要监控能力，还需额外接入 Micrometer 服务。

Spring Cloud Alibaba 适配

由于对 Ribbon 组件仍存在依赖，目前最新的 Spring Cloud Alibaba 2.2.3 还不能完全开箱即用地兼容 Spring Cloud 2020，不过通过少量微调即可完成适配。

// 排除 Ribbon (当然也可以排查 ma ven 依赖)
@EnableAutoConfiguration(excludeName =
"org.springframework.cloud.netflix.ribbon.RibbonAutoConfiguration")

增加 spring cloud loadbalancer 依赖。


    org.springframework.cloud
    spring-cloud-starter-loadbalancer

涉及加载配置中心的服务需要启动 bootstrap (2020 默认关闭)。



  org.springframework.cloud
  spring-cloud-starter-bootstrap

以上调整可以参考兼容适配 Spring Cloud 2020 示例。

开发者如何面对和拥抱变化

正如上文所述，Spring Cloud 提供了非常强的封装能力和抽象能力。例如 spring-cloud-circuit-breaker 就对常见容错组件做了统一封装，在实际使用中，开发者不一定非要直接依赖 @hystrixcommand``@SentinelResource 这类组件原生注解。

public static class DemoControllerService {
    private RestTemplate rest;
    private CircuitBreakerFactory cbFactory;
    public String slow() {
        return cbFactory.create("slow").run(() -> rest.getForObject("/slow", String.class), throwable -> "fallback");
    }
}

通过这类抽象屏蔽底层实现组件的变化，对于上层使用 Spring Cloud 全家桶的用户来说，整体影响其实并不大（例如《Spring Cloud Alibaba 迁移指南：零代码从 Eureka 迁移到 Nacos》）。
关于学习 spring-cloud-commns，笔者并不建议直接硬啃源码（部分 reactor 代码确实容易劝退），更推荐采用 DEBUG 具体实现类的方式进行调试和理解（例如 NacosDiscoveryClient），因为最核心的代码往往不过百行。

因此，对于开发者来说，无论之前使用的是 Netflix 技术栈，还是选择 Alibaba 技术栈，真正需要重点掌握的，始终是 spring-cloud-commons 提供的抽象能力，理解 Spring Cloud 标准尤为关键。

总结

Spring Cloud 2020.0.0 是 Spring Cloud 历史上非常重要的一个主要版本，无论从版本命名、组件体系，还是启动机制和技术路线来看，变化都非常大。尤其是 Netflix 模块的大规模移除、Spring Cloud 启动方式的变化等，都意味着微服务开发正式进入新阶段。随着 Spring Boot 2.4.x 与 Spring Cloud 2020.0 的发布，再加上 Netflix OSS 套件的淡出，Spring Cloud 生态必然会迈入一个新的深度编程体验阶段，值得持续关注与期待。

其实，我们也真心建议大家关注并尝试 Spring Cloud Alibaba 全家桶。截至目前，Spring Cloud Alibaba 已经开源两年多，而且早已从官方毕业。它的社区关注度和活跃度都很高，还通过知行动手实验室 start.aliyun.com 提供了沙箱环境、Ja va 工程脚手架，以及 Arthas 代码诊断工具等配套能力，已经成为工具链相对最完善的 Spring Cloud 实现方案之一。

推荐阅读

如何平滑将注册中心从 Eureka 迁移到 Nacos？
Spring Cloud Alibaba 迁移指南1：零代码从 Eureka 迁移到 Nacos
注册中心 Consul 迁移到 Nacos
掌门教育微服务体系 Solar 第 3 弹：Nacos 企业级落地上篇
Sentinel 与 Hystrix 的对比
Guideline: 从 Hystrix 迁移到 Sentinel

活动推荐

2021 年首场 Spring Cloud Alibaba Meetup 城市站活动，我们邀请到了阿里中间件分布式事务团队负责人季敏、《深入理解 Spring Cloud 与实战》作者方剑、Apache Dubbo PMC 方银城、Nepxion 开源社区创始人任浩军、知名互联网公司中间件架构师童子龙、七牛云技术经理姜智，一起畅聊 Go 语言与 Spring 生态发展趋势，深度分享知名互联网教育公司的微服务实战经验！点击此处即可报名参与~

来源：https://apiv1.oschina.net/oschinapi/blog/detail?id=4868873

其他

上一篇Nacos2.0架构设计与新模型深度解读：支持gRPC长连接 下一篇Kubernetes生产环境部署与运维最佳实践

本站内容用于信息整理与展示，如有侵权或内容问题请及时联系处理。