超詳細(xì)講解!10 種常見的軟件架構(gòu)模式
作者:Vijini Mallawaarachchi
地址:https://www.cnblogs.com/IcanFixIt/p/7518146.html
想知道如何設(shè)計(jì)大型企業(yè)級的系統(tǒng)嗎?在開始主要的代碼開發(fā)之前,我們必須選擇一種合適的體系架構(gòu),它將為我們提供所需的功能和質(zhì)量屬性。因此,在將它們應(yīng)用到我們的設(shè)計(jì)之前,應(yīng)該先了解不同的體系結(jié)構(gòu)。
什么是架構(gòu)模式
根據(jù)維基百科,架構(gòu)模式是在給定上下文中解決軟件架構(gòu)中常見問題的通用、可重用的解決方案。架構(gòu)模式類似于軟件設(shè)計(jì)模式,但范圍更廣。
在本文中,我會簡單介紹下列10種常見的架構(gòu)模式,及其用途、優(yōu)勢和劣勢。
分層模式 客戶端-服務(wù)器模式 主從設(shè)備模式 管道-過濾器模式 代理模式 點(diǎn)對點(diǎn)模式 事件總線模式 模型-視圖-控制器模式 黑板模式 解釋器模式
分層模式
該模式可用于構(gòu)建可分解為子任務(wù)組的程序,其中每個都處于特定的抽象級別。每一次都向更高層提供服務(wù)。
一 般信息系統(tǒng)中最常見的4層劃分如下:
Presentation layer 表示層(也就是UI層) Application layer 應(yīng)用層(也就是服務(wù)層) Business logic layer 業(yè)務(wù)邏輯層(也就是領(lǐng)域?qū)樱?/span> Data access layer 數(shù)據(jù)訪問層(也就是數(shù)據(jù)持久層)
應(yīng)用
一般桌面應(yīng)用程序 電子商務(wù)Web應(yīng)用程序
客戶端-服務(wù)器模式
該模式由兩部分組成:一個服務(wù)端和多個客戶端,服務(wù)器向多個客戶端提供服務(wù)??蛻舳讼蚍?wù)器發(fā)起請求,服務(wù)器向這些客戶端提供相關(guān)服務(wù),之后,服務(wù)器繼續(xù)偵聽客戶端的請求。
應(yīng)用
在線應(yīng)用程序,如電子郵件、文件共享和銀行業(yè)務(wù)等
主從模式
該模式也分為兩塊:主模塊和從模塊。主模塊在相同的從模塊之間分配工作,并根據(jù)從模塊返回的結(jié)構(gòu)來計(jì)算最終的結(jié)果。
應(yīng)用
在數(shù)據(jù)庫復(fù)制中,主數(shù)據(jù)庫被視作權(quán)威數(shù)據(jù)源,而從數(shù)據(jù)庫與其保持同步 連接到計(jì)算機(jī)系統(tǒng)總線上的外圍設(shè)備(主驅(qū)動器和從驅(qū)動器)
管道過濾模式
此模式可用于構(gòu)建產(chǎn)生和處理數(shù)據(jù)流的系統(tǒng)。每個處理步驟都包含在一個過濾器組件中,要處理的數(shù)據(jù)通過管道傳遞。這些管道可用于緩沖或者同步。
應(yīng)用
編譯器。依次使用不同的過濾器執(zhí)行詞法分析、解析、語法分析和代碼生成 生物信息學(xué)中的工作流程
Broker模式
此模式是使用解耦的組件構(gòu)建分布式系統(tǒng),這些組件可以通過遠(yuǎn)程服務(wù)調(diào)用實(shí)現(xiàn)交互。代理組件負(fù)責(zé)協(xié)調(diào)組件之間的通信。
服務(wù)器將它們的功能(服務(wù)和特征等)發(fā)布到代理,客戶端向代理請求服務(wù),然后代理根據(jù)其注冊表將客戶端請求轉(zhuǎn)發(fā)給合適的服務(wù)。
應(yīng)用
消息代理軟件,如 Apache ActiveMQ, Apache Kafka, RabbitMQ 和 JBoss Messaging.
P2P模式
在此模式中,每個獨(dú)立的組件被稱為對等點(diǎn)(或?qū)Φ榷?,peer)。對等端既可以充當(dāng)客戶端(向其它對等端請求服務(wù)),又可以充當(dāng)服務(wù)器(向其它對等方提供服務(wù))。同一個對等端可能既是客戶端,又是服務(wù)器,并且可以動態(tài)改變其角色。
應(yīng)用
文件共享網(wǎng)絡(luò),如Gnutella 和 G2 多媒體協(xié)議,如P2PTV 和 PDTP 基于加密貨幣的產(chǎn)品,如比特幣和區(qū)塊鏈

事物總線模式
該模式主要處理組件,有4個重要的組件:事件源、事件偵聽器、通道和事件總線。事件源將消息發(fā)送到事件總線上的特定通道,偵聽器會訂閱特定的頻道。當(dāng)消息發(fā)送到頻道中后,訂閱該頻道的偵聽器會收到該消息的通知。
應(yīng)用
安卓開發(fā) 通知服務(wù)
MVC模式
該模式將交互式應(yīng)用分為三個部分,
模型——包含核心功能和數(shù)據(jù) 視圖——向用戶顯示信息(可以定義多個視圖) 控制器——處理用戶的輸入
這樣做是為了將數(shù)據(jù)的內(nèi)部表示與用戶輸入和向用戶展示的形式分離開來,這樣可以解耦組件,同時(shí)也可以進(jìn)行高效的代碼重用。
應(yīng)用
主流編程語言的互聯(lián)網(wǎng)應(yīng)用架構(gòu)-網(wǎng)絡(luò)框架,如Django 和 Rails.
黑板模式
此模式對于尚無確定性解決方案的問題很有用,黑板模式由三部分組成:
黑板—— 一個結(jié)構(gòu)化的全局內(nèi)存,包含解決方案領(lǐng)域的對象 知識源——具有自身含義的專業(yè)模塊 控制組件——選擇、配置和執(zhí)行模塊
所有組件都可以訪問黑板,組件可能會產(chǎn)生要添加到黑板中的新數(shù)據(jù)對象,組件在黑板上尋找特定類型的數(shù)據(jù),并且可以通過與現(xiàn)有知識源進(jìn)行模式匹配來找到這些數(shù)據(jù)。
應(yīng)用
語音識別 車輛識別與跟蹤 蛋白質(zhì)結(jié)構(gòu)鑒定 聲吶信號解釋
解釋器模式
此模式通常用于設(shè)計(jì)組件來解釋使用專用語言寫出的程序,它主要指定如何估算程序行,即以特定語言編寫的語句或表達(dá)式。基本思想是為每種語言符號都設(shè)計(jì)一個類。
應(yīng)用
數(shù)據(jù)庫查詢語言,如SQL 用于描述通信協(xié)議的語言
架構(gòu)模式對比
| 模式 | 優(yōu)點(diǎn) | 缺點(diǎn) |
|---|---|---|
| 分層模式 | 一個底層服務(wù)可以被不同的高層服務(wù)使用;分層結(jié)果更容易進(jìn)行標(biāo)準(zhǔn)化,因?yàn)榭梢郧逦囟x每個層級,層級內(nèi)的修改不會影響其它層 | 不是普適性的架構(gòu);某些場景下,需要跳過其中一些分層 |
| CS模式 | 容易對系列服務(wù)進(jìn)行建模,供客戶端請求請求 | 通常是在服務(wù)器的不同線程中進(jìn)行響應(yīng)的; |
| 主從模式 | 準(zhǔn)確性——服務(wù)的執(zhí)行委托給了不同的從模塊 | 從模塊是獨(dú)立的:沒有共享狀態(tài);主從模塊間的通信延遲可能是一個問題,尤其在實(shí)時(shí)系統(tǒng)中。 |
| 管道過濾器模式 | 支持并發(fā)處理,其中輸入、輸出由數(shù)據(jù)流組成時(shí),過濾器在接收到數(shù)據(jù)時(shí)即開始計(jì)算;容易添加過濾器,系統(tǒng)很容易擴(kuò)展;過濾器可重用,可以通過重新組合已有的過濾器來創(chuàng)建不同的管道流。 | 整體效率受最慢的過濾程序限制;從一個過濾器傳遞到另一個時(shí),存在數(shù)據(jù)轉(zhuǎn)換的負(fù)載 |
| 代理模式 | 允許對象進(jìn)行動態(tài)的修改、增、刪、重定位,對開發(fā)者來說內(nèi)容分發(fā)是透明的 | 需要對服務(wù)描述進(jìn)行標(biāo)準(zhǔn)化 |
| P2P模式 | 支持去中心化運(yùn)算;對任意節(jié)點(diǎn)的失敗都有高度穩(wěn)定性;在資源和計(jì)算能力方面具有高度可伸縮性 | 無法保證服務(wù)質(zhì)量,因?yàn)楣?jié)點(diǎn)之間是自愿合作的;很難保證安全;性能取決于節(jié)點(diǎn)的數(shù)量 |
| 事件總線模式 | 很容易向系統(tǒng)好加入新的發(fā)布者、訂閱者和連接;對于高度分布式應(yīng)用很有效 | 伸縮性可能是個難題,因?yàn)樗械男畔鬏敹家ㄟ^相同的時(shí)間總線 |
| MVC模式 | 對同一模型很容易構(gòu)建多個視圖,在運(yùn)行時(shí)可以任意連接或斷開 | 增加了復(fù)雜性,用戶操作可能導(dǎo)致很多不必要的更新 |
| 黑板模式 | 容易添加新應(yīng)用;很容易擴(kuò)展數(shù)據(jù)空間中的結(jié)構(gòu) | 修改數(shù)據(jù)空間的結(jié)構(gòu)很難,因?yàn)樗械膽?yīng)用都會被影響;可能需要同步機(jī)制和訪問控制 |
| 解釋器模式 | 可能支持高度動態(tài)化行為;有利于終端用戶的可編程性;增強(qiáng)了靈活性,因?yàn)樘鎿Q一個解釋程序很容易 | 因?yàn)榻忉屝驼Z言通常比編譯型語言要慢,因此性能可能是一個問題 |












