架構雜談《一》

架構雜談《一》

 

從傳統單體架構到服務化架構的發展歷程

　　典型的單體架構分爲三個層級，Web層、業務邏輯層和數據存儲層，每一個層的指責分別以下：

• Web 層：負責與用戶交互或者對外提供接口
• 業務邏輯層：爲了實現業務邏輯而設計的流程處理模塊
• 數據存儲層：將業務邏輯層處理的結果持久化
        

　　將不一樣的模塊化組件聚合後運行在通用的應用服務器上。

　　單體架構已經對企業級應用的總體架構進行了邏輯分層，包括了上面提到的Web層、業務邏輯層和數據存儲層，不一樣的層級有本身的職責，並從功能類型上劃分層級，每一個層級的職責單一。

　　在這一時期，因爲架構上把總體的單體系統分紅具備不一樣指責的層級，對應的項目管理也傾向於把大的團隊分紅不一樣的職能團隊（UI團隊、後臺業務邏輯處理團隊（程序員）和DBA團隊），每一個團隊只對本身的職責負責。架構已經在必定程度上進行了邏輯的劃分。可是，每一個層次的多個業務邏輯的實現會被放在同一應用項目中，並運行在同一個.Net CLR或者JVM中，儘管會使用規範來約束不一樣業務邏輯的隔離性來解耦，但隨着複雜業務邏輯的迭代增長及開發人員的不斷流動或者爲了節省時間和趕進度，非法使用了其餘組件的服務，業務組件之間、UI組件之間、數據存儲之間的耦合性必然會增長，最後致使組件與組件之間難以劃清界限，徹底耦合在一塊兒，未來新的功能迭代、增長和維護將會難上加難。

　　　在（JEE、ASP.Net WebForm）等開始流行但沒有奠基地位的時候，開源軟件Struts、Spring和Hibernate開始浮出水面了，很快成爲了行業內企業開發的開源框架標配（SSH）（.Net 的 Asp.Net MVC）,Web MVC 框架在用戶交互的UI層進一步劃分了前端的職責，將用戶交互層劃分爲了視圖（View）、模型（Model）和控制器（Controller）三大塊（簡稱MVC架構），結構圖以下：

　　

　　在這個時代、Struts MVC和Asp.net MVC 模板幾乎服務於大多數企業服務的Web項目。後來，開源框架Spring的發佈，更加改變了一開始指定的戰略目標。Spring有兩大核心思想：IOC和AOP。（後單體架構）

　　從單體架構後後單體架構，服務的特色仍然是單體化，服務的粒度抽象爲模板化組件，全部的組件耦合在一個項目中。而且配置和運行在一個.Net CLR(JVM)進程中。若是某個模塊化須要升級上線，則會致使其餘沒有變動的模塊化組件一樣上線，在嚴重狀況下，對某個模塊化組件的變動，因爲各類緣由會致使其餘模塊化組件出現問題。另外在互聯網的突飛發展下，傳統的單體架構和後單體架構沒法知足對大量用戶發起的高併發請求進行處理的需求，沒法破解耦合在一塊兒的模塊化組件的性能瓶頸，單一進程已經沒法知足需求，而且水平擴展的能力也是有限的。

　　爲了解決上述問題，SOA就應運而生了。SOA表明面向服務的架構（服務化），SOA將應用程序的模塊化組件經過定義明確的接口和約定（契約）聯繫在一塊兒，接口採用中立的方式進行定義，獨立於某種語言、硬件和OS（操做系統），一般經過網絡通訊來完成，但並侷限於某種網絡協議（能夠是TCP/IP，也能夠是HTTP，也能夠是消息隊列，甚至能夠是約定的某種數據庫存儲形式），這使得各類各樣系統中的模塊化組件能夠以一種統一和通用的方式進行交互。

　　經過對比各個時代架構下的模塊化組件，能夠發現SOA將模塊化組件從單一進程中進一步拆分，造成了獨立的對外提供服務的網絡化組件，每一個網絡化組件經過某種協議對外提供服務，這種架構有如下特色：

• SOA定義了良好的對外接口，經過網絡協議對外提供的服務，服務之間表現爲鬆耦合性（鬆耦合性具備靈活的特色，能夠對服務流程進行靈活組裝和編排，而不須要對服務本省作任何改變）
• SOA可讓企業最大化地使用內部和外部提供的公共服務
• SOA的數據通訊格式一般爲XML（冗餘的標記會給性能帶來極大的影響，後來被JSON取代）
• 組成整個業務流程的每一個服務的內部結構和實如今發生改變時，不影響整個流程對外提供的服務（只要對外的接口不變，則改變服務內部的實現機制對外部來講是透明的）
• SOA定義了標準的對外接口，可讓底層通用服務進行下沉，供多個上層的使用方同時使用，增長了服務可重用性

　　要完全理解SOA服務化發展狀況，必需要了解SOA的兩個主流實現方式：Web Service 和 ESB

• Web Service

　　　　Web Service 技術是SOA服務化的一種實現方式，它使得運行在不一樣的機器及OS（操做系統）上的服務的互通發現和調用成爲可能，而且能夠經過某種協議交換數據

　　

　　　　經過上圖能夠看出，每一個服務之間是平等的，而且互相解耦的，經過WSDL定義的服務發現接口進行訪問，並經過SOAP協議進行通訊。SOAP協議一般是一種在HTTP或者HTTPS上傳輸XML數據來實現的協議，可是每一個服務都要依賴中心Web Service來發現現存的服務。

　　 　　Web Service的工做原理以下：

　　　　　　一、服務提供者經過UDDI協議將服務註冊到中心Web Service目錄中

　　　　　　二、服務調用者經過UDDI協議從中心 Web Service目錄中查詢服務，並得到服務的WSDL服務描述文件

　　　　　　三、服務調用者經過WSDL語言遠程調用服務提供者提供的服務

　　　　經過這個過程，要改造一個新的業務流程，能夠從 Web Service 目 錄中發現現有的服務，並最大限度地重用現有的服務，通過服務流程的編排來服務新的業務 。 

• ESB

　　 ESB 是企業服務總線的簡稱，是用於設計和實現網絡化服務交互和通訊的軟件模型，是SOA的另外一種實現方式，主要用於企業信息化系統的集成服務場景中。
　　 在SOA服務化發展以前，企業對信息化系統進行了初步建設，在現有的服務系統上增長新的功能或者疊加新的服務化系統，這須要對這些現有的信息化系統和新增的系統進行組合（若是在現有的系統上使用新的開發、操做系統等等是不現實的，有可能現有的系統是採用異構技術棧實現的）。SOA的鬆耦合特色正好應用於這一場景。使得企業能夠按照服務化的方式來添加新的服務或升級現有的服務，來解決新業務對流程編排的須要，甚至能夠經過不一樣的渠道來得到外部服務並與企業現有的應用進行組合。來提供新的業務場景所須要的信息化流程。

　　ESB 也使用於事件處理、數據轉換和映射、消息和事件異步隊列順序處理、安全和異常處理、協議轉換和保證通訊服務的質量等場景。

　　

　　　從上圖能夠看出ESB沒有中心化的服務節點，每一個服務提供者都是經過總線的模式接入系統，總線根據流程的編排負責將服務的輸出進行轉換併發送給流程要求的下一個服務
進行處理。

　　總線根據流程的編排負責將服務的輸出進行轉換併發送給流程要求的下一個服務進行處理。 以下所述

• 監控和控制服務之間的消息路由
• 控制可插拔的服務化的功能和版本
• 解析服務之間交互和通訊的內容和格式
• 經過組合服務、資源和消息處理器來統一編排業務須要的信息處理流程
• 使用冗餘來提升服務的備份能力
  

　　企業服務總線是 ESB 的核心要素，全部服務均可以在總線上插拔，並經過總線的流程編排和協議轉接能力來組合實現業務處理能力。

  說明：

　　一、文中的圖都來自於百度圖片

　　二、參考書籍：《分佈式服務架構：原理、設計與實戰》