收藏:軟件設(shè)計(jì)的7種架構(gòu)模式
架構(gòu)模式是對給定上下文的軟件架構(gòu)中常見問題的一種通用的可復(fù)用的解決方案。一種模式就是特定上下文的問題的一種解決方案。
然而，很多開發(fā)者至今還對各種軟件架構(gòu)模式之間的差別搞不清，甚至對其所知甚少。
大體上，主要有下面這7種架構(gòu)模式：
分層架構(gòu)
多層架構(gòu)
管道/過濾器架構(gòu)
客戶端/服務(wù)器架構(gòu)
模型/視圖/控制器架構(gòu)
事件驅(qū)動(dòng)架構(gòu)
微服務(wù)架構(gòu)
1分層架構(gòu)模式
最常見的架構(gòu)模式就是分層架構(gòu)或者稱為 n 層架構(gòu)。
大部分軟件架構(gòu)師、設(shè)計(jì)師和開發(fā)者都對這個(gè)架構(gòu)模式非常熟悉。盡管對于層的數(shù)量和類型沒有具體限制，但大部分分層架構(gòu)主要由四層組成：展現(xiàn)層、業(yè)務(wù)層、持久層和數(shù)據(jù)庫層，如下圖所示。
一個(gè)很流行的 n 層架構(gòu)示例
?1?上下文?
所有復(fù)雜的系統(tǒng)都會(huì)經(jīng)歷獨(dú)立地發(fā)展和衍化系統(tǒng)各個(gè)部分的需要。出于這個(gè)原因，系統(tǒng)開發(fā)者需要對關(guān)注點(diǎn)進(jìn)行清晰且條理分明的分離，以便系統(tǒng)的各個(gè)模塊可以獨(dú)立地開發(fā)和維護(hù)。
?2?問題?
軟件需要以這樣一種方式分割：各個(gè)模塊可以獨(dú)自開發(fā)和衍化，各自部分之間的交互非常少，支持可移植性、可修改性和復(fù)用性。
?3?方案?
為了實(shí)現(xiàn)關(guān)注點(diǎn)分離，分層模式將軟件分割成各個(gè)單元（稱為“層”）。每一層都是一組模塊，提供了一組高內(nèi)聚的服務(wù)。其使用必須是單向的。層將一組軟件作為一個(gè)完整的分區(qū)，每個(gè)分區(qū)暴露一個(gè)公開接口。
第一個(gè)概念是，每一層都有特定的角色和職責(zé)。例如，展現(xiàn)層負(fù)責(zé)處理所有的用戶界面。分層架構(gòu)的這種關(guān)注點(diǎn)分離，讓構(gòu)建高效的角色和職責(zé)非常簡單。
第二個(gè)概念是，分層架構(gòu)模式是一個(gè)技術(shù)性的分區(qū)架構(gòu)，而非一個(gè)領(lǐng)域性的分區(qū)架構(gòu)。它們是由組件組成的，而不是領(lǐng)域。
最后一個(gè)概念是，分層架構(gòu)中的每一層都被標(biāo)記為封閉或者開放。封閉層意味著請求從一層移到另一層，它必須通過它正下面的這一層才能達(dá)到下面這一層的再下一層。請求不能跳過任何層。
封閉層和請求訪問
?4?弱點(diǎn)?
分層會(huì)導(dǎo)致性能下降。這種模式不適合高性能應(yīng)用程序，因?yàn)榻?jīng)過架構(gòu)中的多層來實(shí)現(xiàn)一個(gè)業(yè)務(wù)請求的效率是不高的。
分層還會(huì)增加系統(tǒng)的前期成本和復(fù)雜性。
?5?用途?
我們應(yīng)該將這種方式應(yīng)用于小型簡單的應(yīng)用程序或網(wǎng)站。對于預(yù)算和時(shí)間非常緊張的場景，這是一個(gè)不錯(cuò)的選擇。
2多層模式
?1?方案?
一個(gè)多層模式示例：消費(fèi)者網(wǎng)站 J2EE
許多系統(tǒng)的執(zhí)行結(jié)構(gòu)被組織成一系列邏輯組件分組。每個(gè)分組被稱為一個(gè)層。
?1?上下文?
在一個(gè)分布式部署中，通常需要將系統(tǒng)的基礎(chǔ)設(shè)施分到不同的子集中。
?2?問題?
我們?nèi)绾螌⑾到y(tǒng)分割到多個(gè)計(jì)算上獨(dú)立的執(zhí)行結(jié)構(gòu)：由一些通信媒介連接的軟件和硬件組？
?3?弱點(diǎn)?
大量前期成本和復(fù)雜性。
?4?用途?
用在分布式系統(tǒng)中。
3管道、過濾器架構(gòu)
軟件架構(gòu)中反復(fù)出現(xiàn)的一種模式是管道 - 過濾器（pipe-filter）模式。
管道過濾器模式
?1?上下文?
許多系統(tǒng)需要轉(zhuǎn)換從輸入到輸出的離散數(shù)據(jù)流。許多類型轉(zhuǎn)換在實(shí)踐中重復(fù)出現(xiàn)，因此將其創(chuàng)建成獨(dú)立的可復(fù)用的部分，這是比較理想的。
?2?問題?
這些系統(tǒng)需要被分割成可復(fù)用的松耦合的組件，組件之間擁有簡單通用的交互機(jī)制。這樣它們就可以靈活地相互結(jié)合。這些通用松耦合的組件就很容易復(fù)用。那些獨(dú)立的組件可以并行執(zhí)行。
?3?方案?
這種架構(gòu)中的管道構(gòu)成了過濾器之間的通信通道。第一個(gè)概念是，由于性能原因，每個(gè)管道都是非定向的和點(diǎn)對點(diǎn)的，接受來自一個(gè)源的輸入并經(jīng)常直接輸出到另外一個(gè)源。
在這種模式中，有如下四種過濾器。
producer（source）：一個(gè)過程的起點(diǎn)。
transformer (map)：對一些或所有數(shù)據(jù)進(jìn)行轉(zhuǎn)換。
tester (reduce)：測試一個(gè)或多個(gè)條件。
consumer (sink)：終點(diǎn)。
?4?弱點(diǎn)?
不太適合交互性的系統(tǒng)，因?yàn)樗鼈兊霓D(zhuǎn)換特性。
過多的解析和反解析會(huì)導(dǎo)致性能損失，也會(huì)增加編寫過濾器本身的復(fù)雜性。
?5?用途?
管道 - 過濾器架構(gòu)用于各種應(yīng)用程序，特別是簡化單項(xiàng)處理的任務(wù)，例如 EDI、ETL 工具。
編譯器：連續(xù)的過濾器執(zhí)行詞法分析、語法分析、語義分析和代碼生成。
4客戶端、過濾器架構(gòu)
?1?上下文?
有許多共享資源和服務(wù)是大量分布式的客戶端希望訪問的，我們希望控制訪問或服務(wù)質(zhì)量。
?2?問題?
通過管理一組共享資源和服務(wù)，我們可以通過分解公共服務(wù)并在單個(gè)位置或少數(shù)位置進(jìn)行修改來提高可修改性和復(fù)用性。我們想要通過在將資源本身分布在多個(gè)物理服務(wù)器上的同時(shí)集中控制這些資源和服務(wù)，來提高可伸縮性和可用性。
?3?方案?
在客戶端 - 服務(wù)器模式中，組件和連接器具有特定的行為。
稱為“客戶端”的組件將請求發(fā)送到稱為“服務(wù)器”的組件，然后等待回復(fù)。
服務(wù)器組件接收到客戶端的請求并向其發(fā)送回復(fù)。
?4?弱點(diǎn)?
服務(wù)器會(huì)成為性能瓶頸和單點(diǎn)故障位置。
在系統(tǒng)建成后，關(guān)于功能位置（在客戶端還是在服務(wù)器）的決策通常是復(fù)雜的而且變動(dòng)成本很大。
?5?用途?
對于有許多組件（客戶端）發(fā)送請求到另外一些提供服務(wù)的組件（服務(wù)器）的系統(tǒng)，我們可以使用客戶端 - 服務(wù)器模式來建模這個(gè)系統(tǒng)的一部分：在線應(yīng)用程序，例如電子郵件、共享文檔或銀行服務(wù)。
5模型、視圖、控制器架構(gòu)（MVC）
?1?上下文?
用戶界面通常是一個(gè)交互性應(yīng)用程序的最頻繁被修改的部分。用戶通常希望從不同的視角查看數(shù)據(jù)，例如柱狀圖或者餅圖。這些表示形式都應(yīng)該反映數(shù)據(jù)當(dāng)前的狀態(tài)。
?2?問題?
用戶界面功能如何獨(dú)立于應(yīng)用程序功能，同時(shí)還還對用戶輸入或底層應(yīng)用程序數(shù)據(jù)的更改做出響應(yīng)？
當(dāng)?shù)讓討?yīng)用程序數(shù)據(jù)更改時(shí)，如何創(chuàng)建、維護(hù)和協(xié)調(diào)用戶界面的多個(gè)視圖？
?3?方案?
模型 - 視圖 - 控制器（model-view-controller，即 MVC）模式將應(yīng)用程序功能分為以下三種類型的組件：
模型，包含應(yīng)用程序的數(shù)據(jù)。
視圖，顯示部分底層數(shù)據(jù)并與用戶交互。
控制器，在模型和視圖之間進(jìn)行中介并管理狀態(tài)更改的通知。
?4?弱點(diǎn)?
對于簡單的用戶界面，其復(fù)雜性并不值得這么做。
模型、視圖和控制器抽象可能不適用于某些用戶界面工具包。
?5?用途?
MVC 是網(wǎng)站或移動(dòng)應(yīng)用程序開發(fā)用戶界面常用的一種架構(gòu)模式。
6事件驅(qū)動(dòng)架構(gòu)
?1?上下文?
需要提供計(jì)算和信息資源來處理傳入的應(yīng)用程序生成的獨(dú)立異步事件，這種方式可以隨著需求的增加而擴(kuò)展。
?2?問題?
構(gòu)建分布式系統(tǒng)，這個(gè)系統(tǒng)可以服務(wù)異步到達(dá)的事件相關(guān)信息，并且能從簡單小型擴(kuò)展到復(fù)雜大型。
?3?方案?
為事件處理部署獨(dú)立的事件進(jìn)程或處理器。到達(dá)的事件進(jìn)入隊(duì)列。調(diào)度程序根據(jù)調(diào)度策略從隊(duì)列中拉取事件并將它們分配到合適的事件處理器。
?4?弱點(diǎn)?
性能和錯(cuò)誤恢復(fù)可能是問題。
?5?用途?
使用這個(gè)方案的電商應(yīng)用程序?qū)⒐ぷ魅缦拢?/span>
Order Service 創(chuàng)建一個(gè) Order，這個(gè)訂單處于待定狀態(tài)，然后發(fā)布一個(gè)OrderCreated事件。
Customer Service 接收到這個(gè)事件并嘗試為這個(gè) Order 扣除信用。然后發(fā)布一個(gè) Credit Reserved 事件或者
CreditLimitExceeded（超出信用限額）事件。Order Service 接收到 Customer Service 發(fā)送的事件并將訂單狀態(tài)更改為已核準(zhǔn)或已取消。
7微服務(wù)架構(gòu)
?1?上下文?
部署基于服務(wù)器的企業(yè)應(yīng)用程序，支持各種瀏覽器和原生移動(dòng)客戶端。應(yīng)用程序通過執(zhí)行業(yè)務(wù)邏輯、訪問數(shù)據(jù)庫、與其它系統(tǒng)交換信息并返回響應(yīng)來處理客戶端請求。這個(gè)應(yīng)用程序可能會(huì)暴露一個(gè)第三方 API。
?2?問題?
一體化應(yīng)用程序會(huì)變得過于龐大和復(fù)雜，無法得到有效支持和部署來實(shí)現(xiàn)最優(yōu)的分布式資源利用，例如在云環(huán)境中。
?3?方案?
將應(yīng)用程序構(gòu)建成服務(wù)套件。每個(gè)服務(wù)都是獨(dú)立部署和可擴(kuò)展的，擁有自己的 API 邊界。不同的服務(wù)可以用不同的編程語言編寫，管理它們自己的數(shù)據(jù)庫，由不同的團(tuán)隊(duì)開發(fā)。
?4?弱點(diǎn)?
系統(tǒng)設(shè)計(jì)必須能容忍服務(wù)失敗，需要更多的系統(tǒng)監(jiān)控。服務(wù)編排和事件協(xié)作開銷比較大。
當(dāng)然，我們還需要更多錢。
?5?用途?
許多使用場景都可以應(yīng)用微服務(wù)架構(gòu)，特別是那些涉及大量數(shù)據(jù)管道的場景。例如，一個(gè)微服務(wù)系統(tǒng)對關(guān)于一個(gè)公司的零售店銷售的報(bào)表系統(tǒng)會(huì)比較理想。數(shù)據(jù)展現(xiàn)過程的每一步都會(huì)被一個(gè)微服務(wù)處理：數(shù)據(jù)收集、清理、規(guī)范化、濃縮、聚合、報(bào)告等。
轉(zhuǎn)載申明：轉(zhuǎn)載本號文章請注明作者和來源，本號發(fā)布文章若存在版權(quán)等問題，請留言聯(lián)系處理，謝謝。
推薦閱讀
更多架構(gòu)相關(guān)技術(shù)知識總結(jié)請參考“架構(gòu)師全店鋪技術(shù)資料打包”相關(guān)電子書(37本技術(shù)資料打包匯總詳情可通過“閱讀原文”獲取)。
全店內(nèi)容持續(xù)更新，現(xiàn)下單“全店鋪技術(shù)資料打包(全)”，后續(xù)可享全店內(nèi)容更新“免費(fèi)”贈(zèng)閱，價(jià)格僅收198元(原總價(jià)350元)。
溫馨提示：
掃描二維碼關(guān)注公眾號，點(diǎn)擊閱讀原文鏈接獲取“架構(gòu)師技術(shù)全店資料打包匯總(全)”電子書資料詳情。
