挑戰權威，一戰成名

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的“輕量級”在其他動態語言面前就顯得不那麽輕了。
具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的可以加群。java架構群：582505643一起交流。

輪子大師，前途未蔔

在之後的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中整合了不少優秀的第三方組件，這些組件的升級也需要我們做好一定的考量，在這些組件的版本升級過程中，使用上是否有變化等問題。其中，最為關鍵的幾個組件需要我們註意：
具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的可以加群。java架構群：582505643一起交流。
?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的忠實擁護者，在時間允許的情況下，這是一件必然會去嘗試的事情，在未來的時間裏，我也盡可能的希望抽出時間繼續分享一些其中的問題與收獲，與大家共勉！

阿裏P9告訴你 Spring Boot 2.0正式發布，升還是不升呢？