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

模式是上下文中問(wèn)題的解決方案。

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

讓我向您解釋…!

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

分層架構(gòu)

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

 

 

> an popular example of n-tier architecture

語(yǔ)境

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

問(wèn)題

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

解決方案

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

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

弱點(diǎn)

層會(huì)導(dǎo)致性能下降。該模式無(wú)法將其自身應(yīng)用于高性能應(yīng)用程序，因?yàn)楸闅v體系結(jié)構(gòu)的多個(gè)層來(lái)滿足業(yè)務(wù)請(qǐng)求效率不高。

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

用法

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

多層模式

語(yǔ)境

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

問(wèn)題

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

解決方案

 

 

> a multi-tier example — consumer website J2EE

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

弱點(diǎn)

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

用法

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

管道和過(guò)濾器

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

 

 

> the pipe filter style

語(yǔ)境

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

問(wèn)題

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

解決方案

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

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

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

弱點(diǎn)

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

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

用法

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

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

客戶端服務(wù)器

 

 

語(yǔ)境

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

問(wèn)題

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

解決方案

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

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

弱點(diǎn)

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

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

用法

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

模型視圖控制器 MVC

 

 

語(yǔ)境

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

問(wèn)題

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

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

解決方案

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

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

弱點(diǎn)

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

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

用法

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

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

語(yǔ)境

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

問(wèn)題

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

解決方案

 

 

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

弱點(diǎn)

性能和錯(cuò)誤恢復(fù)可能是個(gè)問(wèn)題。

用法

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

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

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

語(yǔ)境

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

問(wèn)題

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

解決方案

 

 

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

弱點(diǎn)

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

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

用法

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