扒一扒Spring家族的前世今生
在Spring框架没有开发出来时，JAVA EE是以Sun公司（已经被Oracle公司收购，不复存在，但为了纪念其对Java发展进程的巨大影响力，全书还是保留其名称，以表致敬之意）所制定的EJB（Enterprise Java Bean）作为标准的。
在“遥远”的EJB年代，开发一个EJB需要大量的接口和配置文件，直至EJB 2.0的年代，开发一个EJB还需要配置两个文件，其结果就是配置的工作量比开发的工作量还要大。
其次EJB是运行在EJB容器中的，而Sun公司定义的JSP和Servlet却是运行在Web容器中的，于是你可以想象得到，你需要使用Web容器去调用EJB容器的服务。
这就意味着存在以下的弊端：需要增加调用的配置文件才能让Web容器调用EJB容器；与此同时需要开发两个容器，非常多的配置内容和烦琐的规范导致开发效率十分低下，这非常让当时的开发者诟病；对于Web容器调用EJB容器的服务这种模式，注定了需要通过网络传递，造成性能不佳；对于测试人员还需要了解许多EJB烦琐的细节，才能进行配置和测试，这样测试也难以进行。
就在大家诟病EJB的时候，2002年澳大利亚工程师Rod Johnson（论学历他应该是音乐家，因为他是音乐博士）在其著名的著作Expert One-on-One J2EE Design and Development中提出了Spring的概念。
然后在2004年由Rod Johnson主导的Spring项目推出了1.0版本，这彻底地改变了Java EE开发的世界，很快人们就抛弃了繁重的EJB的标准，迅速地投入到了Spring框架中，于是Spring成为了现实中Java EE开发的标准。
Spring以强大的控制反转（IoC）来管理各类Java资源，从而降低了各种资源的耦合；并且提供了极低的侵入性，也就是使用Spring框架开发的编码，脱离了Spring API也可以继续使用。
而Spring的面向切面的编程（AOP）通过动态代理技术，允许我们按照约定进行配置编程，进而增强了Bean的功能，它擦除了大量重复的代码，如数据库编程所需大量的try…catch…finally…语句以及数据库事务控制代码逻辑，使得开发人员能够更加集中精力于业务开发，而非资源功能性的开发。
Spring还提供许多整合了当时非常流行的框架的模板，如持久层Hibernate的HibernateTemplate模板、iBATIS的SqlMapClientTemplate模板等，极大地融合并简化了当时主流技术的使用，使得其展示了强有力的生命力，并延续至今。
值得一提的是，EJB 3.0的规范也引入了Spring的理念，而且整合了Hibernate框架的思想，但是也未能挽回其颓势，主要原因在于它的规范还是比较死板，而且比较难整合其他开源框架。其次，它运行在EJB容器之中，使用上还是比较困难，性能也不高。
注解还是XM
只是在Spring早期的1.x版本中，由于当时的JDK并不能支持注解，因此只能使用XML。而很快随着JDK升级到JDK5，它加入了注解的新特性，这样注解就被广泛地使用起来，于是Spring的内部也分为了两派，一派是使用XML的赞同派，一派是使用注解的赞同派。
为了简化开发，在Spring 2.x之后的版本也引入了注解，不过只是少量的注解，如@Component、@Service等，但是功能还不够强大，因此对于Spring的开发，绝大部分的情况下还是以使用XML为主，注解为辅。
到了Spring 3.0后，引入了更多的注解功能，于是在Spring中产生了这样一个很大的分歧，即是使用注解还是使用XML？对于XML的引入，有些人觉得过于繁复，而对于注解的使用，会使得注解分布得到处都是，难以控制，有时候还需要了解很多框架的内部实现才能准确使用注解开发所需的功能。
这个时候大家形成了这样的一个不成文的共识，对于业务类使用注解，例如，对于MVC开发，控制器使用@Controller，业务层使用@Service，持久层使用@Repository；而对于一些公用的Bean，例如，对于数据库（如redis）、第三方资源等则使用XML进行配置，直至今时今日这样的配置方式还在企业中广泛地使用着。
也许使用注解还是XML是一个长期存在的话题，但是无论如何都有道理。
随着注解的功能增强，尤其是Servlet 3.0规范的提出，Web容器可以脱离web.xml的部署，使得Web容器完全可以基于注解开发，对于Spring 3.x和Spring 4.x的版本注解功能越来越强大，对于XML的依赖越来越少，到了4.x的版本后甚至可以完全脱离XML，因此在Spring中使用注解开发占据了主流的地位。
与此同时，Pivotal团队在原有Spring的基础上主要通过注解的方式继续简化了Spring框架的开发，它们基于Spring框架开发了Spring Boot，所以Spring Boot并非是代替Spring框架，而是让Spring框架更加容易得到快速的使用。
Pivotal团队在2014年推出Spring Boot的1.0版本，该版本使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。在2018年3月Spring Boot推出了2.0.0 GA版本，该版本是基于Spring 5的，并引入其最新的功能，能够有效支持Java 9的开发。
Spring Boot致力于在蓬勃发展的快速应用开发领域（rapid Application development）借助Java EE在企业互联网的强势地位成为业界领导者，它也是近年来Java开发最令人感到惊喜的项目之一。
随着近年来微服务的流行，越来越多的企业需要快速的开发，而Spring Boot除了以注解为主的开发，还有其他的绑定，例如，对服务器进行了绑定和默认对Spring的最大化配置，所以开发者能够尽快进行开发代码、发布和测试自己的项目。
这符合了现今微服务快速开发、测试和部署的需要，于是越来越多的企业选择Spring Boot作为开发的选型，进而使得Spring Boot更加兴旺起来。本书主要就是论述Spring Boot这一令人激动的开发工具。
Spring Boot的优点
谈到Spring Boot，就让我们先来了解它的优点。依据官方的文档，Spring Boot的优点如下：
创建独立的Spring应用程序；
嵌入的Tomcat、Jetty或者Undertow，无须部署WAR文件；
允许通过Maven来根据需要获取starter；
尽可能地自动配置Spring；
提供生产就绪型功能，如指标、健康检查和外部配置；
绝对没有代码生成，对XML没有要求配置。
这段描述告诉我们，首先Spring Boot是一个基于Spring框架搭建起来的应用，其次它会嵌入Tomcat、Jetty或者Undertow等服务器，并且不需要传统的WAR文件进行部署，也就是说搭建Spring Boot项目并不需要单独下载Tomcat等传统的服务器。
同时提供通过Maven（或者Grandle）依赖的starter，这些starter可以直接获取开发所需的相关包，通过这些starter项目就能以Java Application的形式运行Spring Boot的项目，而无须其他服务器配置。
对于配置，Spring Boot提供Spring框架的最大自动化配置，大量使用自动配置，使得开发者对Spring的配置尽量减少。
此外还提供了一些监测、自动检测的功能和外部配置，与此同时没有附加代码和XML的配置要求。
约定优于配置，这是Spring Boot的主导思想。对于Spring Boot而言，大部分情况下存在默认配置，你甚至可以在没有任何定义的情况下使用Spring框架，如果需要自定义也只需要在配置文件配置一些属性便可以，十分便捷。
而对于部署这些项目必需的功能，Spring Boot提供starter的依赖，例如，spring-boot-starter-web捆绑了Spring MVC所依赖的包，spring-boot-starter-tomcat绑定了内嵌的Tomcat，这样使得开发者能够尽可能快地搭建开发环境，快速进行开发和部署，这就是Spring Boot的特色。也许作为传统开发者的你，还未能理解其意义，但这并不要紧。
为了展示Spring Boot的特色，下节将分别展示传统Spring MVC项目和简易的Spring Boot入门实例，并进行比较。
传统Spring MVC和Spring Boot的对比
在传统的Spring MVC项目开发中，开发一个简易的Spring MVC项目，需要配置DispatcherServlet，也需要配置Spring IoC的容器。你可以选择使用web.xml的配置来实现，当然，如果你使用的是Servlet 3.1规范，也可以继承由Spring MVC提供的AbstractAnnotationConfigDispatcherServletInitializer来配置Spring MVC项目。
这里先给出可以运行的代码示例，即使你还不熟悉Spring MVC也没有关系，这里只是为了说明开发比较烦琐而已，后面将详谈Spring MVC的开发原理。
假设你已经导入需要的Spring和Spring MVC相关的依赖包到工程中，那么就可以开始配置DispatcherServlet了。例如，代码清单1-1就是通过继承AbstractAnnotationConfigDispatcherServletInitializer的方式来配置Spring MVC的DispatcherServlet的。
代码清单1-1 配置Spring MVC注意代码中加粗的地方。这里引入了一个Java配置文件—— WebConfig.java，它的主要作用是配置Spring MVC的核心类DispatcherServlet的上下文，如代码清单1-2所示。
代码清单1-2 配置DispatcherServlet的上下文
通过上面的代码，配置完成Spring MVC的开发环境后，才可以开发Spring MVC控制器Controller，这样就可以开发一个简单的控制器（Controller），如代码清单1-3所示。
代码清单1-3 开发Spring MVC控制器
这样就完成了一个传统Spring MVC的开发，但是你还需要第三方服务器，如Tomcat、WebLogic等服务器去部署你的工程。在启动服务器后，再打开浏览器，输入对应的URL，如项目名称为SpringMVC则输入http://localhost:8080/SpringMVC/test.do，就可以得到图1-1所示的页面。
图1-1 测试传统的Spring MVC项目
从上面来看，传统的Spring MVC开发需要配置的内容还是比较多的，而且对设计人员要求较高。开发完成后，开发者还需要找到对应的服务器去运行，如Tomcat或者Jetty等，这样既要进行开发，又要进行配置和部署，工作量还是不少的。
而使用Spring Boot开发后，你就会发现原来一切可以那么简单。不过在入门阶段暂时不需要讨论太多的细节问题，这是未来需要讨论的问题，所以这里只展示它是如何简单而已。首先我们在IDE中创建一个Maven工程，并把其名称定义为Chapter1，这样就可以看到一个Maven配置文件pom.xml，将其内容修改为如代码清单1-4所示。
代码清单1-4 配置Spring Boot依赖环境
从加粗的代码中可以看到Maven的配置文件引入了多个Spring Boot的starter，Spring Boot会根据Maven配置的starter去寻找对应的依赖，将对应的jar包加载到工程中，而且它还会把绑定的服务器也加载到工程中，这些都不需要你再进行处理。正如Spring Boot承诺的那样，绑定服务器，并且实现Spring的尽可能的配置，采用约定优于配置的原则。这里我们只需要开发一个类就可以运行Spring Boot的应用了，为此新建类——Chapter1Main，如代码清单1-5所示。
代码清单1-5 开发Spring Boot应用
好了，这个入门实例已经完结了。如果你没有接触过Spring Boot那么你会十分惊讶，这样就配置完成Spring MVC的内容了吗？我可以回答你：“是的，已经完成了，现在完全可以使用Java Application的形式去运行类Chapter1Main。”下面是Spring Boot的运行日志：
从日志中可以看到，Tomcat已经启动，并且将我们开发的Chapter1Main作为Spring MVC的控制器加载进来了，也将对应的路径（/test）映射到开发的test方法上。因此，接下来就可以进行测试了。打开浏览器，在地址栏输入http://localhost:8080/test，可以看到如图1-2所示的结果。
图1-2Spring Boot运行结果
与传统的Spring MVC是不是很不一样呢？从上面的对比可以看出，Spring Boot 允许直接进行开发，这就是它的优势。在传统所需要配置的地方，Spring Boot都进行了约定，也就是你可以直接以Spring Boot约定的方式进行开发和运行你的项目。
当你需要修改配置的时候，它也提供了一些快速配置的约定，犹如它所承诺的那样，尽可能地配置好Spring项目和绑定对应的服务器，使得开发人员的配置更少，更加直接地开发项目。
对于那些微服务而言，更喜欢的就是这样能够快速搭建环境的项目，而Spring Boot提供了这种可能性，同时Spring Boot还提供了监控的功能。
随着云技术的到来，微服务成了市场的热点，于是代表Java微服务时代的Spring Boot微服务开发的时代已经到来，结合Spring Cloud后它还能很方便地构建分布式系统开发，满足大部分无能力单独开发分布式架构的企业所需，所以这无疑是激动人心的。
