幾種必知的軟體架構模式
架構模式是對給定上下文的軟體架構中常見問題的一種通用的可複用的解決方案。
一種模式就是特定上下文的問題的一種解決方案。
然而，很多開發者至今還對各種軟體架構模式之間的差別搞不清，甚至對其所知甚少。
大體上，主要有下面這幾種架構模式：
- 分層架構
- 管道 - 過濾器架構
- 客戶端 - 伺服器架構
- 模型 - 檢視 - 控制器架構
- 事件驅動架構
- 微服務架構
1、分層架構模式
最常見的架構模式就是分層架構或者稱為 n 層架構。
大部分軟體架構師、設計師和開發者都對這個架構模式非常熟悉。儘管對於層的數量和型別沒有具體限制，但大部分分層架構主要由四層組成：展現層、業務層、持久層和資料庫層，如下圖所示。
上下文
所有複雜的系統都會經歷獨立地發展和衍化系統各個部分的需要。出於這個原因，系統開發者需要對關注點進行清晰且條理分明的分離，以便系統的各個模組可以獨立地開發和維護。
問題
軟體需要以這樣一種方式分割：各個模組可以獨自開發和衍化，各自部分之間的互動非常少，支援可移植性、可修改性和複用性。
方案
為了實現關注點分離，分層模式將軟體分割成各個單元（稱為“層”）。每一層都是一組模組，提供了一組高內聚的服務。其使用必須是單向的。層將一組軟體作為一個完整的分割槽，每個分割槽暴露一個公開介面。
-
第一個概念是，每一層都有特定的角色和職責。例如，展現層負責處理所有的使用者介面。分層架構的這種關注點分離，讓構建高效的角色和職責非常簡單。
-
第二個概念是，分層架構模式是一個技術性的分割槽架構，而非一個領域性的分割槽架構。它們是由元件組成的，而不是領域。
-
最後一個概念是，分層架構中的每一層都被標記為封閉或者開放。封閉層意味著請求從一層移到另一層，它必須通過它正下面的這一層才能達到下面這一層的再下一層。請求不能跳過任何層。
弱點
分層會導致效能下降。這種模式不適合高效能應用程式，因為經過架構中的多層來實現一個業務請求的效率是不高的。
分層還會增加系統的前期成本和複雜性。
用途
我們應該將這種方式應用於小型簡單的應用程式或網站。對於預算和時間非常緊張的場景，這是一個不錯的選擇。
2、多層模式
方案
許多系統的執行結構被組織成一系列邏輯元件分組。每個分組被稱為一個層。
上下文
在一個分散式部署中，通常需要將系統的基礎設施分到不同的子集中。
問題
我們如何將系統分割到多個計算上獨立的執行結構：由一些通訊媒介連線的軟體和硬體組？
弱點
大量前期成本和複雜性。
用途
用在分散式系統中。
3、管道 - 過濾器架構
軟體架構中反覆出現的一種模式是管道 - 過濾器（pipe-filter）模式。
上下文
許多系統需要轉換從輸入到輸出的離散資料流。許多型別轉換在實踐中重複出現，因此將其建立成獨立的可複用的部分，這是比較理想的。
問題
這些系統需要被分割成可複用的鬆耦合的元件，元件之間擁有簡單通用的互動機制。這樣它們就可以靈活地相互結合。這些通用鬆耦合的元件就很容易複用。那些獨立的元件可以並行執行。
方案
這種架構中的管道構成了過濾器之間的通訊通道。第一個概念是，由於效能原因，每個管道都是非定向的和點對點的，接受來自一個源的輸入並經常直接輸出到另外一個源。
在這種模式中，有如下四種過濾器。
- producer（
source）：一個過程的起點。 - transformer (
map)：對一些或所有資料進行轉換。 - tester (
reduce)：測試一個或多個條件。 - consumer (
sink)：終點。
弱點
不太適合互動性的系統，因為它們的轉換特性。
過多的解析和反解析會導致效能損失，也會增加編寫過濾器本身的複雜性。
用途
管道 - 過濾器架構用於各種應用程式，特別是簡化單項處理的任務，例如 EDI、ETL 工具。
編譯器：連續的過濾器執行詞法分析、語法分析、語義分析和程式碼生成。
4、客戶端 - 伺服器架構
上下文
有許多共享資源和服務是大量分散式的客戶端希望訪問的，我們希望控制訪問或服務質量。
問題
通過管理一組共享資源和服務，我們可以通過分解公共服務並在單個位置或少數位置進行修改來提高可修改性和複用性。我們想要通過在將資源本身分佈在多個物理伺服器上的同時集中控制這些資源和服務，來提高可伸縮性和可用性。
方案
在客戶端 - 伺服器模式中，元件和聯結器具有特定的行為。
稱為“客戶端”的元件將請求傳送到稱為“伺服器”的元件，然後等待回覆。
伺服器元件接收到客戶端的請求並向其傳送回覆。
弱點
伺服器會成為效能瓶頸和單點故障位置。
在系統建成後，關於功能位置（在客戶端還是在伺服器）的決策通常是複雜的而且變動成本很大。
用途
對於有許多元件（客戶端）傳送請求到另外一些提供服務的元件（伺服器）的系統，我們可以使用客戶端 - 伺服器模式來建模這個系統的一部分：線上應用程式，例如電子郵件、共享文件或銀行服務。
5、模型 - 檢視 - 控制器架構（MVC）
上下文
使用者介面通常是一個互動性應用程式的最頻繁被修改的部分。使用者通常希望從不同的視角檢視資料，例如柱狀圖或者餅圖。這些表示形式都應該反映資料當前的狀態。
問題
使用者介面功能如何獨立於應用程式功能，同時還還對使用者輸入或底層應用程式資料的更改做出響應？
當底層應用程式資料更改時，如何建立、維護和協調使用者介面的多個檢視？
方案
模型 - 檢視 - 控制器（model-view-controller，即 MVC）模式將應用程式功能分為以下三種類型的元件：
- 模型，包含應用程式的資料。
- 檢視，顯示部分底層資料並與使用者互動。
- 控制器，在模型和檢視之間進行中介並管理狀態更改的通知。
弱點
對於簡單的使用者介面，其複雜性並不值得這麼做。
模型、檢視和控制器抽象可能不適用於某些使用者介面工具包。
用途
MVC 是網站或移動應用程式開發使用者介面常用的一種架構模式。
6、事件驅動架構
上下文
需要提供計算和資訊資源來處理傳入的應用程式生成的獨立非同步事件，這種方式可以隨著需求的增加而擴充套件。
問題
構建分散式系統，這個系統可以服務非同步到達的事件相關資訊，並且能從簡單小型擴充套件到複雜大型。
方案
為事件處理部署獨立的事件程序或處理器。到達的事件進入佇列。排程程式根據排程策略從佇列中拉取事件並將它們分配到合適的事件處理器。
弱點
效能和錯誤恢復可能是問題。
用途
使用這個方案的電商應用程式將工作如下：
Order Service 建立一個 Order，這個訂單處於待定狀態，然後釋出一個OrderCreated事件。
-
Customer Service 接收到這個事件並嘗試為這個 Order 扣除信用。然後釋出一個 Credit Reserved 事件或者
CreditLimitExceeded（超出信用限額）事件。 -
Order Service 接收到 Customer Service 傳送的事件並將訂單狀態更改為已核准或已取消。
7、微服務架構
上下文
部署基於伺服器的企業應用程式，支援各種瀏覽器和原生移動客戶端。應用程式通過執行業務邏輯、訪問資料庫、與其它系統交換資訊並返回響應來處理客戶端請求。這個應用程式可能會暴露一個第三方 API。
問題
一體化應用程式會變得過於龐大和複雜，無法得到有效支援和部署來實現最優的分散式資源利用，例如在雲環境中。
方案
將應用程式構建成服務套件。每個服務都是獨立部署和可擴充套件的，擁有自己的 API 邊界。不同的服務可以用不同的程式語言編寫，管理它們自己的資料庫，由不同的團隊開發。
弱點
系統設計必須能容忍服務失敗，需要更多的系統監控。服務編排和事件協作開銷比較大。
當然，我們還需要更多錢。
用途
許多使用場景都可以應用微服務架構，特別是那些涉及大量資料管道的場景。例如，一個微服務系統對關於一個公司的零售店銷售的報表系統會比較理想。資料展現過程的每一步都會被一個微服務處理：資料收集、清理、規範化、濃縮、聚合、報告等。