《分佈式服務架構：原理、設計於實戰》總結

　　第一章：

　　理論基礎：

　　互聯網企業對傳統技術進行發展和演化，造成一套具備互聯網特點的互聯網技術，互聯網技術以拆分爲原則來知足服務於海量 用戶的需求，從架構上來說，分佈式、服務化( SOA )、 微服務獲得了深刻發展，以拆分和服務化爲基礎，將海量用戶產生的大規模的訪問流量進行分解，採用分而治之的方法，達成用戶須要的功能指標，並同時知足用戶對高可用性、高性能、 可伸縮、可擴展和安全性的非功能質量的要求。

　　這斷話摘自書中的一段內容，從這段話中咱們能夠思考，分佈式理論中使用了兩個主流的技術，以SOA服務化爲基礎，採用分而治之的思想進行業務處理；

　　何爲分而治之：將一個大任務劃分爲幾個子任務，並行執行後，將結果合併的思想；

　　在大數據處理中一樣採用分而治之的原理進行處理，好比下面的案例：在對5萬張撲克牌進行處理篩選漏掉的一張時，就能夠將5萬張牌進行拆分爲5個，而後這5個並行計算各個牌的個數，計算完成後進行各個花色的統計，最後進行結果的篩選；

     

 

從傳統單體架構到服務化架構 ：

原始的EJB架構：

 

 缺點：

儘管大多數公司會 使用規範來約束不一樣業務邏輯的隔離性來解禍，可是長此以往，隨着複雜業務邏輯的選代增長 及開發人員的不斷流動，新手工程師爲了節省時間

和趕進度，非法使用了其餘組件的服務，業務組件之間、 組件之間、數據存取之間的稿合性必然增長，最後致使組件與組件之間難以劃 清界限，徹底禍合在一塊兒，

未來的新功能迭代、增長和維護將難上加難。 

 

SSH框架：

SSM框架的優勢：

對Spring進行優勢簡述：

　　開源框架 Spring 的發佈，更加改變了 JEE 一開始制定的戰略目標。 Spring框架做爲 邏輯層實現的核心容器，使用起來簡單、方便又靈活，幾乎大部分開發者徹底倒向了 Spring開源派。 Spring 框架有兩個核心思想: IOC 和 AOP，以下所述 。

　　Spring IOC 指的是控制翻轉，將傳統 EJB 基於容器的開發改形成普通的 Java 組件的開發， 且在運行時由 Spring容器統一管理和串聯，服務於不一樣的流程，在開發過程當中對 Spring容器沒有強依賴，便於開發、測試、驗證和遷移。使用 EJB 實現一個服務化組件 Bean 時，須要依賴於多個容器接口 ，並須要根據容器的規則進行復雜的 XML 配置，測試須要依賴於應用服務器的環境，有諸多不便;使用 Spring框架則否則，開發業務邏輯時每一個業務邏輯的服務組件都是獨立的， 而不依賴於 Spring框架，藉助 Spring容器對單元測試的支持，經過對下層依賴服務進行 Mock, 每一個業務組件均可以在必定範圍內進行單元化測試，而不須要啓動重型的容器來測試。

　　Spring 對 AOP 的支持是 Spring 框架成功的另一大核心要素。 AOP 表明面向切面的編程， 一般適用於使用面向對象方法沒法抽象的業務邏輯，例如:日誌、安全、事務、應用程序性能管 理(APM) 等，使用它們的場景並不能用面向對象的方法來表達和實現，而須要使用切面來表達， 由於它們可能穿插在程序的任何一個角落裏。在 Java 的世界裏， AOP 的實現方式有以下 三種 。

· cglib庫實現，對 Java字節碼進行從新編譯，將切面插入宇節碼的某些點和麪上 。

· 定製類加載器，在類加載時對字節碼進行補充，在字節碼中插入切面，增長了除業務邏 輯外的功能， NM 自身提供的 Java Agent 機制就是在加載類的宇節碼時，經過增長切 面來實現 AOP 的。

•NM 自己提供了動態代理組件，能夠經過它實現任意對象的代理模式，在代理的過程當中可 以插入切面的邏輯。可使用 Java提供的 APIProxy.newProxylnstanceO和 InvocationHandler 來實現。

 AspectJ是實現 AOP 的專業框架和平臺，經過 AspectJ能夠實現任意方式的字節碼切 面， Spring框架徹底支持 AspectJ。

　　到如今爲止， SSH 開源標配框架中有了四交互層的 Stru也框架和業務邏輯實現層的 Spring 框架，因爲面向對象領域的模型與關係型數據庫存在着自然的屏障，因此對象模型和關係模型之 間須要一個紐帶框架，也就是咱們常說的 ORM 框架，它可以將對象轉化成關係，也能夠將關係 轉化成對象，因而， Hibernate框架出現了。 Hibernate經過配置對象與關係表之間的映射關係，來 指導框架對對象進行持久化和查詢，而且可讓應用層開發者像執行 SQL 同樣執行對象查找 。 這 大大減小了應用層開發人員寫 SQL 的時間 。然而，隨着時間的發展，高度抽象的 ORM 框架被證 明性能有瓶頸，所以，後來你們更傾向於使用更加靈活的 MyBatis 來實現 ORM 層 。 

缺點：

　　SSM框架仍是沒有擺脫傳統的單JVM的劣勢，遠遠知足不了高併發的場景。

　　服務的特色仍然是單體化，服務的粒度抽象爲模塊化組件，全部組件精合在一個開發項目中，而且配置和運行在一個JVM中 。 若是某個模塊化組件須要升 級上線，則會致使其餘沒有變動的模塊化組件一樣上線，在嚴重狀況下，對某個模塊化組件的 變動，因爲種種緣由，會致使其餘模塊化組件出現問題。 

　　在互聯網異軍突起的環境下，傳統 JEE和 SSH沒法知足對海量用戶發起的高井發請 求進行處理的需求，沒法突破稿合在 一塊兒的模塊化組件的性能瓶頸，單一進程己經沒法滿 足需 求，而且水平擴展的能力也是頗有限的。 

面向服務架構：