常見的軟體架構模式

什麼是架構模式？

根據維基百科中的定義：

架構模式是一個通用的、可重用的解決方案，用于在給定上下文中的軟體體系結構中經常出現的問題。架構模式與軟體設計模式類似，但具有更廣泛的範圍。
           

在本文中，将簡要地解釋以下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
• 用于描述通信協定的語言

體系架構模式的比較

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

名稱	優點	缺點
分層模式	一個較低的層可以被不同的層所使用。層使标準化更容易，因為我們可以清楚地定義級别。可以在層内進行更改，而不會影響其他層。	不是普遍适用的。在某些情況下，某些層可能會被跳過。
用戶端-伺服器模式	很好地建立一組服務，使用者可以請求他們的服務。	請求通常在伺服器上的單獨線程中處理。由于不同的用戶端具有不同的表示，程序間通信會導緻額外開銷。
主從裝置模式	準确性——将服務的執行委托給不同的從裝置，具有不同的實作。	從裝置是孤立的：沒有共享的狀态。主-從通信中的延遲可能是一個問題，例如在實時系統中。這種模式隻能應用于可以分解的問題。
管道-過濾器模式	展示并發處理。當輸入和輸出由流組成時，過濾器在接收資料時開始計算。輕松添加過濾器，系統可以輕松擴充。過濾器可重複使用。 可以通過重新組合一組給定的過濾器來建構不同的管道。	效率受到最慢的過濾過程的限制。從一個過濾器移動到另一個過濾器時的資料轉換開銷。
代理模式	允許動态更改、添加、删除和重新定位對象，這使開發人員的釋出變得透明。	要求對服務描述進行标準化。
點對點模式	支援分散式計算。對任何給定節點的故障處理具有強大的健壯性。在資源和計算能力方面具有很高的可擴充性。	服務品質沒有保證，因為節點是自願合作的。安全是很難得到保證的。性能取決于節點的數量。
事件總線模式	新的釋出者、訂閱者和連接配接可以很容易地添加。對高度分布式的應用程式有效。	可伸縮性可能是一個問題，因為所有消息都是通過同一事件總線進行的。
模型-視圖-控制器模式	可以輕松地擁有同一個模型的多個視圖，這些視圖可以在運作時連接配接和斷開。	增加複雜性。可能導緻許多不必要的使用者操作更新。
黑闆模式	很容易添加新的應用程式。擴充資料空間的結構很簡單。	修改資料空間的結構非常困難，因為所有應用程式都受到了影響。可能需要同步和通路控制。
解釋器模式	高度動态的行為是可行的。對終端使用者程式設計性提供好處。提高靈活性，因為替換一個解釋程式很容易。	由于解釋語言通常比編譯後的語言慢，是以性能可能是一個問題。