架構雜談《一》

架構雜談《一》

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

　　典型的單體架構分為三個層級，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的工作原理如下：

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

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

　　　　　　3、服務調用者通過WSDL語言遠程調用服務提供者提供的服務

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

• ESB

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

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

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

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

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

　　企業服務匯流排是 ESB 的核心要素，所有服務都可以在匯流排上插拔，並通過匯流排的流程編排和協議轉接能力來組合實現業務處理能力。

  說明：

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

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