1. 程式人生 > 實用技巧 >企業架構中常見的十種軟體架構模式

企業架構中常見的十種軟體架構模式

想知道如何設計大型企業級的系統嗎?在開始主要的程式碼開發之前,我們必須選擇一種合適的體系架構,它將為我們提供所需的功能和質量屬性。因此,在將它們應用到我們的設計之前,應該先了解不同的體系結構。


- 什麼是架構模式 -

根據維基百科,

架構模式是在給定上下文中解決軟體架構中常見問題的通用、可重用的解決方案。架構模式類似於軟體設計模式,但範圍更廣。

在本文中,我會簡單介紹下列10種常見的架構模式,及其用途、優勢和劣勢。

- 分層模式 -

該模式可用於構建可分解為子任務組的程式,其中每個都處於特定的抽象級別。每一次都向更高層提供服務。
一般資訊系統中最常見的4層劃分如下:

  • Presentation layer

    表示層(也就是UI層)

  • Application layer應用層(也就是服務層)

  • Business logic layer業務邏輯層(也就是領域層)

  • Data access layer資料訪問層(也就是資料持久層)

應用

  • 一般桌面應用程式

  • 電子商務Web應用程式

- 客戶端-伺服器模式 -

該模式由兩部分組成:一個服務端和多個客戶端,伺服器向多個客戶端提供服務。客戶端向伺服器發起請求,伺服器向這些客戶端提供相關服務,之後,伺服器繼續偵聽客戶端的請求。

應用

  • 線上應用程式,如電子郵件、檔案共享和銀行業務等

- 主從模式 -

該模式也分為兩塊:主模組和從模組。主模組在相同的從模組之間分配工作,並根據從模組返回的結構來計算最終的結果。

應用

  • 在資料庫複製中,主資料庫被視作權威資料來源,而從資料庫與其保持同步

  • 連線到計算機系統總線上的外圍裝置(主驅動器和從驅動器)

- 管道過濾模式 -

此模式可用於構建產生和處理資料流的系統。每個處理步驟都包含在一個過濾器元件中,要處理的資料通過管道傳遞。這些管道可用於緩衝或者同步。

應用

  • 編譯器。依次使用不同的過濾器執行詞法分析、解析、語法分析和程式碼生成

  • 生物資訊學中的工作流程

- Broker模式 -

此模式是使用解耦的元件構建分散式系統,這些元件可以通過遠端服務呼叫實現互動。代理元件負責協調元件之間的通訊。
伺服器將它們的功能(服務和特徵等)釋出到代理,客戶端向代理請求服務,然後代理根據其登錄檔將客戶端請求轉發給合適的服務。

應用

  • 訊息代理軟體,如Apache ActiveMQ,Apache Kafka,RabbitMQ和JBoss Messaging.

- P2P模式 -

在此模式中,每個獨立的元件被稱為對等點(或對等端,peer)。對等端既可以充當客戶端(向其它對等端請求服務),又可以充當伺服器(向其它對等方提供服務)。同一個對等端可能既是客戶端,又是伺服器,並且可以動態改變其角色。

應用

  • 檔案共享網路,如Gnutella和G2

  • 多媒體協議,如P2PTV和PDTP

  • 基於加密貨幣的產品,如比特幣和區塊鏈

- 事物匯流排模式 -

該模式主要處理元件,有4個重要的元件:事件源、事件偵聽器、通道和事件匯流排。事件源將訊息傳送到事件總線上的特定通道,偵聽器會訂閱特定的頻道。當訊息傳送到頻道中後,訂閱該頻道的偵聽器會收到該訊息的通知。

應用

  • 安卓開發

  • 通知服務

- MVC模式 -

該模式將互動式應用分為三個部分,

  1. 模型——包含核心功能和資料

  2. 檢視——向用戶顯示資訊(可以定義多個檢視)

  3. 控制器——處理使用者的輸入

這樣做是為了將資料的內部表示與使用者輸入和向用戶展示的形式分離開來,這樣可以解耦元件,同時也可以進行高效的程式碼重用。

應用

  • 主流程式語言的網際網路應用架構

  • 網路框架,如DjangoRails.

- 黑板模式 -

此模式對於尚無確定性解決方案的問題很有用,黑板模式由三部分組成:

  • 黑板—— 一個結構化的全域性記憶體,包含解決方案領域的物件

  • 知識源——具有自身含義的專業模組

  • 控制組件——選擇、配置和執行模組

所有元件都可以訪問黑板,元件可能會產生要新增到黑板中的新資料物件,元件在黑板上尋找特定型別的資料,並且可以通過與現有知識源進行模式匹配來找到這些資料。

應用

  • 語音識別

  • 車輛識別與跟蹤

  • 蛋白質結構鑑定

  • 聲吶訊號解釋

- 直譯器模式 -

此模式通常用於設計元件來解釋使用專用語言寫出的程式,它主要指定如何估算程式行,即以特定語言編寫的語句或表示式。基本思想是為每種語言符號都設計一個類。

應用

  • 資料庫查詢語言,如SQL

  • 用於描述通訊協議的語言

- 架構模式對比 -

模式優點缺點

分層模式

一個底層服務可以被不同的高層服務使用;
分層結果更容易進行標準化,因為可以清晰地定義每個層級
層級內的修改不會影響其它層

不是普適性的架構;
某些場景下,需要跳過其中一些分層

CS模式

容易對系列服務進行建模,供客戶端請求

請求通常是在伺服器的不同執行緒中進行響應的;
因為不同客戶端有不同形式,程序間通訊會造成很大負載

主從模式

準確性——服務的執行委託給了不同的從模組

從模組是獨立的:沒有共享狀態;
主從模組間的通訊延遲可能是一個問題,尤其在實時系統中。

管道過濾器模式

支援併發處理,其中輸入、輸出由資料流組成時,過濾器在接收到資料時即開始計算;
容易新增過濾器,系統很容易擴充套件;
過濾器可重用,可以通過重新組合已有的過濾器來建立不同的管道流。

整體效率受最慢的過濾程式限制;
從一個過濾器傳遞到另一個時,存在資料轉換的負載

代理模式

允許物件進行動態的修改、增、刪、重定位,對開發者來說內容分發是透明的

需要對服務描述進行標準化

P2P模式

支援去中心化運算;
對任意節點的失敗都有高度穩定性;
在資源和計算能力方面具有高度可伸縮性

無法保證服務質量,因為節點之間是自願合作的;
很難保證安全;
效能取決於節點的數量

事件匯流排模式

很容易向系統好加入新的釋出者、訂閱者和連線;
對於高度分散式應用很有效

伸縮性可能是個難題,因為所有的資訊傳輸都要通過相同的時間匯流排

MVC模式

對同一模型很容易構建多個檢視,在執行時可以任意連線或斷開

增加了複雜性,使用者操作可能導致很多不必要的更新

黑板模式

容易新增新應用;
很容易擴充套件資料空間中的結構

修改資料空間的結構很難,因為所有的應用都會被影響;
可能需要同步機制和訪問控制

直譯器模式

可能支援高度動態化行為;
有利於終端使用者的可程式設計性;
增強了靈活性,因為替換一個解釋程式很容易

因為解釋型語言通常比編譯型語言要慢,因此效能可能是一個問題