公眾號關(guān)注“杰哥的IT之旅”，

選擇“星標(biāo)”，重磅干貨，第一時間送達(dá)！

想知道如何設(shè)計大型企業(yè)級的系統(tǒng)嗎？在開始主要的代碼開發(fā)之前，我們必須選擇一種合適的體系架構(gòu)，它將為我們提供所需的功能和質(zhì)量屬性。因此，在將它們應(yīng)用到我們的設(shè)計之前，應(yīng)該先了解不同的體系結(jié)構(gòu)。

-? ? ?什么是架構(gòu)模式? ? ?-

根據(jù)維基百科，

架構(gòu)模式是在給定上下文中解決軟件架構(gòu)中常見問題的通用、可重用的解決方案。架構(gòu)模式類似于軟件設(shè)計模式，但范圍更廣。

在本文中，我會簡單介紹下列10種常見的架構(gòu)模式，及其用途、優(yōu)勢和劣勢。

-? ? ?分層模式? ? ?-

該模式可用于構(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)來計算最終的結(jié)果。

應(yīng)用

• 在數(shù)據(jù)庫復(fù)制中，主數(shù)據(jù)庫被視作權(quán)威數(shù)據(jù)源，而從數(shù)據(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)用實現(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模式? ? ?-

在此模式中，每個獨立的組件被稱為對等點（或?qū)Φ榷耍琾eer）。對等端既可以充當(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)用分為三個部分，

1. 模型——包含核心功能和數(shù)據(jù)
2. 視圖——向用戶顯示信息（可以定義多個視圖）
3. 控制器——處理用戶的輸入

這樣做是為了將數(shù)據(jù)的內(nèi)部表示與用戶輸入和向用戶展示的形式分離開來，這樣可以解耦組件，同時也可以進(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è)計組件來解釋使用專用語言寫出的程序，它主要指定如何估算程序行，即以特定語言編寫的語句或表達(dá)式。基本思想是為每種語言符號都設(shè)計一個類。

應(yīng)用

• 數(shù)據(jù)庫查詢語言，如SQL
• 用于描述通信協(xié)議的語言

-? ? ?架構(gòu)模式對比? ? ?-

模式	優(yōu)點	缺點
分層模式	一個底層服務(wù)可以被不同的高層服務(wù)使用； 分層結(jié)果更容易進(jìn)行標(biāo)準(zhǔn)化，因為可以清晰地定義每個層級 層級內(nèi)的修改不會影響其它層	不是普適性的架構(gòu)； 某些場景下，需要跳過其中一些分層
CS模式	容易對系列服務(wù)進(jìn)行建模，供客戶端請求	請求通常是在服務(wù)器的不同線程中進(jìn)行響應(yīng)的； 因為不同客戶端有不同形式，進(jìn)程間通信會造成很大負(fù)載
主從模式	準(zhǔn)確性——服務(wù)的執(zhí)行委托給了不同的從模塊	從模塊是獨立的：沒有共享狀態(tài)； 主從模塊間的通信延遲可能是一個問題，尤其在實時系統(tǒng)中。
管道過濾器模式	支持并發(fā)處理，其中輸入、輸出由數(shù)據(jù)流組成時，過濾器在接收到數(shù)據(jù)時即開始計算； 容易添加過濾器，系統(tǒng)很容易擴展； 過濾器可重用，可以通過重新組合已有的過濾器來創(chuàng)建不同的管道流。	整體效率受最慢的過濾程序限制； 從一個過濾器傳遞到另一個時，存在數(shù)據(jù)轉(zhuǎn)換的負(fù)載
代理模式	允許對象進(jìn)行動態(tài)的修改、增、刪、重定位，對開發(fā)者來說內(nèi)容分發(fā)是透明的	需要對服務(wù)描述進(jìn)行標(biāo)準(zhǔn)化
P2P模式	支持去中心化運算； 對任意節(jié)點的失敗都有高度穩(wěn)定性； 在資源和計算能力方面具有高度可伸縮性	無法保證服務(wù)質(zhì)量，因為節(jié)點之間是自愿合作的； 很難保證安全； 性能取決于節(jié)點的數(shù)量
事件總線模式	很容易向系統(tǒng)好加入新的發(fā)布者、訂閱者和連接； 對于高度分布式應(yīng)用很有效	伸縮性可能是個難題，因為所有的信息傳輸都要通過相同的時間總線
MVC模式	對同一模型很容易構(gòu)建多個視圖，在運行時可以任意連接或斷開	增加了復(fù)雜性，用戶操作可能導(dǎo)致很多不必要的更新
黑板模式	容易添加新應(yīng)用； 很容易擴展數(shù)據(jù)空間中的結(jié)構(gòu)	修改數(shù)據(jù)空間的結(jié)構(gòu)很難，因為所有的應(yīng)用都會被影響； 可能需要同步機制和訪問控制
解釋器模式	可能支持高度動態(tài)化行為； 有利于終端用戶的可編程性； 增強了靈活性，因為替換一個解釋程序很容易	因為解釋型語言通常比編譯型語言要慢，因此性能可能是一個問題

（完）

作者：Vijini Mallawaarachchi
原文：https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
如果您覺得這篇文章對您有點用的話，麻煩您為本文來個四連：轉(zhuǎn)發(fā)分享、點贊、點在看、留言，因為這將是我寫作與分享更多優(yōu)質(zhì)文章的最強動力！
本公眾號全部博文已整理成一個目錄，請在公眾號后臺回復(fù)「m」獲取！
推薦閱讀：
1、程序員必知的 7 種軟件架構(gòu)模式
2、支付寶的架構(gòu)到底有多牛逼？
3、微信支付軟件架構(gòu)，這也太牛逼了！
4、今日頭條的技術(shù)架構(gòu)到底有多牛逼？
5、螞蟻金服的技術(shù)架構(gòu)到底有多牛逼？
6、一文讀懂「分布式架構(gòu)」
7、如何畫出一張合格的技術(shù)架構(gòu)圖？
8、如何畫出優(yōu)秀的架構(gòu)圖？
9、從 Nginx 優(yōu)秀的核心架構(gòu)設(shè)計，揭秘其為何能支持高并發(fā)？
10、就是要讓你搞懂Nginx，這篇就夠了！
關(guān)注微信公眾號「杰哥的IT之旅」，后臺回復(fù)「1024」查看更多內(nèi)容，回復(fù)「加群」備注：地區(qū)-職業(yè)方向-昵稱?即可加入讀者交流群。
點個[在看]，是對杰哥最大的支持！