10個常見的軟件架構模式
[導讀]想知道如何設計大型企業(yè)級的系統(tǒng)嗎？在開始主要的代碼開發(fā)之前，我們必須選擇一種合適的體系架構，它將為我們提供所需的功能和質量屬性。因此，在將它們應用到我們的設計之前，應該先了解不同的體系結構。-???什么是架構模式???-根據(jù)維基百科，架構模式是在給定上下文中解決軟件架構中常見問題...
想知道如何設計大型企業(yè)級的系統(tǒng)嗎？在開始主要的代碼開發(fā)之前，我們必須選擇一種合適的體系架構，它將為我們提供所需的功能和質量屬性。因此，在將它們應用到我們的設計之前，應該先了解不同的體系結構。
-? ? ?什么是架構模式? ? ?-
根據(jù)維基百科，
-? ? ?分層模式? ? ?-
該模式可用于構建可分解為子任務組的程序，其中每個都處于特定的抽象級別。每一次都向更高層提供服務。
一般信息系統(tǒng)中最常見的4層劃分如下：
-? ? ?客戶端-服務器模式? ? ?-
該模式由兩部分組成：一個服務端和多個客戶端，服務器向多個客戶端提供服務?？蛻舳讼蚍掌靼l(fā)起請求，服務器向這些客戶端提供相關服務，之后，服務器繼續(xù)偵聽客戶端的請求。
-? ? ?主從模式? ? ?-
該模式也分為兩塊：主模塊和從模塊。主模塊在相同的從模塊之間分配工作，并根據(jù)從模塊返回的結構來計算最終的結果。應用
-? ? ?管道過濾模式? ? ?-
此模式可用于構建產生和處理數(shù)據(jù)流的系統(tǒng)。每個處理步驟都包含在一個過濾器組件中，要處理的數(shù)據(jù)通過管道傳遞。這些管道可用于緩沖或者同步。
-? ? ?Broker模式? ? ?-
此模式是使用解耦的組件構建分布式系統(tǒng)，這些組件可以通過遠程服務調用實現(xiàn)交互。代理組件負責協(xié)調組件之間的通信。
服務器將它們的功能（服務和特征等）發(fā)布到代理，客戶端向代理請求服務，然后代理根據(jù)其注冊表將客戶端請求轉發(fā)給合適的服務。
-? ? ?P2P模式? ? ?-
在此模式中，每個獨立的組件被稱為對等點（或對等端，peer）。對等端既可以充當客戶端（向其它對等端請求服務），又可以充當服務器（向其它對等方提供服務）。同一個對等端可能既是客戶端，又是服務器，并且可以動態(tài)改變其角色。
-? ? ?事物總線模式? ? ?-
該模式主要處理組件，有4個重要的組件：事件源、事件偵聽器、通道和事件總線。事件源將消息發(fā)送到事件總線上的特定通道，偵聽器會訂閱特定的頻道。當消息發(fā)送到頻道中后，訂閱該頻道的偵聽器會收到該消息的通知。
-? ? ?MVC模式? ? ?-
該模式將交互式應用分為三個部分，
-? ? ?黑板模式? ? ?-
此模式對于尚無確定性解決方案的問題很有用，黑板模式由三部分組成：
-? ? ?解釋器模式? ? ?-
此模式通常用于設計組件來解釋使用專用語言寫出的程序，它主要指定如何估算程序行，即以特定語言編寫的語句或表達式?；舅枷胧菫槊糠N語言符號都設計一個類。
-? ? ?架構模式對比? ? ?-
-? ? ?什么是架構模式? ? ?-
根據(jù)維基百科，
架構模式是在給定上下文中解決軟件架構中常見問題的通用、可重用的解決方案。架構模式類似于軟件設計模式，但范圍更廣。在本文中，我會簡單介紹下列10種常見的架構模式，及其用途、優(yōu)勢和劣勢。
-? ? ?分層模式? ? ?-
該模式可用于構建可分解為子任務組的程序，其中每個都處于特定的抽象級別。每一次都向更高層提供服務。
一般信息系統(tǒng)中最常見的4層劃分如下：
- Presentation layer?表示層（也就是UI層）
- Application layer?應用層（也就是服務層）
- Business logic layer?業(yè)務邏輯層（也就是領域層）
- Data access layer?數(shù)據(jù)訪問層（也就是數(shù)據(jù)持久層）
- 一般桌面應用程序
- 電子商務Web應用程序
-? ? ?客戶端-服務器模式? ? ?-
該模式由兩部分組成：一個服務端和多個客戶端，服務器向多個客戶端提供服務?？蛻舳讼蚍掌靼l(fā)起請求，服務器向這些客戶端提供相關服務，之后，服務器繼續(xù)偵聽客戶端的請求。
應用
- 在線應用程序，如電子郵件、文件共享和銀行業(yè)務等
-? ? ?主從模式? ? ?-
該模式也分為兩塊：主模塊和從模塊。主模塊在相同的從模塊之間分配工作，并根據(jù)從模塊返回的結構來計算最終的結果。應用
- 在數(shù)據(jù)庫復制中，主數(shù)據(jù)庫被視作權威數(shù)據(jù)源，而從數(shù)據(jù)庫與其保持同步
- 連接到計算機系統(tǒng)總線上的外圍設備（主驅動器和從驅動器）
-? ? ?管道過濾模式? ? ?-
此模式可用于構建產生和處理數(shù)據(jù)流的系統(tǒng)。每個處理步驟都包含在一個過濾器組件中，要處理的數(shù)據(jù)通過管道傳遞。這些管道可用于緩沖或者同步。
應用
- 編譯器。依次使用不同的過濾器執(zhí)行詞法分析、解析、語法分析和代碼生成
- 生物信息學中的工作流程
-? ? ?Broker模式? ? ?-
此模式是使用解耦的組件構建分布式系統(tǒng)，這些組件可以通過遠程服務調用實現(xiàn)交互。代理組件負責協(xié)調組件之間的通信。
服務器將它們的功能（服務和特征等）發(fā)布到代理，客戶端向代理請求服務，然后代理根據(jù)其注冊表將客戶端請求轉發(fā)給合適的服務。
應用
- 消息代理軟件，如?Apache ActiveMQ,?Apache Kafka,?RabbitMQ?和?JBoss Messaging.
-? ? ?P2P模式? ? ?-
在此模式中，每個獨立的組件被稱為對等點（或對等端，peer）。對等端既可以充當客戶端（向其它對等端請求服務），又可以充當服務器（向其它對等方提供服務）。同一個對等端可能既是客戶端，又是服務器，并且可以動態(tài)改變其角色。
應用
- 文件共享網(wǎng)絡，如Gnutella?和?G2
- 多媒體協(xié)議，如P2PTV?和?PDTP
- 基于加密貨幣的產品，如比特幣和區(qū)塊鏈
-? ? ?事物總線模式? ? ?-
該模式主要處理組件，有4個重要的組件：事件源、事件偵聽器、通道和事件總線。事件源將消息發(fā)送到事件總線上的特定通道，偵聽器會訂閱特定的頻道。當消息發(fā)送到頻道中后，訂閱該頻道的偵聽器會收到該消息的通知。
應用
- 安卓開發(fā)
- 通知服務
-? ? ?MVC模式? ? ?-
該模式將交互式應用分為三個部分，
- 模型——包含核心功能和數(shù)據(jù)
- 視圖——向用戶顯示信息（可以定義多個視圖）
- 控制器——處理用戶的輸入
應用
- 主流編程語言的互聯(lián)網(wǎng)應用架構
- 網(wǎng)絡框架，如Django?和?Rails.
-? ? ?黑板模式? ? ?-
此模式對于尚無確定性解決方案的問題很有用，黑板模式由三部分組成：
- 黑板—— 一個結構化的全局內存，包含解決方案領域的對象
- 知識源——具有自身含義的專業(yè)模塊
- 控制組件——選擇、配置和執(zhí)行模塊
應用
- 語音識別
- 車輛識別與跟蹤
- 蛋白質結構鑒定
- 聲吶信號解釋
-? ? ?解釋器模式? ? ?-
此模式通常用于設計組件來解釋使用專用語言寫出的程序，它主要指定如何估算程序行，即以特定語言編寫的語句或表達式?；舅枷胧菫槊糠N語言符號都設計一個類。
應用
- 數(shù)據(jù)庫查詢語言，如SQL
- 用于描述通信協(xié)議的語言
-? ? ?架構模式對比? ? ?-
| 模式 | 優(yōu)點 | 缺點 |
| 分層模式 | 一個底層服務可以被不同的高層服務使用； 分層結果更容易進行標準化，因為可以清晰地定義每個層級 層級內的修改不會影響其它層 | 不是普適性的架構； 某些場景下，需要跳過其中一些分層 |
| CS模式 | 容易對系列服務進行建模，供客戶端請求 | 請求通常是在服務器的不同線程中進行響應的； 因為不同客戶端有不同形式，進程間通信會造成很大負載 |
| 主從模式 | 準確性——服務的執(zhí)行委托給了不同的從模塊 | 從模塊是獨立的：沒有共享狀態(tài)； 主從模塊間的通信延遲可能是一個問題，尤其在實時系統(tǒng)中。 |
| 管道過濾器模式 | 支持并發(fā)處理，其中輸入、輸出由數(shù)據(jù)流組成時，過濾器在接收到數(shù)據(jù)時即開始計算； 容易添加過濾器，系統(tǒng)很容易擴展； 過濾器可重用，可以通過重新組合已有的過濾器來創(chuàng)建不同的管道流。 | 整體效率受最慢的過濾程序限制； 從一個過濾器傳遞到另一個時，存在數(shù)據(jù)轉換的負載 |
| 代理模式 | 允許對象進行動態(tài)的修改、增、刪、重定位，對開發(fā)者來說內容分發(fā)是透明的 | 需要對服務描述進行標準化 |
| P2P模式 | 支持去中心化運算； 對任意節(jié)點的失敗都有高度穩(wěn)定性； 在資源和計算能力方面具有高度可伸縮性 | 無法保證服務質量，因為節(jié)點之間是自愿合作的； 很難保證安全； 性能取決于節(jié)點的數(shù)量 |
| 事件總線模式 | 很容易向系統(tǒng)好加入新的發(fā)布者、訂閱者和連接； 對于高度分布式應用很有效 | 伸縮性可能是個難題，因為所有的信息傳輸都要通過相同的時間總線 |
| MVC模式 | 對同一模型很容易構建多個視圖，在運行時可以任意連接或斷開 | 增加了復雜性，用戶操作可能導致很多不必要的更新 |
| 黑板模式 | 容易添加新應用； 很容易擴展數(shù)據(jù)空間中的結構 | 修改數(shù)據(jù)空間的結構很難，因為所有的應用都會被影響； 可能需要同步機制和訪問控制 |
| 解釋器模式 | 可能支持高度動態(tài)化行為； 有利于終端用戶的可編程性； 增強了靈活性，因為替換一個解釋程序很容易 | 因為解釋型語言通常比編譯型語言要慢，因此性能可能是一個問題 |
下載文檔
