分析Spring框架的前世今生

這篇文章主要介紹“分析Spring框架的前世今生”，在日常操作中，相信很多人在分析Spring框架的前世今生問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”分析Spring框架的前世今生”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

本文學習目標

1、掌握 Spring 的基本架構及各子模塊之間的依賴關系。

2、了解 Spirng 的發展歷史，啟發思維。

3、對 Spring 形成一個整體的認識，為之后的深入學習做鋪墊。

4、了解 Spring 版本升級的規律，從而應用到自己的系統升級版本命名。

Spring 的前世今生

相信經歷過不使用框架開發 Web 項目的 70 后、80 后都會有如此感觸，如今的程序員開發項目太輕松 了，基本只需要關心業務如何實現，通用技術問題只需要集成框架便可。

早在 2007 年，一個基于 Java 語言的開源框架正式發布，取了一個非常有活力且美好的名字，叫做Spring。

它是一個開源的輕量級Java SE（Java 標準版本）/Java EE（Java 企業版本）開發應用框架，其目的是用于簡化企業級應用程序開發。

應用程序是由一組相互協作的對象組成。而在傳統應用程序開發中，一個完整的應用是由一組相互協作的對象組成。

所以開發一個應用除了要開發業務邏輯之外，最多的是關注如何使這些對象協作來完成所需功能，而且要低耦合、高聚合。業務邏輯開發是不可避免的，那如果有個框架出來幫我們來創建對象及管理這些對象之間的依賴關系。

可能有人說了，比如“抽象工廠、工廠方法模式”不也可以幫我們創建對象，“生成器模式”幫我們處理對象間的依賴關系，不也能完成這些功能嗎？

可是這些又需要我們創建另一些工廠類、生成器類，我們又要而外管理這些類，增加了我們的負擔，如果能有種通過配置方式來創建對象，管理對象之間依賴關系，我們不需要通過工廠和生成器來創建及管理對象之間的依賴關系，這樣我們是不是減少了許多工作，加速了開發，能節省出很多時間來干其他事。

Spring框架剛出來時主要就是來完成這個功能。

Spring 框架除了幫我們管理對象及其依賴關系，還提供像通用日志記錄、性能統計、安全控制、異常處理等面向切面的能力，還能幫我管理最頭疼的數據庫事務，本身提供了一套簡單的 JDBC 訪問實現，提供與第三方數據訪問框架集成（如 Hibernate、JPA），與各種 Java EE 技術整合（如 Java Mail、任務調度等等），提供一套自己的 Web 層框架 Spring MVC、而且還能非常簡單的與第三方 Web 框架集成。

從這里我們可以認為 Spring 是一個超級粘合大平臺，除了自己提供功能外，還提供粘合其他技術和框架的能力，從而使我們可以更自由的選擇到底使用什么技術進行開發。

而且不管是 JAVA SE（C/S 架構）應用程序還是 JAVA EE（B/S 架構）應用程序都可以使用這個平臺進行開發。如今的 Spring 已經不再是一個框架，早已成為了一種生態。

SpringBoot 的便捷式開發實現了零配置，SpringCloud 全家桶，提供了非常方便的解決方案。接下來，讓我們來深入探討 Spring 到底能給我們帶來什么？

一切從 Bean 開始

說到 Bean 這個概念，還得從 Java 的起源說起。

早在 1996 年，Java 還只是一個新興的、初出茅廬的編程語言。人們之所以關注她僅僅是因為，可以使用 Java 的 Applet 來開發 Web 應用，作為瀏覽器組件。

但開發者們很快就發現這個新興的語言還能做更多的事情。

與之前的所有語言不同，Java 讓模塊化構建復雜的系統成為可能（當時的軟件行業雖然在業務上突飛猛進，但當時開發用的是傳統的面向過程開發思想，軟件的開發效率一直踟躕不前。

伴隨著業務復雜性的不斷加深，開發也變得越發困難。

其實，當時也是 OOP 思想飛速發展的時期，她在 80 年代末被提出，成熟于 90 年代，現今大多數編程語言都已經是面向對象的）。

同年 12 月，Sun 公司發布了當時還名不見經傳但后來人盡皆知的 JavaBean 1.00-A 規范。早期的JavaBean 規范針對于 Java，她定義了軟件組件模型。

這個規范規定了一整套編碼策略，使簡單的 Java對象不僅可以被重用，而且還可以輕松地構建更為復雜的應用。

盡管 JavaBean 最初是為重用應用組件而設計的，但當時他們卻是主要用作構建窗體控件，畢竟在 PC 時代那才是主流。

但相比于當時正如日中天的 Delphi、VB 和 C++，它看起來還是太簡易了，以至于無法勝任任何"實際的"工作需要。

復雜的應用通常需要事務、安全、分布式等服務的支持，但 JavaBean 并未直接提供。

所以到了 1998年 3 月，Sun 公司發布了 EJB 1.0 規范，該規范把 Java 組件的設計理念延伸到了服務器端，并提供了許多必須的企業級服務，但他也不再像早期的 JavaBean 那么簡單了。

實際上，除了名字叫 EJB Bean以外，其他的和 JavaBean 關系不大了。

盡管現實中有很多系統是基于 EJB 構建的，但 EJB 從來沒有實現它最初的設想：簡化開發。

EJB 的聲明式編程模型的確簡化了很多基礎架構層面的開發，例如事務和安全；

但另一方面 EJB 在部署描述符和配套代碼實現等方面變得異常復雜。隨著時間的推移，很多開發者對 EJB 已經不再抱有幻想，開始尋求更簡潔的方法。

現在 Java 組件開發理念重新回歸正軌。新的編程技術 AOP 和 DI 的不斷出現，他們為 JavaBean 提供了之前 EJB 才能擁有的強大功能。這些技術為 POJO 提供了類似 EJB 的聲明式編程模型，而沒有引入 任何 EJB 的復雜性。

當簡單的 JavaBean 足以勝任時，人們便不愿編寫笨重的 EJB 組件了。

客觀地講，EJB 的發展甚至促進了基于 POJO 的編程模型。引入新的理念，最新的 EJB 規范相比之前的規范有了前所未有的簡化，但對很多開發者而言，這一切的一切都來得太遲了。

到了 EJB 3 規范發布時，其他基于 POJO 的開發架構已經成為事實的標準了，而 Spring 框架也就是在這樣的大環境下出現的。

Spring 的設計初衷

Spring 是為解決企業級應用開發的復雜性而設計，她可以做很多事。但歸根到底支撐 Spring 的僅僅是少許的基本理念，而所有的這些基本理念都能可以追溯到一個最根本的使命：簡化開發。

這是一個鄭重的承諾，其實許多框架都聲稱在某些方面做了簡化。而 Spring 則立志于全方面的簡化 Java 開發。

對此，她主要采取了 4 個關鍵策略：

1、基于 POJO 的輕量級和最小侵入性編程；

2、通過依賴注入和面向接口松耦合；

3、基于切面和慣性進行聲明式編程；

4、通過切面和模板減少樣板式代碼；

而他主要是通過：面向 Bean(BOP)、依賴注入DI以及面向切面AOP這三種方式來達成的。

BOP 編程伊始

Spring 是面向 Bean 的編程（Bean Oriented Programming, BOP），Bean 在 Spring 中才是真正的主角。Bean 在 Spring 中作用就像 Object 對 OOP 的意義一樣，Spring 中沒有 Bean 也就沒有 Spring存在的意義。

Spring 提供了 IOC 容器通過配置文件或者注解的方式來管理對象之間的依賴關系。

控制反轉(其中最常見的實現方式叫做依賴注入（Dependency Injection，DI），還有一種方式叫“依賴查找”（Dependency Lookup，DL），她在 C++、Java、PHP 以及.NET 中都運用。

在最早的Spring 中是包含有依賴注入方法和依賴查詢的，但因為依賴查詢使用頻率過低，不久就被 Spring 移除 了，所以在 Spring 中控制反轉也被直接稱作依賴注入)，她的基本概念是：不創建對象，但是描述創建 它們的方式。

在代碼中不直接與對象和服務連接，但在配置文件中描述哪一個組件需要哪一項服務。

容器 （在 Spring 框架中是 IOC 容器）負責將這些聯系在一起。

在典型的 IOC 場景中，容器創建了所有對象，并設置必要的屬性將它們連接在一起，決定什么時間調用方法。

依賴注入的基本概念

Spring 設計的核心 org.springframework.beans 包（架構核心是 org.springframework.core包），它的設計目標是與 JavaBean 組件一起使用。

這個包通常不是由用戶直接使用，而是由服務器將其用作其他多數功能的底層中介。下一個最高級抽象是 BeanFactory 接口，它是工廠設計模式的實現，允許通過名稱創建和檢索對象。BeanFactory 也可以管理對象之間的關系。

BeanFactory 最底層支持兩個對象模型。

1，單例：提供了具有特定名稱的全局共享實例對象，可以在查詢時對其進行檢索。Singleton 是默認的也是最常用的對象模型。

2，原型：確保每次檢索都會創建單獨的實例對象。在每個用戶都需要自己的對象時，采用原型模式。

Bean 工廠的概念是 Spring 作為 IOC 容器的基礎。

IOC 則將處理事情的責任從應用程序代碼轉移到框架。

AOP 編程理念

面向切面編程，即 AOP，是一種編程思想，它允許程序員對橫切關注點或橫切典型的職責分界線的行為（例如日志和事務管理）進行模塊化。

AOP 的核心構造是方面（切面），它將那些影響多個類的行為封裝到可重用的模塊中。

AOP 和 IOC 是補充性的技術，它們都運用模塊化方式解決企業應用程序開發中的復雜問題。

在典型的面向對象開發方式中，可能要將日志記錄語句放在所有方法和 Java 類中才能實現日志功能。

在 AOP方式中，可以反過來將日志服務模塊化，并以聲明的方式將它們應用到需要日志的組件上。

當然，優勢就是 Java 類不需要知道日志服務的存在，也不需要考慮相關的代碼。所以，用 Spring AOP 編寫的應用程序代碼是松散耦合的。

AOP 的功能完全集成到了 Spring 事務管理、日志和其他各種特性的上下文中。

AOP 編程的常用場景有：Authentication（權限認證）、Auto Caching（自動緩存處理）、Error Handling（統一錯誤處理）、Debugging（調試信息輸出）、Logging（日志記錄）、Transactions（事務處理）等。

Spring5 系統架構

Spring 總共大約有 20 個模塊，由 1300 多個不同的文件構成。而這些組件被分別整合在核心容器（Core Container）、AOP（Aspect Oriented Programming）和設備支持（Instrmentation）、數據訪問及集成（Data Access/Integeration）、Web、報文發送（Messaging）、Test，6 個模塊集合中。

以下是 Spring 5 的模塊結構圖：

組成 Spring 框架的每個模塊集合或者模塊都可以單獨存在，也可以一個或多個模塊聯合實現。每個模塊的組成和功能如下：

核心容器

由spring-beans、spring-core、spring-context和spring-expression（Spring Expression Language, SpEL） 4 個模塊組成。

spring-core 和 spring-beans 模塊是 Spring 框架的核心模塊，包含了控制反轉（Inversion of Control, IOC）和依賴注入（Dependency Injection, DI）。

BeanFactory 接口是 Spring 框架中的核心接口，它是工廠模式的具體實現。BeanFactory 使用控制反轉對應用程序的配置和依賴性規范與實際的應用程序代碼進行了分離。但BeanFactory 容器實例化后并不會自動實例化 Bean，只有當 Bean 被使用時 BeanFactory 容器才會對該 Bean 進行實例化與依賴關系的裝配。

spring-context 模塊構架于核心模塊之上，他擴展了 BeanFactory，為她添加了 Bean 生命周期控制、框架事件體系以及資源加載透明化等功能。

此外該模塊還提供了許多企業級支持，如郵件訪問、遠程訪問、任務調度等ApplicationContext 是該模塊的核心接口，她的超類是 BeanFactory。

與BeanFactory 不同，ApplicationContext 容器實例化后會自動對所有的單實例 Bean 進行實例化與依賴關系的裝配，使之處于待用狀態。

spring-context-support 模塊是對 Spring IOC 容器的擴展支持，以及 IOC 子容器。

spring-context-indexer 模塊是 Spring 的類管理組件和 Classpath 掃描。

spring-expression 模塊是統一表達式語言（EL）的擴展模塊，可以查詢、管理運行中的對象，同時也方便的可以調用對象方法、操作數組、集合等。

它的語法類似于傳統 EL，但提供了額外的功能，最出色的要數函數調用和簡單字符串的模板函數。這種語言的特性是基于 Spring 產品的需求而設計，他可以非常方便地同 Spring IOC 進行交互。

AOP 和設備支持

由 spring-aop、spring-aspects 和 spring-instrument 3 個模塊組成。

spring-aop 是 Spring 的另一個核心模塊，是 AOP 主要的實現模塊。作為繼 OOP 后，對程序員影響最大的編程思想之一，AOP 極大地開拓了人們對于編程的思路。

在 Spring 中，他是以 JVM 的動態代理技術為基礎，然后設計出了一系列的 AOP 橫切實現，比如前置通知、返回通知、異常通知等，同時，Pointcut 接口來匹配切入點，可以使用現有的切入點來設計橫切面，也可以擴展相關方法根據需求進行切入。

spring-aspects 模塊集成自 AspectJ 框架，主要是為 Spring AOP 提供多種 AOP 實現方法。

spring-instrument 模塊是基于 JAVA SE 中的"java.lang.instrument"進行設計的，應該算是 AOP的一個支援模塊，主要作用是在 JVM 啟用時，生成一個代理類，程序員通過代理類在運行時修改類的字節，從而改變一個類的功能，實現 AOP 的功能。在分類里，我把他分在了 AOP 模塊下，在 Spring 官方文檔里對這個地方也有點含糊不清，這里是純個人觀點。

數據訪問與集成

由 spring-jdbc、spring-tx、spring-orm、spring-jms 和 spring-oxm 5 個模塊組成。

spring-jdbc 模塊是 Spring 提供的 JDBC 抽象框架的主要實現模塊，用于簡化 Spring JDBC 操作 。

主要是提供 JDBC 模板方式、關系數據庫對象化方式、SimpleJdbc 方式、事務管理來簡化 JDBC 編程，主要實現類是 JdbcTemplate、SimpleJdbcTemplate 以及 NamedParameterJdbcTemplate。

spring-tx 模塊是 Spring JDBC 事務控制實現模塊。使用 Spring 框架，它對事務做了很好的封裝，通過它的 AOP 配置，可以靈活的配置在任何一層；但是在很多的需求和應用，直接使用 JDBC 事務控制還是有其優勢的。其實，事務是以業務邏輯為基礎的；一個完整的業務應該對應業務層里的一個方法；

如果業務操作失敗，則整個事務回滾；所以，事務控制是絕對應該放在業務層的；但是，持久層的設計則應該遵循一個很重要的原則：保證操作的原子性，即持久層里的每個方法都應該是不可以分割的。

所以，在使用 Spring JDBC 事務控制時，應該注意其特殊性。

Web 組件

由 spring-web、spring-webmvc、spring-websocket 和 spring-webflux 4 個模塊組成。

spring-web 模塊為 Spring 提供了最基礎 Web 支持，主要建立于核心容器之上，通過 Servlet 或者 Listeners 來初始化 IOC 容器，也包含一些與 Web 相關的支持。

spring-webmvc 模塊眾所周知是一個的 Web-Servlet 模塊，實現了 Spring MVC （model-view-Controller）的 Web 應用。

spring-websocket 模塊主要是與 Web 前端的全雙工通訊的協議。

spring-webflux 是一個新的非堵塞函數式 Reactive Web 框架，可以用來建立異步的，非阻塞，事件驅動的服務，并且擴展性非常好。

通信報文

即 spring-messaging 模塊，是從 Spring4 開始新加入的一個模塊，主要職責是為 Spring 框架集成一些基礎的報文傳送應用。

集成測試

即 spring-test 模塊，主要為測試提供支持的，畢竟在不需要發布（程序）到你的應用服務器或者連接到其他企業設施的情況下能夠執行一些集成測試或者其他測試對于任何企業都是非常重要的。

集成兼容

即 spring-framework-bom 模塊，Bill of Materials.解決 Spring 的不同模塊依賴版本不同問題。

各模塊之間的依賴關系

我對 Spring5 各模塊做了一次系統的總結，描述模塊之間的依賴關系，希望能對小伙伴們有所幫助。

接下來的《深入Spring5源碼系列》中，我們將深入了解 Spring 的核心模塊功能。

基本學習順序為：從 spring-core 入手， 其次是 spring-beans 和 spring-aop，隨后是 spring-context，再其次是 spring-tx 和 spring-orm， 最后是 spring-web 和其他部分。

Spring 版本命名規則

版本號的格式為 X.Y.Z(又稱 Major.Minor.Patch)：

X 表示主版本號， 當 API 的兼容性變化時， X 需遞增。

Y 表示次版本號， 當增加功能時(不影響 API 的兼容性)， Y 需遞增。

Z 表示修訂號， 當做 Bug 修復時(不影響 API 的兼容性)， Z 需遞增。

詳細的規則如下：

X, Y, Z 必須為非負整數，且不得包含前導零，必須按數值遞增，如 1.9.0 -> 1.10.0 -> 1.11.0。

0.Y.Z 的版本號表明軟件處于初始開發階段， 意味著 API 可能不穩定； 1.0.0 表明版本已有穩定的 API。

當 API 的兼容性變化時， X 必須遞增， Y 和 Z 同時設置為 0；

當新增功能(不影響 API 的兼容性)或者 API 被標記為 Deprecated 時， Y 必須遞增， 同時 Z 設置為 0； 當進行 bug fix 時， Z 必須遞增。

先行版本號(Pre-release)意味該版本不穩定， 可能存在兼容性問題， 其格式為： X.Y.Z.[a-c][正整數]， 如 1.0.0.a1， 1.0.0.b99， 1.0.0.c1000。

開發版本號常用于 CI-CD， 格式為 X.Y.Z.dev[正整數]， 如 1.0.1.dev4。

版本號的排序規則為依次比較主版本號、 次版本號和修訂號的數值， 如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0；

對于先行版本號和開發版本號， 有： 1.0.0.a100 < 1.0.0， 2.1.0.dev3 < 2.1.0； 當存在字母時， 以 ASCII 的排序來比較， 如 1.0.0.a1 < 1.0.0.b1。

常見的版本修飾詞

Snapshot: 版本代表不穩定、尚處于開發中的版本

Alpha: 內部版本

Beta: 測試版

Demo: 演示版

Enhance: 增強版

Free: 自由版

Full Version: 完整版，即正式版

LTS: 長期維護版本

Release: 發行版

RC: 即將作為正式版發布

Standard: 標準版

Ultimate: 旗艦版

Upgrade: 升級版

Spring 版本修飾詞

Release：穩定版本

GA：廣泛可用的穩定版(General Availability)

M：里程碑版本(Milestone）具有一些全新的功能或是具有里程碑意義的版本

RC：即將作為正式版發布 (Release Candidate)

到此，關于“分析Spring框架的前世今生”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！