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的忠實擁護者，在時間允許的情況下，這是一件必然會去嘗試的事情，在未來的時間裡，我也儘可能的希望抽出時間繼續分享一些其中的問題與收穫，與大家共勉！
關注我：http://blog.didispace.com/