【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

Spring Boot 2.0 正式发布,新特性解读

  • 2018-03-01
  • 本文字数:5121 字

    阅读完需:约 17 分钟

写在前面

北京时间 3 月 1 日,经过漫长的等待之后,Spring Boot 2.0 正式发布。作为 Spring 生态中的重要开源项目,Spring Boot 旨在简化创建产品级的 Spring 应用和服务。用户只需要"run"就能创建一个独立的,产品级别的 Spring 应用。

一经发布,Spring Boot 就迅速受到了开发者的青睐,到目前为止,它已经有超过 2 万个 Star,1.6 万个 fork(2017 年 GitHub 排名前十)。而 Spring Boot 2.0 的酝酿已有一段时间,从去年 5 月 16 日发布 M1 版本,再到后来的 RC 版本,也已有近 1 年时间。

Spring 2.0 中引入了众多令人激动的新特性,包括支持 Java 9、HTTP/2、基于 Spring 5 构建、强力集成 GSON 等等。为了了解 Spring Boot 的整体发展历史,以及 2.0 中的重要更新,InfoQ 特邀请到 Spring Boot 专家、永辉云创架构师翟永超撰文解读。

Spring 帝国

Spring 几乎是每一位 Java 开发人员都耳熟能详的开发框架,不论你是一名初出茅庐的程序员还是经验丰富的老司机,都会对其有一定的了解或使用经验。在现代企业级应用架构中,Spring 技术栈几乎成为了 Java 语言的代名词,那么 Spring 为什么能够在众多开源框架中脱颖而出,成为业内一致认可的技术解决方案呢?我们不妨从最初的 Spring Framework 开始,看看它为什么能够横扫千军,一统江湖!

挑战权威,一战成名

2004 年 3 月,Spring 的第一个版本以及其创始人 Rod Johnson 的经典力作《Expert one-on-one J2EE Development without EJB》发布,打破了当时 Java 开发领域的传统思考模式,企业级应用开始走向“轻量化”发展的步伐。

最初的 Spring Framework 1.0 并不像如今的 Spring 那么复杂,但是在该版本中已经包含了 Spring 中最为核心的两大要素:依赖注入(IOC)和面向切面编程(AOP),这两个功能是 Spring 区别于其他优秀框架,并在企业级应用中建立核心地位的关键所在。

很多开发者在初涉 Java 应用的时候很可能会觉得这两个功能的意义并不大,因为不用它们我们依然可以很好的实现业务功能,事实也确实如此,但是随着业务的迭代和开发的深入,复杂多变的需求开始慢慢侵蚀原本“完美”的架构,开发与测试的难度逐步增大,往往在这个时候,我们才体会到了 Spring 的价值。

所以,即便在 Spring 的最初版本中也封装了诸多偏业务型的功能封装,如:邮件发送、事务管理等,但我们要知道真正让企业级应用离不开 Spring 的理由并不是这些与业务直接相关的功能,而是上面所提及的与业务实现毫不相关的两大核心。

由于在初期版本中 Spring 对很多功能性封装并没有今天的 Spring 那么强大,所以很长一段时间,我们都采用了 Spring 做工程管理来整合其他更优秀的功能型框架来完成系统开发的架构模式,比如曾经风靡一时的 Spring + Struts + Hibernate 架构,相信可以勾起一代人的回忆。

优雅灵活,吸粉无数

Spring 在发布并获得业界的普遍认可之后,Spring 开源社区变得异常活跃,除了社区自身不断对 Spring 进行增强之外,其他功能性框架也纷纷对 Spring 进行适配与支持。在随后发布的 Spring 2.x 和 3.x 中,先后支持了 Annotation 的优雅配置方式以及更为灵活的 Java 类的配置,这使得 Spring 在管理 Bean 的配置方式上变得更为多样化。

但是随着 Spring 的深入应用,繁琐的配置问题也开始显现,我们会发现每次在构建项目的时候总是在不断的复制黏贴着一些模版化的配置与代码,有时候我们只是想实现几个很简单的功能,结果配置内容远大于业务逻辑代码的编写;同时,在框架整合过程中,对于一些共同依赖的 Jar 包存在着潜在的冲突风险,使得一些复杂的整合任务变得困难起来。所以,Spring 的“轻量级”在其他动态语言面前就显得不那么轻了。

轮子大师,前途未卜

在之后的 Spring 4.x 中除了提供对 Java 8 的支持以及对依赖注入的增强之外,有很长一段时间,Spring 社区对其核心框架的创新就没有那么出彩了,社区更多的精力开始将矛头转向了曾经那些亲密无间的小伙伴们。于是,我们在 Spring 社区发现多出了各种功能性的兄弟项目,比如:简化数据访问的 Spring Data、提供批处理能力的 Spring Batch、用于保护应用安全的 Spring Security 等。

虽然这些框架从个体来说都有一定的优势和先进的理念,但是对于很多既有系统来说,在功能性框架上很难做出改变,对于这些新生的轮子项目就很难得到应用,除了一些从零开始的系统会做一些尝试之外,鉴于学习成本和踩坑风险的考虑,中小团队对这些新项目很少有愿意去尝试的。所以,一些老牌的功能性框架除非有严重的性能或安全问题出现,不然很难被这些轮子所替代。

在这段时间里,虽然 Spring 社区推出了那么多的轮子项目,但是真正在国内得到广泛应用的并不多,很多开发团队依然只是使用最核心的 IOC 和 AOP,并根据自己团队的技术栈情况整合出更适合自身的脚手架来进行系统开发。

神兵出世,再创辉煌

2014 年 4 月 1 日,Spring Boot 发布了第一个正式版本。该项目旨在帮助开发者更容易地创建基于 Spring 的应用程序和服务,使得现有的和新的 Spring 开发者能够最快速地获得所需要的 Spring 功能。一直到今天发布 2.x 版本,共经历了近 4 年的发展,Spring Boot 已经是一个拥有了 21000 多 Star,15000 多次 Commits,贡献者超过 400 多名的超热门开源项目。

Spring Boot 为什么突然如此备受关注与推崇呢?主要有以下几点:

  • 简化依赖管理:在 Spring Boot 中提供了一系列的 Starter POMs,将各种功能性模块进行了划分与封装,让我们可以更容易的引入和使用,有效的避免了用户在构建传统 Spring 应用时维护大量依赖关系而引发的 JAR 冲突等问题。
  • 自动化配置:Spring Boot 为每一个 Starter 都提供了自动化的 Java 配置类,用来替代我们传统 Spring 应用在 XML 中繁琐且并不太变化的 Bean 配置;同时借助一系列的条件注解修饰,使得我们也能轻松的替换这些自动化配置的 Bean 来进行扩展。
  • 嵌入式容器:除了代码组织上的优化之外,Spring Boot 中支持的嵌入式容器也是一个极大的亮点(此处仿佛又听到了 Josh Long 的那句:“Deploy as a Jar, not a War”),借助这个特性使得 Spring Boot 应用的打包运行变得非常的轻量级。
  • 生产级的监控端点:spring-boot-starter-actuator的推出可以说是 Spring Boot 在 Spring 基础上的另一个重要创新,为 Spring 应用的工程化变得更加完美。该模块并不能帮助我们实现任何业务功能,但是却在架构运维层面给予我们更多的支持,通过该模块暴露的 HTTP 接口,我们可以轻松的了解和控制 Spring Boot 应用的运行情况。

Spring Boot 虽然是基于 Spring 构建的,但是通过上面这些特性的支持,改变了我们使用 Spring 的姿势,极大得简化了构建企业级应用的各种配置工作,尤其对于很多初学者来说,变得更加容易入门使用。

如约而至,升级与否?

万众期待的 Spring Boot 2.0 终于发布了第一个正式版本,为什么 Spring Boot 2.0 如此受期待呢?我认为主要有以下几个原因:

  1. 支持最新的 Java 9
  2. 基于 Spring 5 构建,Spring 的新特性均可以在 Spring Boot 2.0 中使用
  3. 为各种组件的响应式编程提供了自动化配置,如:Reactive Spring Data、Reactive Spring Security 等
  4. 支持 Spring MVC 的非阻塞式替代方案 WebFlux 以及嵌入式 Netty Server
  5. Spring Boot 2.0 的发布,Spring Cloud Finchley 还会远吗?

上述列举的内容是笔者主要关心的重要内容,并非 Spring Boot 2.0 所有的新特性,对于不同的使用者来说相信会有不同的关注点。

除此之外,在 Spring Boot 2.0 中还有非常多其他令人振奋的新特性,比如:对 HTTP/2 的支持、新增了更灵活的属性绑定 API(可以不通过@ConfigurationProperties注解就能实现配置内容读取和使用)、对 Spring Security 整合的简化配置、Gradle 插件的增强、Actuator 模块的优化等等。

本文不对这些新特性做详细的介绍,下面主要说说,我们是否有必要将我们的 Spring Boot 1.x 升级到 Spring Boot 2.x,在这过程中,我们需要考虑和注意哪些问题。

Java 版本要求的变化

我们在选择是否要升级 Spring Boot 的时候,最先需要考虑的是 Java 版本的选择。在 Spring Boot 2.0 中提高了对 Java 版本的要求,我们需要至少使用 Java 8 才能使用它,如果你的 Spring Boot 应用还运行在 Java 7 上,那就还得考虑 Java 的升级成本。

另外,在未来的一段时间内,你是否想要使用 Java 9 将是一个影响升级与否的重要决策依据,因为 Spring Boot 1.x 版本明确说明了没有对 Java 9 的支持计划;换言之,如果你想将 Spring Boot 运行在 Java 9 上,那么你必须升级到 Spring Boot 2.0。

Tips:当前版本的 Spring Boot 2.0 虽然支持 Java 9,但是依然还有一些问题。比如:JDK 的代理支持需要使用 AspectJ 1.9,但是该版本还处于 RC 版;还不支持 Apache Cassandra;对于 JSP TLDs 在嵌入式 Tomcat 中也无法支持等情况。对于这些问题的具体处理方法可见: Running Spring Boot on Java 9

依赖组件的升级

Spring Boot 的 Starter 中整合了不少优秀的第三方组件,这些组件的升级也需要我们做好一定的考量,在这些组件的版本升级过程中,使用上是否有变化等问题。其中,最为关键的几个组件需要我们注意:

  • Tomcat 升级至 8.5
  • Flyway 升级至 5
  • Hibernate 升级至 5.2
  • Thymeleaf 升级至 3

Tips:前几日曝出的 Tomcat 漏洞问题。经查 Spring Boot 2.0 选用的版本为 8.5.28,属于安全版本,所以大家可以放心使用。

依赖重组和配置重定位

在 Spring Boot 2.0 的升级过程中,可能这部分内容将是大家要做出较多修改的地方,所以建议大家在这里留个心眼。由于 Spring Boot 在构建 Starter POMs 的时候并非是扁平的一层结构,一些功能模块 Starter 之间是存在包含引用关系的,比如:spring-boot-starter-thymeleaf 中包含了 spring-boot-starter-web,因为 thymeleaf 模版引擎之前肯定是在 Spring MVC 下使用的。

但是,在 Spring Boot 2.0 中,WebFlux 的出现对于 Web 应用的解决方案将不再唯一,因此 spring-boot-starter-thymeleaf 中的依赖就不在包含 spring-boot-starter-web,开发人员需要自己添加 spring-boot-starter-web 或 spring-boot-starter-webflux 来决定是使用哪个模块实现 Web 应用。

除了类似上面的依赖重组之后,在 Spring Boot 2.0 中对于配置属性的重定位也是比较多的,这将导致一些原有的配置将不再生效,需要我们手工的去修改这些配置的 Key 来完成升级适配。比如,一些与 servlet 相关的server.*属性重定位到server.servlet前缀下:

Old property New property server.context-parameters.* server.servlet.context-parameters.* server.context-path server.servlet.context-path server.jsp.class-name server.servlet.jsp.class-name server.jsp.init-parameters.* server.servlet.jsp.init-parameters.* server.jsp.registered server.servlet.jsp.registered server.servlet-path server.servlet.path更多的依赖变化、配置重定位以及默认配置的变化,读者可自行查阅官方升级手册:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide

不必要的顾虑

之前有朋友在 spring4all 社区上问:如果 Spring Boot 升级 2.0,2.0 出了那么多新功能,我们的业务代码是否也需要随之修改,风险会不会很大?其实,这个问题大家完全不用太多的顾虑,Spring Boot 2.0 虽然新增了很多强大的新特性,但是对于原有功能的支持并没有抛弃。所以,就算我们不用任何类似 WebFlux 这样的新功能,将工程升级到了 Spring Boot 2.0 之后,继续使用 Spring MVC 开发我们的项目也是完全没有影响的。只是,就如上面所述的,我们可能需要做一些依赖和配置上的调整才能继续将应用正常的运行起来。

总结与展望

感谢大家能够读完上面我对 Spring Boot 2.0 的薄见,希望这些内容能够对你在 Spring Boot 2.0 的选择上有一定的参考价值。这个版本虽然不像 Spring Boot 1.0 那样颠覆我们对繁琐的 Spring 应用的认识,但是依然透露着很多时代前沿的气息。同时,Spring Boot 2.0 的发布,也意味着 Spring Cloud Finchley 里正式发布又近了一步,因为这个版本中同样的将会带来很多令人兴奋的内容,相信这一天的到来也不远了!

对于当前 Spring Boot 2.0 的迁移升级,作为一名 Spring Boot 与 Spring Cloud 的忠实拥护者,在时间允许的情况下,这是一件必然会去尝试的事情,在未来的时间里,我也尽可能的希望抽出时间继续分享一些其中的问题与收获,与大家共勉!

参考资料

作者介绍

翟永超,供职于永辉云创,任架构师,负责 Spring Cloud 微服务架构的落地。《Spring Cloud 微服务实战》作者,spring4all 社区 发起人。

欢迎关注我的个人博客:程序猿 DD

2018-03-01 17:2321539

评论

发布
暂无评论
发现更多内容

TiDB学习之路

TiDB 社区干货传送门

实践案例

TiDB 在 Cisco Webex 架构中的部署和应用

TiDB 社区干货传送门

传统行业数据架构发展变化

TiDB 社区干货传送门

数据库架构选型

【考试指南】TiDB 5.0认证指南之PCTA PCTP

TiDB 社区干货传送门

TiDB 底层架构

TiSpark On Kubernetes实践

TiDB 社区干货传送门

实践案例

记一次TiDB的临时救场

TiDB 社区干货传送门

实践案例

高并发请求下 TiDB 集群的业务无损升级

TiDB 社区干货传送门

dm-V1.0.5使用汇总

TiDB 社区干货传送门

管理与运维

探索TiDB Lightning源码来解决发现的bug

TiDB 社区干货传送门

TiDB 底层架构

JOIN 查询的执行计划 比较

TiDB 社区干货传送门

性能调优 TiDB 底层架构

记一次简单的Oracle离线数据迁移至TiDB过程

TiDB 社区干货传送门

TiDB 运维基础操作脑图

TiDB 社区干货传送门

骏彩竞猜分布式解决方案之路

TiDB 社区干货传送门

安装 & 部署

使用 TiUP 安装部署 TiDB 集群实验流程

TiDB 社区干货传送门

版本升级 集群管理 管理与运维 安装 & 部署 扩/缩容

TiDB Binlog 支持 Oracle 目标库功能用户手册

TiDB 社区干货传送门

迁移

关于TiDB数据脱敏的一些想法

TiDB 社区干货传送门

实践案例

TiSpark数据写入过程解析(源码解析)

TiDB 社区干货传送门

TiDB 底层架构

使用SPM固定执行计划

TiDB 社区干货传送门

TiDB体系结构

TiDB 社区干货传送门

TiDB 底层架构

大事务的处理方式对比

TiDB 社区干货传送门

实践案例

TiDB BR 备份至 MinIO S3 实战

TiDB 社区干货传送门

管理与运维

前缀索引在特殊场景下的优化尝试

TiDB 社区干货传送门

实践案例 TiDB 底层架构

TiDB在个推的落地实践 | 解决热点难题,提升性能超千倍

TiDB 社区干货传送门

性能调优

TiDB 元信息管理方式

TiDB 社区干货传送门

TiDB 底层架构

TiDB 如何在 LVS FULL NAT 模式下显示客户端真实 IP

TiDB 社区干货传送门

实践案例

一言难尽的Prometheus监控实践

TiDB 社区干货传送门

实践案例

5分钟搞定 MySQL 到 TiDB 的数据同步

TiDB 社区干货传送门

实践案例

TiDB监控Prometheus磁盘内存问题

TiDB 社区干货传送门

故障排查/诊断

TiCDC 4.0.15 初体验

TiDB 社区干货传送门

实践案例

TiDB 如何获取集群创建时间

TiDB 社区干货传送门

实践案例 TiDB 底层架构

TiDB 悲观事务模式和Mysql的表象区别

TiDB 社区干货传送门

Spring Boot 2.0正式发布,新特性解读_语言 & 开发_翟永超_InfoQ精选文章