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中最为核心的两大要素：依赖注入和面向切面编程，这两个功能是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终于发布了第一个正式版本，为什么Spring Boot 2.0如此受期待呢？我认为主要有以下几个原因：
- 支持最新的Java 9
- 基于Spring 5构建，Spring的新特性均可以在Spring Boot 2.0中使用
- 为各种组件的响应式编程提供了自动化配置，如：Reactive Spring Data、Reactive Spring Security等
- 支持Spring MVC的非阻塞式替代方案WebFlux以及嵌入式Netty Server
- 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 |
更多的依赖变化、配置重定位以及默认配置的变化，读者可自行查阅官方升级手册：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的忠实拥护者，在时间允许的情况下，这是一件必然会去尝试的事情，在未来的时间里，我也尽可能的希望抽出时间继续分享一些其中的问题与收获，与大家共勉！
