在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后它還能很方便地構建分布式系統開發，滿足大部分無能力單獨開發分布式架構的企業所需，所以這無疑是激動人心的。
