架構模式是在給定上下文中解決軟件架構中常見問題的通用，可重用的解決方案。

模式是上下文中問題的解決方案。

如今，許多程序員仍然對體系結構模式之間的差異感到困惑，甚至對此并不了解。

讓我向您解釋…!

• 分層架構
• 管道和過濾器
• 客戶端服務器
• 模型視圖控制器
• 事件驅動架構
• 微服務架構

分層架構

最常見的架構模式是分層架構或稱為n層架構。大多數軟件架構師，設計師，開發人員都廣為人知。盡管對于必須存在的層的數量和類型沒有特別的限制，但是大多數分層體系結構由四個層組成：表示，業務，持久性和數據庫，如下所示。

 

 

> an popular example of n-tier architecture

語境

所有復雜的系統都需要獨立開發和演化系統的各個部分。由于這個原因，系統的開發人員需要明確且有據可查的關注點分離，以便可以獨立開發和維護系統的模塊。

問題

需要對軟件進行分段，以便可以獨立開發和開發模塊，而各部分之間的交互很少，從而支持可移植性，可修改性和重用性。

解決方案

為了實現關注點的分離，分層模式將軟件分為稱為層的單元。每一層都是一組模塊，這些模塊提供了一套緊密的服務。用法必須是單向的。層完全對一組軟件進行分區，并且每個分區都通過公共接口公開。

• 第一個概念是每個層都有特定的角色和責任。例如，表示層將負責處理所有UI。因為分層架構內關注點的分離使建立有效的角色和責任變得容易。
• 在第二個概念上，分層體系結構模式是技術分區的體系結構，而不是域分區的體系結構。它們是組件組，而不是按域劃分。
• 最后一個概念是分層體系結構中的每個層都被標記為封閉或開放。封閉層意味著請求從一層移到另一層，它必須經過它下面的一層才能到達該層下面的下一層。該請求不能跳過任何層。 > Closed layers and request access

弱點

層會導致性能下降。該模式無法將其自身應用于高性能應用程序，因為遍歷體系結構的多個層來滿足業務請求效率不高。

層的增加還增加了系統的前期成本和復雜性。

用法

對于小型，簡單的應用程序或網站，我們應該使用此樣式。對于預算和時間緊迫的情況，這是一個不錯的選擇。

多層模式

語境

在分布式部署中，通常需要將系統的基礎結構分布到不同的子集中。

問題

我們如何將系統劃分為多個在計算上獨立的執行結構：通過某些通信介質連接的軟件和硬件組?

解決方案

 

 

> a multi-tier example — consumer website J2EE

許多系統的執行結構被組織為一組組件的邏輯分組。每個分組稱為一個層。

弱點

大量的前期成本和復雜性。

用法

用于分布式系統。

管道和過濾器

反復出現的軟件體系結構中的一種模式是管道過濾器模式。

 

 

> the pipe filter style

語境

需要許多系統從輸入到輸出轉換離散數據項的流。實際上，許多類型的轉換會重復發生，因此，需要將它們創建為獨立的，可重復使用的部分。

問題

此類系統需要分為具有簡單，通用交互機制的可重用，松散耦合的組件。這樣，它們可以靈活地彼此組合。通用且松散耦合的組件易于重用。獨立的組件可以并行執行。

解決方案

這種架構中的管道形成了過濾器之間的通信通道。第一個概念是每條管道都是無方向性的，并且出于性能原因是點對點的，接受來自一個源的輸入，并始終將輸出定向到另一個。

此樣式中存在四種類型的過濾器，如下所示。

• 生產者(來源)：過程的起點。
• 轉換器(映射)：對部分或全部數據執行轉換。
• 測試員(減少)：測試一個或多個條件。
• 消費者(接收者)：終點。

弱點

由于交互式系統的轉換特性，因此不是很好的選擇。

過多的解析和未解析會導致性能損失并增加編寫過濾器本身的復雜性。

用法

管道過濾器體系結構用于各種應用程序中，尤其是有助于簡單單向處理的任務，例如EDI，ETL工具。

編譯器：連續的過濾器執行詞法分析，解析，語義分析和代碼生成。

客戶端服務器

 

 

語境

有許多分布式客戶端希望訪問的共享資源和服務，我們希望對其進行控制，以控制訪問或服務質量。

問題

通過管理一組共享資源和服務，我們可以通過排除常見服務并必須在單個位置或少數位置中對它們進行修改來提高可修改性和重用性。我們希望通過集中控制這些資源和服務，同時在多個物理服務器之間分配資源本身來提高可伸縮性和可用性。

解決方案

在客戶端-服務器樣式中，組件和連接器具有特定的行為。

• 稱為“客戶端”的組件將請求發送到稱為“服務器”的組件，并等待答復。
• 服務器組件從客戶端接收請求，然后向其發送回復。

弱點

服務器可能是性能瓶頸和單點故障。

構建系統后，關于在何處定位功能(在客戶端還是在服務器中)的決策通常很復雜，更改成本很高。

用法

我們可以使用客戶端-服務器樣式來建模系統的一部分，該系統具有許多組件，這些組件將請求(客戶端)發送到另一個提供服務的組件(服務器)：在線應用程序，例如電子郵件，文檔共享和銀行業務。

模型視圖控制器 MVC

 

 

語境

用戶界面通常是交互式應用程序中最經常修改的部分。用戶通常希望從不同的角度查看數據，例如條形圖或餅圖。這些表示均應反映數據的當前狀態。

問題

如何將用戶界面功能與應用程序功能區分開，又如何對用戶輸入或底層應用程序數據的更改做出響應?

當基礎應用程序數據更改時，如何創建，維護和協調用戶界面的多個視圖?

解決方案

模型視圖控制器(MVC)模式將應用程序功能分為以下三種組件。

• 一個模型，其中包含應用程序的數據。
• 視圖，顯示基礎數據的某些部分并與用戶進行交互。
• 控制器，它在模型和視圖之間進行中介，并管理狀態更改的通知。

弱點

對于簡單的用戶界面，復雜性可能不值得。

模型，視圖和控制器的抽象可能不適用于某些用戶界面工具箱。

用法

MVC是一種架構模式，通常在開發用戶界面時用于Web移動應用程序。

事件驅動架構

語境

需要提供計算和信息資源來處理傳入的獨立異步應用程序生成的事件，其方式可以隨需求的增加而擴展。

問題

構建可以為與事件關聯的異步到達消息提供服務的分布式系統，并且該分布式系統可以從小型和簡單擴展到大型和復雜。

解決方案

 

 

部署獨立的事件流程/處理器以進行事件處理。到達事件排隊。調度程序從隊列中提取事件，并根據調度策略將它們分配給適當的事件處理程序。

弱點

性能和錯誤恢復可能是個問題。

用法

使用此方法的電子商務應用程序將按以下方式工作：訂單服務以掛起狀態創建訂單并發布OrderCreated事件。

• 客戶服務收到事件并嘗試為該訂單保留信用。然后，它發布“保留信用”事件或“ CreditLimitExceeded”事件。
• 訂單服務從客戶服務接收事件，并將訂單狀態更改為已批準或已取消

微服務架構

語境

部署支持多種瀏覽器和本機移動客戶端的基于服務器的企業應用程序。該應用程序通過執行業務邏輯，訪問數據庫，與其他系統交換消息并返回響應來處理客戶端請求。該應用程序可能會公開一個第三方API。

問題

整體應用程序可能變得太大和復雜，以致于無法有效支持，而部署則無法實現最佳的分布式資源利用，例如在云環境中。

解決方案

 

 

將應用程序構建為服務套件。每個服務都可以獨立部署和擴展，并具有自己的API邊界。可以用不同的編程語言編寫不同的服務，管理自己的數據庫，并由不同的團隊開發。

弱點

系統必須設計為能夠承受需要更多系統監視的服務故障。服務編排和事件協作開銷。

我們還需要更多的內存。

用法

許多用例適用于微服務架構，尤其是那些涉及大量數據管道的用例。例如，基于微服務的系統非常適合公司零售商店銷售的報告系統。數據準備過程的每個步驟都將由微服務處理：數據收集，清理，規范化，充實，匯總，報告等。