程序員必知的7種軟件架構模式

 
 
    
 
     
 
      
 
       
 
        
 
         
 
          
 
           
做者：Trung Anh Dang
 
           
策劃：萬佳
 
          
 
         
 
        
 
       
 
      
 
     
 
    

架構模式是對給定上下文的軟件架構中常見問題的一種通用的可複用的解決方案。

一種模式就是特定上下文的問題的一種解決方案。

然而，不少開發者至今還對各類軟件架構模式之間的差異搞不清，甚至對其所知甚少。

大致上，主要有下面這7種架構模式：

1. 分層架構

2. 多層架構

3. 管道 - 過濾器架構

4. 客戶端 - 服務器架構

5. 模型 - 視圖 - 控制器架構

6. 事件驅動架構

7. 微服務架構

1

分層架構模式

最多見的架構模式就是分層架構或者稱爲 n 層架構。

大部分軟件架構師、設計師和開發者都對這個架構模式很是熟悉。儘管對於層的數量和類型沒有具體限制，但大部分分層架構主要由四層組成：展示層、業務層、持久層和數據庫層，以下圖所示。

一個很流行的 n 層架構示例

 1 上下文 

全部複雜的系統都會經歷獨立地發展和衍化系統各個部分的須要。出於這個緣由，系統開發者須要對關注點進行清晰且條理分明的分離，以便系統的各個模塊能夠獨立地開發和維護。

 2 問題 

軟件須要以這樣一種方式分割：各個模塊能夠獨自開發和衍化，各自部分之間的交互很是少，支持可移植性、可修改性和複用性。

 3 方案 

爲了實現關注點分離，分層模式將軟件分割成各個單元（稱爲「層」）。每一層都是一組模塊，提供了一組高內聚的服務。其使用必須是單向的。層將一組軟件做爲一個完整的分區，每一個分區暴露一個公開接口。

• 第一個概念是，每一層都有特定的角色和職責。例如，展示層負責處理全部的用戶界面。分層架構的這種關注點分離，讓構建高效的角色和職責很是簡單。
• 第二個概念是，分層架構模式是一個技術性的分區架構，而非一個領域性的分區架構。它們是由組件組成的，而不是領域。
• 最後一個概念是，分層架構中的每一層都被標記爲封閉或者開放。封閉層意味着請求從一層移到另外一層，它必須經過它正下面的這一層才能達到下面這一層的再下一層。請求不能跳過任何層。

封閉層和請求訪問

 4 弱點 

分層會致使性能降低。這種模式不適合高性能應用程序，由於通過架構中的多層來實現一個業務請求的效率是不高的。

分層還會增長系統的前期成本和複雜性。

 5 用途 

咱們應該將這種方式應用於小型簡單的應用程序或網站。對於預算和時間很是緊張的場景，這是一個不錯的選擇。

2

多層模式

 1 方案 

一個多層模式示例：消費者網站 J2EE

許多系統的執行結構被組織成一系列邏輯組件分組。每一個分組被稱爲一個層。

 1 上下文 

在一個分佈式部署中，一般須要將系統的基礎設施分到不一樣的子集中。

 2 問題 

咱們如何將系統分割到多個計算上獨立的執行結構：由一些通訊媒介鏈接的軟件和硬件組？

 3 弱點 

大量前期成本和複雜性。

 4 用途 

用在分佈式系統中。

3

管道-過濾器架構

軟件架構中反覆出現的一種模式是管道 - 過濾器（pipe-filter）模式。

管道過濾器模式

 1 上下文 

許多系統須要轉換從輸入到輸出的離散數據流。許多類型轉換在實踐中重複出現，所以將其建立成獨立的可複用的部分，這是比較理想的。

 2 問題 

這些系統須要被分割成可複用的鬆耦合的組件，組件之間擁有簡單通用的交互機制。這樣它們就能夠靈活地相互結合。這些通用鬆耦合的組件就很容易複用。那些獨立的組件能夠並行執行。

 3 方案 

這種架構中的管道構成了過濾器之間的通訊通道。第一個概念是，因爲性能緣由，每一個管道都是非定向的和點對點的，接受來自一個源的輸入並常常直接輸出到另一個源。

在這種模式中，有以下四種過濾器。

• producer（ source ）：一個過程的起點。
• transformer ( map )：對一些或全部數據進行轉換。
• tester ( reduce )：測試一個或多個條件。
• consumer ( sink )：終點。

 4 弱點 

不太適合交互性的系統，由於它們的轉換特性。

過多的解析和反解析會致使性能損失，也會增長編寫過濾器自己的複雜性。

 5 用途 

管道 - 過濾器架構用於各類應用程序，特別是簡化單項處理的任務，例如 EDI、ETL 工具。

編譯器：連續的過濾器執行詞法分析、語法分析、語義分析和代碼生成。

4

客戶端-過濾器架構

 1 上下文 

有許多共享資源和服務是大量分佈式的客戶端但願訪問的，咱們但願控制訪問或服務質量。

 2 問題 

經過管理一組共享資源和服務，咱們能夠經過分解公共服務並在單個位置或少數位置進行修改來提升可修改性和複用性。咱們想要經過在將資源自己分佈在多個物理服務器上的同時集中控制這些資源和服務，來提升可伸縮性和可用性。

 3 方案 

在客戶端 - 服務器模式中，組件和鏈接器具備特定的行爲。

稱爲「客戶端」的組件將請求發送到稱爲「服務器」的組件，而後等待回覆。

服務器組件接收到客戶端的請求並向其發送回覆。

 4 弱點 

服務器會成爲性能瓶頸和單點故障位置。

在系統建成後，關於功能位置（在客戶端仍是在服務器）的決策一般是複雜的並且變更成本很大。

 5 用途 

對於有許多組件（客戶端）發送請求到另一些提供服務的組件（服務器）的系統，咱們可使用客戶端 - 服務器模式來建模這個系統的一部分：在線應用程序，例如電子郵件、共享文檔或銀行服務。

5

模型-視圖-控制器架構（MVC）

 1 上下文 

用戶界面一般是一個交互性應用程序的最頻繁被修改的部分。用戶一般但願從不一樣的視角查看數據，例如柱狀圖或者餅圖。這些表示形式都應該反映數據當前的狀態。

 2 問題 

用戶界面功能如何獨立於應用程序功能，同時還還對用戶輸入或底層應用程序數據的更改作出響應？

當底層應用程序數據更改時，如何建立、維護和協調用戶界面的多個視圖？

 3 方案 

模型 - 視圖 - 控制器（model-view-controller，即 MVC）模式將應用程序功能分爲如下三種類型的組件：

• 模型，包含應用程序的數據。
• 視圖，顯示部分底層數據並與用戶交互。
• 控制器，在模型和視圖之間進行中介並管理狀態更改的通知。

 4 弱點 

對於簡單的用戶界面，其複雜性並不值得這麼作。

模型、視圖和控制器抽象可能不適用於某些用戶界面工具包。

 5 用途 

MVC 是網站或移動應用程序開發用戶界面經常使用的一種架構模式。

6

事件驅動架構

 1 上下文 

須要提供計算和信息資源來處理傳入的應用程序生成的獨立異步事件，這種方式能夠隨着需求的增長而擴展。

 2 問題 

構建分佈式系統，這個系統能夠服務異步到達的事件相關信息，而且能從簡單小型擴展到複雜大型。

 3 方案 

爲事件處理部署獨立的事件進程或處理器。到達的事件進入隊列。調度程序根據調度策略從隊列中拉取事件並將它們分配到合適的事件處理器。

 4 弱點 

性能和錯誤恢復多是問題。

 5 用途 

使用這個方案的電商應用程序將工做以下：

Order Service 建立一個 Order，這個訂單處於待定狀態，而後發佈一個 OrderCreated 事件。

Customer Service 接收到這個事件並嘗試爲這個 Order 扣除信用。而後發佈一個 Credit Reserved 事件或者 CreditLimitExceeded （超出信用限額）事件。

Order Service 接收到 Customer Service 發送的事件並將訂單狀態更改成已覈准或已取消。

7

微服務架構

 1 上下文 

部署基於服務器的企業應用程序，支持各類瀏覽器和原生移動客戶端。應用程序經過執行業務邏輯、訪問數據庫、與其它系統交換信息並返回響應來處理客戶端請求。這個應用程序可能會暴露一個第三方 API。

 2 問題 

一體化應用程序會變得過於龐大和複雜，沒法獲得有效支持和部署來實現最優的分佈式資源利用，例如在雲環境中。

 3 方案 

將應用程序構建成服務套件。每一個服務都是獨立部署和可擴展的，擁有本身的 API 邊界。不一樣的服務能夠用不一樣的編程語言編寫，管理它們本身的數據庫，由不一樣的團隊開發。

 4 弱點 

系統設計必須能容忍服務失敗，須要更多的系統監控。服務編排和事件協做開銷比較大。

固然，咱們還須要更多錢。

 5 用途 

許多使用場景均可以應用微服務架構，特別是那些涉及大量數據管道的場景。例如，一個微服務系統對關於一個公司的零售店銷售的報表系統會比較理想。數據展示過程的每一步都會被一個微服務處理：數據收集、清理、規範化、濃縮、聚合、報告等。

END

版權申明：內容來源網絡，版權歸原創者全部。除非沒法確認，咱們都會標明做者及出處，若有侵權煩請告知，咱們會當即刪除並表示歉意。謝謝。

若是你以爲文章不錯，文末的贊 👍 又回來啦， 記得給我「點贊」和「在看」哦～

本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。