想知道如何設計大型企業級的系統嗎？在開始主要的代碼開發之前，我們必須選擇一種合适的體系架構，它将為我們提供所需的功能和品質屬性。是以，在将它們應用到我們的設計之前，應該先了解不同的體系結構。
- 什麼是架構模式 -
根據維基百科，
架構模式是在給定上下文中解決軟體架構中常見問題的通用、可重用的解決方案。架構模式類似于軟體設計模式，但範圍更廣。
在本文中，我會簡單介紹下列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模式 -
該模式将互動式應用分為三個部分，
- 模型——包含核心功能和資料
- 視圖——向使用者顯示資訊（可以定義多個視圖）
- 控制器——處理使用者的輸入
這樣做是為了将資料的内部表示與使用者輸入和向使用者展示的形式分離開來，這樣可以解耦元件，同時也可以進行高效的代碼重用。
應用
- 主流程式設計語言的網際網路應用架構
- 網絡架構，如Django 和 Rails.
- 黑闆模式 -
此模式對于尚無确定性解決方案的問題很有用，黑闆模式由三部分組成：
- 黑闆—— 一個結構化的全局記憶體，包含解決方案領域的對象
- 知識源——具有自身含義的專業子產品
- 控制元件——選擇、配置和執行子產品
所有元件都可以通路黑闆，元件可能會産生要添加到黑闆中的新資料對象，元件在黑闆上尋找特定類型的資料，并且可以通過與現有知識源進行模式比對來找到這些資料。
應用
- 語音識别
- 車輛識别與跟蹤
- 蛋白質結構鑒定
- 聲呐信号解釋
- 解釋器模式 -
此模式通常用于設計元件來解釋使用專用語言寫出的程式，它主要指定如何估算程式行，即以特定語言編寫的語句或表達式。基本思想是為每種語言符号都設計一個類。
應用
- 資料庫查詢語言，如SQL
- 用于描述通信協定的語言
- 架構模式對比 -
| 模式 | 優點 | 缺點 |
| 分層模式 | 一個底層服務可以被不同的高層服務使用；分層結果更容易進行标準化，因為可以清晰地定義每個層級層級内的修改不會影響其它層 | 不是普适性的架構；某些場景下，需要跳過其中一些分層 |
| CS模式 | 容易對系列服務進行模組化，供用戶端請求 | 請求通常是在伺服器的不同線程中進行響應的；因為不同用戶端有不同形式，程序間通信會造成很大負載 |
| 主從模式 | 準确性——服務的執行委托給了不同的從子產品 | 從子產品是獨立的：沒有共享狀态；主從子產品間的通信延遲可能是一個問題，尤其在實時系統中。 |
| 管道過濾器模式 | 支援并發處理，其中輸入、輸出由資料流組成時，過濾器在接收到資料時即開始計算；容易添加過濾器，系統很容易擴充；過濾器可重用，可以通過重新組合已有的過濾器來建立不同的管道流。 | 整體效率受最慢的過濾程式限制；從一個過濾器傳遞到另一個時，存在資料轉換的負載 |
| 代理模式 | 允許對象進行動态的修改、增、删、重定位，對開發者來說内容分發是透明的 | 需要對服務描述進行标準化 |
| P2P模式 | 支援去中心化運算；對任意節點的失敗都有高度穩定性；在資源和計算能力方面具有高度可伸縮性 | 無法保證服務品質，因為節點之間是自願合作的；很難保證安全；性能取決于節點的數量 |
| 事件總線模式 | 很容易向系統好加入新的釋出者、訂閱者和連接配接；對于高度分布式應用很有效 | 伸縮性可能是個難題，因為所有的資訊傳輸都要通過相同的時間總線 |
| MVC模式 | 對同一模型很容易建構多個視圖，在運作時可以任意連接配接或斷開 | 增加了複雜性，使用者操作可能導緻很多不必要的更新 |
| 黑闆模式 | 容易添加新應用；很容易擴充資料空間中的結構 | 修改資料空間的結構很難，因為所有的應用都會被影響；可能需要同步機制和通路控制 |
| 解釋器模式 | 可能支援高度動态化行為；有利于終端使用者的可程式設計性；增強了靈活性，因為替換一個解釋程式很容易 | 因為解釋型語言通常比編譯型語言要慢，是以性能可能是一個問題 |