來源:MageekChiusegmentfault.com/a/1190000011334873複製代碼
Spring 是一個開源框架,是爲了解決企業應用程序開發複雜性而建立的(替代更加劇量級的企業級Java技術, 尤爲是EJB),它完成了大量開發中的通用步驟,留給開發者的僅僅是與特定應用相關的部分,從而大大提升了企業應用的開發效率。前端
Spring 框架是一個分層架構,由 7 個定義良好的模塊組成。Spring 模塊構建在覈心容器之上,核心容器定義了建立、配置和管理 bean 的方式以下圖:web
組成 Spring 框架的每一個模塊均可以單獨存在,或者與其餘一個或多個模塊聯合實現。每一個模塊的功能以下:spring
Spring 核心容器:核心容器提供 Spring 框架的基本功能,管理着Spring應用中bean的建立、配置和管理。核心容器的主要組件是 BeanFactory,它是工廠模式的實現。BeanFactory 使用DI將應用程序的配置和依賴性規範與實際的應用程序代碼分開。數據庫
Spring 上下文:Spring 上下文是一個配置文件,向 Spring 框架提供上下文信息。提供了一種框架式的對象訪問方法,有些象JNDI註冊器。Context封裝包的特性得自於Beans封裝包,並添加了對國際化(I18N)的支持(例如資源綁定),事件傳播,資源裝載的方式和Context的透明建立,好比說經過Servlet容器。Spring 上下文和Bean工廠都是 bean 容器 的實現。編程
Spring AOP:經過配置管理特性,Spring AOP 模塊直接將面向方面的編程功能集成到了 Spring 框架中。因此,能夠很容易地使 Spring 框架管理的任何對象支持 AOP。Spring AOP 模塊爲基於 Spring 的應用程序中的對象提供了事務管理服務。segmentfault
Spring DAO:JDBC DAO 抽象層提供了有意義的異常層次結構,可用該結構來管理異常處理和不一樣數據庫供應商拋出的錯誤消息。異常層次結構簡化了錯誤處理,而且極大地下降了須要編寫的異常代碼數量(例如打開和關閉鏈接)。Spring DAO 的面向 JDBC 的異常聽從通用的 DAO 異常層次結構。後端
Spring ORM:Spring 框架插入了若干個 ORM 框架,從而提供了 ORM 的對象關係工具,其中包括 JDO、Hibernate 和 iBatis SQL Map。全部這些都聽從 Spring 的通用事務和 DAO 異常層次結構。瀏覽器
Spring Web 模塊:Web 上下文模塊創建在應用程序上下文模塊之上,爲基於 Web 的應用程序提供了上下文。緩存
Spring MVC 框架:MVC 框架是一個全功能的構建 Web 應用程序的 MVC 實現。經過策略接口,MVC 框架變成爲高度可配置的,MVC 容納了大量視圖技術,其中包括 JSP、Velocity、Tiles、iText 和 POI。安全
控制反轉模式(IOC)也稱做依賴性介入(DI)的基本概念是:不建立對象,可是描述建立它們的方式。在代碼中不直接與對象和服務鏈接,但在配置文件中描述哪個組件須要哪一項服務。容器 (在 Spring 框架中是 IOC 容器) 負責將這些聯繫在一塊兒。在典型的 IOC 場景中,容器建立了全部對象,並設置必要的屬性將它們鏈接在一塊兒,決定什麼時間調用方法。
Rod Johnson是第一個高度重視以配置文件來管理Java實例的協做關係的人,他給這種方式起了一個名字:控制反轉(Inverse of Control,IoC)。後來Martine Fowler爲這種方式起了另外一個名稱:依賴注入(Dependency Injection),所以無論是依賴注入,仍是控制反轉,其含義徹底相同。
當某個Java對象(調用者)須要調用另外一個Java對象(被依賴對象)的方法時,在傳統模式下一般有兩種作法
原始作法: 調用者主動建立被依賴對象,而後再調用被依賴對象的方法
簡單工廠模式: 調用者先找到被依賴對象的工廠,而後主動經過工廠去獲取被依賴對象,最後再調用被依賴對象的方法.
注意上面的主動二字,這必然會致使調用者與被依賴對象實現類的硬編碼耦合,很是不利於項目升級的維護。使用Spring框架以後,調用者無需主動獲取被依賴對象,調用者只要被動接受Spring容器爲調用者的成員變量賦值便可,因而可知,使用Spring後,調用者獲取被依賴對象的方式由原來的主動獲取,變成了被動接受——因此Rod Johnson稱之爲控制反轉。
另外從Spring容器的角度來看,Spring容器負責將被依賴對象賦值給調用者的成員變量——至關於爲調用者注入它依賴的實例,所以Martine Fowler稱之爲依賴注入。
AOP(Aspect Orient Programming)也就是面向切面編程,做爲面向對象編程的一種補充,已經成爲一種比較成熟的編程方式。其實AOP問世的時間並不太長,AOP和OOP互爲補充,面向切面編程將程序運行過程分解成各個切面。
AOP專門用於處理系統中分佈於各個模塊(不一樣方法)中的交叉關注點的問題,在JavaEE應用中,經常經過AOP來處理一些具備橫切性質的系統級服務,如日誌、事務管理、安全檢查、緩存、對象池管理等,AOP已經成爲一種很是經常使用的解決方案。
在典型的面向對象開發方式中,可能要將日誌記錄語句放在全部方法和 Java 類中才能實現日誌功能。在 AOP 方式中,能夠反過來將日誌服務模塊化,並以聲明的方式將它們應用到須要日誌的組件上,這樣 Java 類就不須要知道日誌服務的存在,也不須要考慮相關的代碼。因此,用 Spring AOP 編寫的應用程序代碼是鬆散耦合的。
低侵入式設計,代碼的污染極低:不少框架經過強迫應用繼承它們的類或實現它們的接口而致使應用與框架綁死,而Spring是經過spring特有的註解和通用的pojo結合。Spring的非侵入編程模型意味着這個類在Spring應用和非Spring應用中均可以發揮一樣的做用。Spring的組件就是普通的Java Bean,這也使得單元測試能夠再也不依賴容器,編寫更加容易。
使用模板消除樣板式代碼: 如Spring的JdbcTemplate使得執行數據庫操做時避免傳統的JDBC樣板代碼(建立一個數據庫鏈接,而後再建立一個語句對象,最後你才能進行查詢,關閉數據庫鏈接、語句和結果集)成爲了可能。
獨立於各類應用服務器:基於Spring框架的應用,能夠真正實現Write Once,Run Anywhere的承諾。
Spring的IoC容器下降了業務對象替換的複雜性,下降了了組件之間的耦合性:對象的依賴關係將由系統中負責協調各對象的第三方組件在建立對象的時候進行設定,因此對象無需自行建立或管理它們的依賴關係,依賴關係將被自動注入到須要它們的對象當中去。並且若是一個對象只經過接口而不是具體實現或初始化過程來代表依賴關係,那麼這種依賴就可以在對象自己絕不知情的狀況下,用不一樣的具體實現進行替換。
Spring的AOP支持容許將一些通用任務如安全、事務、日誌等進行集中式管理: 將核心業務和系統服務分離,保持POJO的簡單性和內聚性,從而使他們各自達到更好的複用。
Spring的ORM和DAO提供了與第三方持久層框架的良好整合,並簡化了底層的數據庫訪問:
Spring的高度開放性,並不強制應用徹底依賴於Spring,開發者可自由選用Spring框架的部分或所有:當Spring不能知足需求時, 徹底能夠考慮其餘選擇。事實上, Spring甚至提供了與其餘第三方框架和類庫的集成點, 這樣你就不須要本身編寫這樣的代碼了。好比之前經常使用的SSH框架,如今經常使用的SSM框架
Spring包含許多項目,下面挑一些最經常使用的出來總結一下。
Spring MVC是Spring中的基礎 Web 框架,基於模型-視圖-控制器(Model-View-Controller,MVC)模式實現,它可以幫你構建像Spring框架那樣靈活和鬆耦合的Web應用程序。
在該框架下,一次web請求大體能夠分爲以下圖幾個步驟,這些劃分分離了職責,使得代碼靈活、維護性更好。
爲了使用該框架,咱們首先要配置DispatchServlet,也就是前端控制器,而後啓用Spring MVC,並編寫控制器,視圖,模型等等。
其中,DispatcherServlet是Spring MVC的核心,DispatcherServlet啓動的時候,它會建立Spring應用上下文,並加載配置文件或配置類中所聲明的bean或者自動掃描的bean,可是在Spring Web應用中,一般還會有另一個應用上下文,這個應用上下文是由ContextLoaderListener建立的。DispatcherServlet加載包含Web組件的bean,如控制器、視圖解析器以及處理器映射,而ContextLoaderListener要加載應用中的其餘bean,一般是驅動應用後端的中間層和數據層組件。
Spring MVC是一個強大靈活的Web框架。藉助於註解,Spring MVC提供了近似於POJO的開發模式,這使得開發處理請求的控制器變得很是簡單,同時也易於測試。並且Spring MVC還支持多種視圖解析器如JSP,Tiles,Thymeleaf,使得前端界面的功能更強大,編寫更容易。
Spring Web Flow是Spring MVC的一個擴展, 它爲基於流程的會話式Web應用(購物車或者嚮導功能)提供了支持。簡言之,它是一個流程框架,可以引導用戶執行一系列嚮導步驟。
在Spring Web Flow中,流程是由三個主要元素定義的:狀態、轉移和流程數據。狀態( State)是流程中事件發生的地點,在流程中經過轉移的方式從一個狀態到另外一個狀態,流程的當前情況稱爲流程數據。
狀態分爲:
行爲( Action) 行爲狀態是流程邏輯發生的地方
決策( Decision) 決策狀態將流程分紅兩個方向, 它會基於流程數據的評估結果肯定流程方向
結束( End) 結束狀態是流程的最後一站。一旦進入End狀態, 流程就會終止
子流程( Subflow) 子流程狀態會在當前正在運行的流程上下文中啓動一個新的流程
視圖( View) 視圖狀態會暫停流程並邀請用戶參與流程
轉移鏈接了流程中的狀態。流程中除結束狀態以外的每一個狀態,至少都須要一個轉移,這樣就可以知道一旦這個狀態完成時流程要去向哪裏。狀態能夠有多個轉移,分別對應於當前狀態結束時能夠執行的不一樣的路徑。
當流程從一個狀態進行到另外一個狀態時,它會帶走一些流程數據。有時候,這些數據只須要很短的時間(可能只要展示頁面給用戶)。有時候,這些數據會在整個流程中傳遞並在流程結束的時候使用。
Spring Web Flow 能夠構建會話式應用程序的Web框架,這是好的,可是感受其配置只能用xml這個設計不太合理,尤爲是當bean不少或者流程節點不少時都很差維護。
安全對於許多應用都是一個很是關鍵的切面,由於安全性是超越應用程序功能的一個關注點,應用系統的絕大部份內容都不該該參與到與本身相關的安全性處理中。儘管咱們能夠直接在應用程序中編寫安全性功能相關的代碼,但更好的方式仍是將安全性相關的關注點與應用程序自己的關注點進行分離,做爲系統的一個切面。Spring Security就是經過AOP和Filter來爲應用程序實現安全性的。
使用Servlet規範中的Filter保護Web請求並限制URL級別的訪問。Spring Security還可以使用Spring AOP保護方法調用——藉助於對象代理和使用通知,可以確保只有具有適當權限的用戶才能訪問安全保護的方法。
Spring Security很是靈活,可以基於各類數據存儲來認證用戶。它內置了多種常見的用戶存儲場景,如內存、關係型數據庫以及LDAP。但咱們也能夠編寫並插入自定義的用戶存儲實現。
當爲瀏覽器渲染HTML內容時,你可能但願視圖中可以反映安全限制和相關的信息。一個簡單的樣例就是渲染用戶的基本信息( 好比顯示「您已經以……身份登陸」)。或者你想根據用戶被授予了什麼權限,有條件地渲染特定的視圖元素。Spring Security自己提供了一個JSP標籤庫,而Thymeleaf經過特定的方言實現了與Spring Security的集成。藉助於這些,能夠很容易的實現對視圖的保護。
Spring Data 是爲了簡化構建基於 Spring 框架應用的數據訪問技術,包括關係數據庫、NoSQL、Map-Reduce 框架、雲數據服務等等,旨在提供一種通用、統一的編碼模式(可是並非代碼徹底同樣),使得在Spring中使用任何數據庫都變得很是容易。
Spring Data做爲Spring Source的其中一個父項目,旨在統一和簡化對各種型持久化存儲,而不拘泥因而關係型數據庫仍是NoSQL數據存儲。
目前的Spring Data 包含以下的模塊(或者說子項目):
Spring Data Commons
Spring Data JPA
Spring Data KeyValue
Spring Data LDAP
Spring Data MongoDB
Spring Data Gemfire
Spring Data REST
Spring Data Redis
Spring Data for Apache Cassandra
Spring Data for Apache Solr
Spring Data Couchbase (community module)
Spring Data Elasticsearch (community module)
Spring Data Neo4j (community module)
不管是哪一種持久化存儲,數據訪問對象(DAO,即Data Access Objects)一般都會提供對單一域對象的CRUD(建立、讀取、更新、刪除)操做、查詢方法、排序和分頁方法等。Spring Data則提供了基於這些層面的統一接口(CrudRepository,PagingAndSortingRepository)以及對持久化存儲的實現。
你可能接觸過某一種Spring模型對象——好比JdbcTemplate——來編寫訪問對象的實現。可是在基於Spring Data的數據訪問對象,咱們只需定義和編寫一些查詢方法的接口(基於不一樣的持續化存儲, 定義有可能稍有不一樣),Spring Data會在運行時間生成正確的實現。
全部Spring Data的子項目都支持:
模板:處理資源分配和異常處理
對象、數據存儲映射:如ORM
對數據訪問對象的支持:幫助咱們編寫一些模板式語句如分頁排序
然而一些Spring Data子項目,如Spring Data Redis和Spring Data Riak都只是提供模板,這是因爲其相應的數據存儲都只支持非結構化的數據,而不適用於對象的映射和查詢。
Spring誕生時是Java企業版(Java Enterprise Edition, JEE,也稱J2EE)的輕量級代替品。無需開發重量級的Enterprise JavaBean(EJB),Spring爲企業級Java開發提供了一種相對簡單的方法。
雖然Spring的組件代碼是輕量級的,但它的配置倒是重量級的。一開始,Spring用XML配置,並且是不少的XML配置,即便後來有基於註解的改善,咱們依然難逃大量配置的魔爪。而Spring Boot讓這一切成爲了過去,若是說Spring的目的是簡化程序的開發,那麼Spring Boot就是爲了簡化Spring自己的開發。
Spring Boot依賴於自動配置技術將Spring應用中樣板式的配置移除掉,這樣就能讓咱們免受於一大堆的配置之苦,更加專一於業務功能。Spring Boot同時還提供了多個Starter項目,拿來便可用,極大地簡化了編程任務。
它提供了四個主要的特性,可以改變開發Spring應用程序的方式:
Spring Boot Starter:它將經常使用的依賴分組進行了整合,將其合併到一個依賴中,這樣就能夠一次性添加到項目的Maven或Gradle構建中,這裏能夠找到目前全部的starter項目。
自動配置:Spring Boot的自動配置特性利用了Spring 4對條件化配置的支持,合理地推測應用所需的bean並自動化配置它們,減小了你本身須要配置的數量。
命令行接口(Command-line interface,CLI):Spring Boot的CLI發揮了Groovy編程語言的優點,並結合自動配置進一步簡化Spring應用的開發。
Actuator:它爲Spring Boot應用添加了必定的管理特性。
在進入主題以前,首先來看看微服務,簡單說來就是將本來單個獨立的大系統拆分爲分佈式的多個小型的服務,這些小型服務各自獨立運行,他們經過HTTP和RestFul API進行通訊。
一個微服務通常完成某個特定的功能,好比下單管理、客戶管理等等。每個微服務都是微型六角形應用,都有本身的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI,運行時,每個實例多是一個雲VM或者是Docker容器。
微服務具備分佈式系統的特性,如服務發現,負載均衡,故障轉移,多版本,灰度升級,服務降級,分佈式跟蹤。
Spring Cloud是一套完整的分佈式系統解決方案,它的子項目涵蓋了全部實現分佈式系統所須要的基礎軟件設施(包括配置管理、服務治理、智能路由、全局鎖等等)。基於Spring Boot,Spring Boot作較少的配置,即可成爲Spring Cloud中的一個微服務,使用Spring Cloud的開發者能夠快速的啓動服務或構建應用、同時可以快速和雲平臺資源進行對接,使得開發部署極其簡單。
Spring Cloud專一於提供良好的開箱即用經驗的典型用例和可擴展性機制覆蓋:
分佈式/版本化配置:Spring Cloud Config
服務註冊和發現:Netflix Eureka 或者 Spring Cloud Eureka(對前者的二次封裝)
路由:Spring Cloud Zuul 基於 Netflix Zuul
service - to - service調用:Spring Cloud Feign
負載均衡:Spring Cloud Ribbon 基於 Netflix Ribbon 實現
斷路器:Spring Cloud Hystrix
分佈式消息傳遞:Spring Cloud Bus
總結了一大堆,感受Spring Boot是趨勢,畢竟效率是王道。而後就是Spring Data的各個項目,由於現在的數據源是愈加的豐富。最後,近幾年微服務的概念挺火的,因此Spring Cloud也要多多瞭解。