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

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

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

讓我向您解釋…!

• 分層架構(gòu)
• 管道和過濾器
• 客戶端服務(wù)器
• 模型視圖控制器
• 事件驅(qū)動架構(gòu)
• 微服務(wù)架構(gòu)

分層架構(gòu)

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

 

 

> an popular example of n-tier architecture

語境

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

問題

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

解決方案

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

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

弱點

層會導(dǎo)致性能下降。該模式無法將其自身應(yīng)用于高性能應(yīng)用程序，因為遍歷體系結(jié)構(gòu)的多個層來滿足業(yè)務(wù)請求效率不高。

層的增加還增加了系統(tǒng)的前期成本和復(fù)雜性。

用法

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

多層模式

語境

在分布式部署中，通常需要將系統(tǒng)的基礎(chǔ)結(jié)構(gòu)分布到不同的子集中。

問題

我們?nèi)绾螌⑾到y(tǒng)劃分為多個在計算上獨立的執(zhí)行結(jié)構(gòu)：通過某些通信介質(zhì)連接的軟件和硬件組?

解決方案

 

 

> a multi-tier example — consumer website J2EE

許多系統(tǒng)的執(zhí)行結(jié)構(gòu)被組織為一組組件的邏輯分組。每個分組稱為一個層。

弱點

大量的前期成本和復(fù)雜性。

用法

用于分布式系統(tǒng)。

管道和過濾器

反復(fù)出現(xiàn)的軟件體系結(jié)構(gòu)中的一種模式是管道過濾器模式。

 

 

> the pipe filter style

語境

需要許多系統(tǒng)從輸入到輸出轉(zhuǎn)換離散數(shù)據(jù)項的流。實際上，許多類型的轉(zhuǎn)換會重復(fù)發(fā)生，因此，需要將它們創(chuàng)建為獨立的，可重復(fù)使用的部分。

問題

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

解決方案

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

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

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

弱點

由于交互式系統(tǒng)的轉(zhuǎn)換特性，因此不是很好的選擇。

過多的解析和未解析會導(dǎo)致性能損失并增加編寫過濾器本身的復(fù)雜性。

用法

管道過濾器體系結(jié)構(gòu)用于各種應(yīng)用程序中，尤其是有助于簡單單向處理的任務(wù)，例如EDI，ETL工具。

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

客戶端服務(wù)器

 

 

語境

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

問題

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

解決方案

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

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

弱點

服務(wù)器可能是性能瓶頸和單點故障。

構(gòu)建系統(tǒng)后，關(guān)于在何處定位功能(在客戶端還是在服務(wù)器中)的決策通常很復(fù)雜，更改成本很高。

用法

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

模型視圖控制器 MVC

 

 

語境

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

問題

如何將用戶界面功能與應(yīng)用程序功能區(qū)分開，又如何對用戶輸入或底層應(yīng)用程序數(shù)據(jù)的更改做出響應(yīng)?

當基礎(chǔ)應(yīng)用程序數(shù)據(jù)更改時，如何創(chuàng)建，維護和協(xié)調(diào)用戶界面的多個視圖?

解決方案

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

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

弱點

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

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

用法

MVC是一種架構(gòu)模式，通常在開發(fā)用戶界面時用于Web移動應(yīng)用程序。

事件驅(qū)動架構(gòu)

語境

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

問題

構(gòu)建可以為與事件關(guān)聯(lián)的異步到達消息提供服務(wù)的分布式系統(tǒng)，并且該分布式系統(tǒng)可以從小型和簡單擴展到大型和復(fù)雜。

解決方案

 

 

部署獨立的事件流程/處理器以進行事件處理。到達事件排隊。調(diào)度程序從隊列中提取事件，并根據(jù)調(diào)度策略將它們分配給適當?shù)氖录幚沓绦颉?/p>

弱點

性能和錯誤恢復(fù)可能是個問題。

用法

使用此方法的電子商務(wù)應(yīng)用程序?qū)匆韵路绞焦ぷ鳎河唵畏?wù)以掛起狀態(tài)創(chuàng)建訂單并發(fā)布OrderCreated事件。

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

微服務(wù)架構(gòu)

語境

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

問題

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

解決方案

 

 

將應(yīng)用程序構(gòu)建為服務(wù)套件。每個服務(wù)都可以獨立部署和擴展，并具有自己的API邊界?？梢杂貌煌木幊陶Z言編寫不同的服務(wù)，管理自己的數(shù)據(jù)庫，并由不同的團隊開發(fā)。

弱點

系統(tǒng)必須設(shè)計為能夠承受需要更多系統(tǒng)監(jiān)視的服務(wù)故障。服務(wù)編排和事件協(xié)作開銷。

我們還需要更多的內(nèi)存。

用法

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