10種常見的軟件架構模式

Tips
原文做者：Vijini Mallawaarachchi
原文地址：10 Common Software Architectural Patterns in a nutshell

有沒有想過要設計多大的企業規模系統？在主要的軟件開發開始以前，咱們必須選擇一個合適的體系結構，它將爲咱們提供所需的功能和質量屬性。所以，在將它們應用到咱們的設計以前，咱們應該瞭解不一樣的體系結構。

什麼是架構模式？

根據維基百科中的定義：

架構模式是一個通用的、可重用的解決方案，用於在給定上下文中的軟件體系結構中常常出現的問題。架構模式與軟件設計模式相似，但具備更普遍的範圍。

在本文中，將簡要地解釋如下10種常見的體系架構模式，以及它們的用法、優缺點。

1. 分層模式
2. 客戶端-服務器模式
3. 主從設備模式
4. 管道-過濾器模式
5. 代理模式
6. 點對點模式
7. 事件總線模式
8. 模型-視圖-控制器模式
9. 黑板模式
10. 解釋器模式

一. 分層模式

這種模式也稱爲多層體系架構模式。它能夠用來構造能夠分解爲子任務組的程序，每一個子任務都處於一個特定的抽象級別。每一個層都爲下一個提供更高層次服務。

通常信息系統中最多見的是以下所列的4層。

• 表示層(也稱爲UI層)
• 應用層(也稱爲服務層)
• 業務邏輯層(也稱爲領域層)
• 數據訪問層(也稱爲持久化層)

使用場景：

• 通常的桌面應用程序
• 電子商務Web應用程序

二. 客戶端-服務器模式

這種模式由兩部分組成：一個服務器和多個客戶端。服務器組件將爲多個客戶端組件提供服務。客戶端從服務器請求服務，服務器爲這些客戶端提供相關服務。此外，服務器持續偵聽客戶機請求。

使用場景：

• 電子郵件，文件共享和銀行等在線應用程序

三. 主從設備模式

這種模式由兩方組成;主設備和從設備。主設備組件在相同的從設備組件中分配工做，並計算最終結果，這些結果是由從設備返回的結果。

使用場景：

• 在數據庫複製中，主數據庫被認爲是權威的來源，而且要與之同步
• 在計算機系統中與總線鏈接的外圍設備(主和從驅動器)

四. 管道-過濾器模式

此模式可用於構造生成和處理數據流的系統。每一個處理步驟都封裝在一個過濾器組件內。要處理的數據是經過管道傳遞的。這些管道能夠用於緩衝或用於同步。

使用場景：

• 編譯器。連續的過濾器執行詞法分析、解析、語義分析和代碼生成
• 生物信息學的工做流

五. 代理模式

此模式用於構造具備解耦組件的分佈式系統。這些組件能夠經過遠程服務調用彼此交互。代理組件負責組件之間的通訊協調。

服務器將其功能(服務和特徵)發佈給代理。客戶端從代理請求服務，而後代理將客戶端重定向到其註冊中心的適當服務。

使用場景：

• 消息代理軟件，如Apache ActiveMQ，Apache Kafka，RabbitMQ和JBoss Messaging

六. 點對點模式

在這種模式中，單個組件被稱爲對等點。對等點能夠做爲客戶端，從其餘對等點請求服務，做爲服務器，爲其餘對等點提供服務。對等點能夠充當客戶端或服務器或二者的角色，而且能夠隨時間動態地更改其角色。

使用場景：

• 像Gnutella和G2這樣的文件共享網絡
• 多媒體協議，如P2PTV和PDTP
• 像Spotify這樣的專有多媒體應用程序

七. 事件總線模式

這種模式主要是處理事件，包括4個主要組件：事件源、事件監聽器、通道和事件總線。消息源將消息發佈到事件總線上的特定通道上。偵聽器訂閱特定的通道。偵聽器會被通知消息，這些消息被髮布到它們以前訂閱的一個通道上。

使用場景：

• 安卓開發
• 通知服務

八. 模型-視圖-控制器模式

這種模式，也稱爲MVC模式，把一個交互式應用程序劃分爲3個部分，

• 模型：包含核心功能和數據
• 視圖：將信息顯示給用戶(能夠定義多個視圖)
• 控制器：處理用戶輸入的信息

這樣作是爲了將信息的內部表示與信息的呈現方式分離開來，並接受用戶的請求。它分離了組件，並容許有效的代碼重用。

使用場景：

• 在主要編程語言中互聯網應用程序的體系架構
• 像Django和Rails這樣的Web框架

九. 黑板模式

這種模式對於沒有肯定解決方案策略的問題是有用的。黑板模式由3個主要組成部分組成。

• 黑板——包含來自解決方案空間的對象的結構化全局內存
• 知識源——專門的模塊和它們本身的表示
• 控制組件——選擇、配置和執行模塊

全部的組件均可以訪問黑板。組件能夠生成添加到黑板上的新數據對象。組件在黑板上查找特定類型的數據，並經過與現有知識源的模式匹配來查找這些數據。

使用場景：

• 語音識別
• 車輛識別和跟蹤
• 蛋白質結構識別
• 聲納信號的解釋

十. 解釋器模式

這個模式用於設計一個解釋用專用語言編寫的程序的組件。它主要指定如何評估程序的行數，即以特定的語言編寫的句子或表達式。其基本思想是爲每種語言的符號都有一個分類。

使用場景：

• 數據庫查詢語言，好比SQL
• 用於描述通訊協議的語言

---

體系架構模式的比較

下面給出的表格總結了每種體系架構模式的優缺點。

名稱	優勢	缺點
分層模式	一個較低的層能夠被不一樣的層所使用。層使標準化更容易，由於咱們能夠清楚地定義級別。能夠在層內進行更改，而不會影響其餘層。	不是廣泛適用的。在某些狀況下，某些層可能會被跳過。
客戶端-服務器模式	很好地創建一組服務，用戶能夠請求他們的服務。	請求一般在服務器上的單獨線程中處理。因爲不一樣的客戶端具備不一樣的表示，進程間通訊會致使額外開銷。
主從設備模式	準確性——將服務的執行委託給不一樣的從設備，具備不一樣的實現。	從設備是孤立的：沒有共享的狀態。主-從通訊中的延遲多是一個問題，例如在實時系統中。這種模式只能應用於能夠分解的問題。
管道-過濾器模式	展現併發處理。當輸入和輸出由流組成時，過濾器在接收數據時開始計算。輕鬆添加過濾器，系統能夠輕鬆擴展。過濾器可重複使用。 能夠經過從新組合一組給定的過濾器來構建不一樣的管道。	效率受到最慢的過濾過程的限制。從一個過濾器移動到另外一個過濾器時的數據轉換開銷。
代理模式	容許動態更改、添加、刪除和從新定位對象，這使開發人員的發佈變得透明。	要求對服務描述進行標準化。
點對點模式	支持分散式計算。對任何給定節點的故障處理具備強大的健壯性。在資源和計算能力方面具備很高的可擴展性。	服務質量沒有保證，由於節點是自願合做的。安全是很可貴到保證的。性能取決於節點的數量。
事件總線模式	新的發佈者、訂閱者和鏈接能夠很容易地添加。對高度分佈式的應用程序有效。	可伸縮性多是一個問題，由於全部消息都是經過同一事件總線進行的。
模型-視圖-控制器模式	能夠輕鬆地擁有同一個模型的多個視圖，這些視圖能夠在運行時鏈接和斷開。	增長複雜性。可能致使許多沒必要要的用戶操做更新。
黑板模式	很容易添加新的應用程序。擴展數據空間的結構很簡單。	修改數據空間的結構很是困難，由於全部應用程序都受到了影響。可能須要同步和訪問控制。
解釋器模式	高度動態的行爲是可行的。對終端用戶編程性提供好處。提升靈活性，由於替換一個解釋程序很容易。	因爲解釋語言一般比編譯後的語言慢，所以性能多是一個問題。