軟件|10種常見的軟件架構(gòu)模式
掃描二維碼
隨時隨地手機看文章
什么是架構(gòu)模式?
根據(jù)維基百科中的定義:
架構(gòu)模式是一個通用的、可重用的解決方案,用于在給定上下文中的軟件體系結(jié)構(gòu)中經(jīng)常出現(xiàn)的問題。架構(gòu)模式與軟件設(shè)計模式類似,但具有更廣泛的范圍。在本文中,將簡要地解釋以下10種常見的體系架構(gòu)模式,以及它們的用法、優(yōu)缺點。
-
分層模式
-
客戶端-服務(wù)器模式
-
主從設(shè)備模式
-
管道-過濾器模式
-
代理模式
-
點對點模式
-
事件總線模式
-
模型-視圖-控制器模式
-
黑板模式
-
解釋器模式
一. 分層模式
這種模式也稱為多層體系架構(gòu)模式。它可以用來構(gòu)造可以分解為子任務(wù)組的程序,每個子任務(wù)都處于一個特定的抽象級別。每個層都為下一個提供更高層次服務(wù)。
-
表示層(也稱為UI層)
-
應(yīng)用層(也稱為服務(wù)層)
-
業(yè)務(wù)邏輯層(也稱為領(lǐng)域?qū)?
-
數(shù)據(jù)訪問層(也稱為持久化層)
-
一般的桌面應(yīng)用程序
-
電子商務(wù)Web應(yīng)用程序
二. 客戶端-服務(wù)器模式
這種模式由兩部分組成:一個服務(wù)器和多個客戶端。服務(wù)器組件將為多個客戶端組件提供服務(wù)。客戶端從服務(wù)器請求服務(wù),服務(wù)器為這些客戶端提供相關(guān)服務(wù)。此外,服務(wù)器持續(xù)偵聽客戶機請求。
-
電子郵件,文件共享和銀行等在線應(yīng)用程序
三. 主從設(shè)備模式
這種模式由兩方組成;主設(shè)備和從設(shè)備。主設(shè)備組件在相同的從設(shè)備組件中分配工作,并計算最終結(jié)果,這些結(jié)果是由從設(shè)備返回的結(jié)果。
-
在數(shù)據(jù)庫復(fù)制中,主數(shù)據(jù)庫被認為是權(quán)威的來源,并且要與之同步
-
在計算機系統(tǒng)中與總線連接的外圍設(shè)備(主和從驅(qū)動器)
四. 管道-過濾器模式
此模式可用于構(gòu)造生成和處理數(shù)據(jù)流的系統(tǒng)。每個處理步驟都封裝在一個過濾器組件內(nèi)。要處理的數(shù)據(jù)是通過管道傳遞的。這些管道可以用于緩沖或用于同步。
-
編譯器。連續(xù)的過濾器執(zhí)行詞法分析、解析、語義分析和代碼生成
-
生物信息學(xué)的工作流
五. 代理模式
此模式用于構(gòu)造具有解耦組件的分布式系統(tǒng)。這些組件可以通過遠程服務(wù)調(diào)用彼此交互。代理組件負責(zé)組件之間的通信協(xié)調(diào)。
-
消息代理軟件,如Apache ActiveMQ,Apache Kafka,RabbitMQ和JBoss Messaging
六. 點對點模式
在這種模式中,單個組件被稱為對等點。對等點可以作為客戶端,從其他對等點請求服務(wù),作為服務(wù)器,為其他對等點提供服務(wù)。對等點可以充當(dāng)客戶端或服務(wù)器或兩者的角色,并且可以隨時間動態(tài)地更改其角色。
-
像Gnutella和G2這樣的文件共享網(wǎng)絡(luò)
-
多媒體協(xié)議,如P2PTV和PDTP
-
像Spotify這樣的專有多媒體應(yīng)用程序
七. 事件總線模式
這種模式主要是處理事件,包括4個主要組件:事件源、事件監(jiān)聽器、通道和事件總線。消息源將消息發(fā)布到事件總線上的特定通道上。偵聽器訂閱特定的通道。偵聽器會被通知消息,這些消息被發(fā)布到它們之前訂閱的一個通道上。
-
安卓開發(fā)
-
通知服務(wù)
八. 模型-視圖-控制器模式
這種模式,也稱為MVC模式,把一個交互式應(yīng)用程序劃分為3個部分,
-
模型:包含核心功能和數(shù)據(jù)
-
視圖:將信息顯示給用戶(可以定義多個視圖)
-
控制器:處理用戶輸入的信息
-
在主要編程語言中互聯(lián)網(wǎng)應(yīng)用程序的體系架構(gòu)
-
像Django和Rails這樣的Web框架
九. 黑板模式
這種模式對于沒有確定解決方案策略的問題是有用的。黑板模式由3個主要組成部分組成。
-
黑板——包含來自解決方案空間的對象的結(jié)構(gòu)化全局內(nèi)存
-
知識源——專門的模塊和它們自己的表示
-
控制組件——選擇、配置和執(zhí)行模塊
-
語音識別
-
車輛識別和跟蹤
-
蛋白質(zhì)結(jié)構(gòu)識別
-
聲納信號的解釋
十. 解釋器模式
這個模式用于設(shè)計一個解釋用專用語言編寫的程序的組件。它主要指定如何評估程序的行數(shù),即以特定的語言編寫的句子或表達式。其基本思想是為每種語言的符號都有一個分類。
-
數(shù)據(jù)庫查詢語言,比如SQL
-
用于描述通信協(xié)議的語言
體系架構(gòu)模式的比較
下面給出的表格總結(jié)了每種體系架構(gòu)模式的優(yōu)缺點。
名稱 | 優(yōu)點 | 缺點 |
---|---|---|
分層模式 | 一個較低的層可以被不同的層所使用。層使標(biāo)準(zhǔn)化更容易,因為我們可以清楚地定義級別??梢栽趯觾?nèi)進行更改,而不會影響其他層。 | 不是普遍適用的。在某些情況下,某些層可能會被跳過。 |
客戶端-服務(wù)器模式 | 很好地建立一組服務(wù),用戶可以請求他們的服務(wù)。 | 請求通常在服務(wù)器上的單獨線程中處理。由于不同的客戶端具有不同的表示,進程間通信會導(dǎo)致額外開銷。 |
主從設(shè)備模式 | 準(zhǔn)確性——將服務(wù)的執(zhí)行委托給不同的從設(shè)備,具有不同的實現(xiàn)。 | 從設(shè)備是孤立的:沒有共享的狀態(tài)。主-從通信中的延遲可能是一個問題,例如在實時系統(tǒng)中。這種模式只能應(yīng)用于可以分解的問題。 |
管道-過濾器模式 | 展示并發(fā)處理。當(dāng)輸入和輸出由流組成時,過濾器在接收數(shù)據(jù)時開始計算。輕松添加過濾器,系統(tǒng)可以輕松擴展。過濾器可重復(fù)使用??梢酝ㄟ^重新組合一組給定的過濾器來構(gòu)建不同的管道。 | 效率受到最慢的過濾過程的限制。從一個過濾器移動到另一個過濾器時的數(shù)據(jù)轉(zhuǎn)換開銷。 |
代理模式 | 允許動態(tài)更改、添加、刪除和重新定位對象,這使開發(fā)人員的發(fā)布變得透明。 | 要求對服務(wù)描述進行標(biāo)準(zhǔn)化。 |
點對點模式 | 支持分散式計算。對任何給定節(jié)點的故障處理具有強大的健壯性。在資源和計算能力方面具有很高的可擴展性。 | 服務(wù)質(zhì)量沒有保證,因為節(jié)點是自愿合作的。安全是很難得到保證的。性能取決于節(jié)點的數(shù)量。 |
事件總線模式 | 新的發(fā)布者、訂閱者和連接可以很容易地添加。對高度分布式的應(yīng)用程序有效。 | 可伸縮性可能是一個問題,因為所有消息都是通過同一事件總線進行的。 |
模型-視圖-控制器模式 | 可以輕松地擁有同一個模型的多個視圖,這些視圖可以在運行時連接和斷開。 | 增加復(fù)雜性??赡軐?dǎo)致許多不必要的用戶操作更新。 |
黑板模式 | 很容易添加新的應(yīng)用程序。擴展數(shù)據(jù)空間的結(jié)構(gòu)很簡單。 | 修改數(shù)據(jù)空間的結(jié)構(gòu)非常困難,因為所有應(yīng)用程序都受到了影響??赡苄枰胶驮L問控制。 |
解釋器模式 | 高度動態(tài)的行為是可行的。對終端用戶編程性提供好處。提高靈活性,因為替換一個解釋程序很容易。 | 由于解釋語言通常比編譯后的語言慢,因此性能可能是一個問題。 |