- 相關推薦
系統(tǒng)架構設計模式大全
目前系統(tǒng)架構大約有110多種設計模式，模式不是教條，模式僅僅是經(jīng)驗的總結，下面小編為大家整理了一些系統(tǒng)架構設計模式，一起來看看吧：
Domain Model：定義了一個應用領域結構和工作流的精確模型，其中還包括它們的變化。
Layers：解決系統(tǒng)合理分層的問題。
Model-View-Controller：解決對用戶界面變化的支持問題。支持某一特定用戶界面的變化。
Presentation-Abstraction-Control：解決相同業(yè)務具有多種表現(xiàn)形式問題。
Microkernel：解決業(yè)務具有多種不同業(yè)務方法的問題。
Refelection：解決需要動態(tài)改變軟件系統(tǒng)結構和行為的問題。
Pipes and Filters：解決算法的結構化并可以重新構建的問題。
Shared Repository：適用于網(wǎng)絡管理和控制系統(tǒng)領域。
Blackboard：解決運行中智能化改進處理方法的問題。
Domain Object：表現(xiàn)為已經(jīng)將自我完備的連貫功能和基礎性責任封裝成定義良好的實體，通過一個或多個”顯示接口”提供功能，并隱藏內部結構和實現(xiàn)。
Messaging：由一系列相互連接的MessageChannel和Message Router管理著跨網(wǎng)絡的不同服務間的消息交換。
Message Channel：解決如何把彼此協(xié)作的客戶端和服務連接起來的問題。
Message Router：解決如何根據(jù)條件接受”信道”消息的問題。
Message Translator：解決如何轉換消息格式的問題。
Message Endpoint：解決把數(shù)據(jù)轉換為消息中間件能夠理解的形式的問題。
Publisher-Subscriber：為了在應用中更好的把彼此關注的事件通知給其它領域對象。
Broker：通過一個代理管理器管理領域對象間遠程互操作的各個關鍵方面。
Client Proxy：解決客戶端應用與網(wǎng)絡基礎設施相互屏蔽的問題。
Requestor：解決應用代碼被基礎設施的代碼污染而影響可移植性的問題。
Invoker：解決服務代碼被基礎設施的代碼污染而影響可移植性的問題。
Client Request Handler：解決客戶端應用與通信相互影響的問題，它封裝了客戶端在統(tǒng)一的接口背后進行的進程間通信的細節(jié)。
Server Request Handler：解決服務端應用與通信相互影響的問題，封裝了服務器端在統(tǒng)一的接口背后進行的進程間通信的細節(jié)。
Reactor：解決在應用中避免使用多線程的問題。
Proactor：解決在多線程的背景下出現(xiàn)性能問題的缺陷。
Acceptor-Connector：把事件初始化與具體處理方法分離，從而提高可維護性。
Asynchronous Completion Token：解決異步到達的事件仍然能按一定順序處理的問題。
Explicit Interface：解決如何正確設計接口的問題。
Extension Interface：隨著時間的推移，組件的接口是會膨脹的，一個胖的接口將更脆弱。解決防止”胖”接口并分離接口。
Introspective Interface：解決公開內部信息接口的問題。
Dynamic Invocation Interface：解決同一個接口允許客戶端調用多種方法的問題。
Proxy：解決在同一個接口下通過代理屏蔽某些實現(xiàn)的問題。
Business Delegate：由本地業(yè)務代表來完成所有網(wǎng)絡任務，分離了應用和網(wǎng)絡處理的業(yè)務，減少了開發(fā)難度、提高了可理解性和可維護性。
Facade：解決屏蔽子系統(tǒng)的變化輻射到高層應用的問題。
Combined Method：解決多種相互關聯(lián)的方法不合理的分布的問題。
Iterator：解決分布式元素能夠方便迭代的問題。
Enumeration Method：解決減少外部迭代方式多次對聚合中的元素進行獨立訪問開銷的問題。
Batch Method：解決多次訪問加大網(wǎng)絡開銷的問題。
Encapsulated Implementation：解決對象劃分的基本原則和方法問題。
Composite：建立一種結構靈活的樹狀結構對象組織形式，形成“整體/部分”層級結構。
Half-Object plus Protocol：通過在分布式系統(tǒng)中合理布局對象，以減少不合理的網(wǎng)絡流量和服務器壓力。
Replicated Component Group：解決分布式系統(tǒng)容錯的問題，復制的組件實現(xiàn)位于不同的網(wǎng)絡節(jié)點，并組成一個組件組。
Half-Sync/Half-Async：對并發(fā)系統(tǒng)中的異步和同步服務處理解耦合以簡化編程，但又不會過度地影響性能。
Leader/Followers：解決大批量小處理的環(huán)境下減少并發(fā)線程應用的問題。
Active Object：為了減少服務器并發(fā)線程應用。
Monitor Object：解決并發(fā)業(yè)務相互協(xié)調的問題。
Guarded Suspension：在并發(fā)性程序中，當某個線程對一個資源進行訪問的時候，首先需要判斷這個資源的警戒條件是否成立。
Future：并發(fā)調用的服務可能需要向客戶端返回結果。
Thread-Safe Interface：避免自死鎖和加鎖開銷。
Strategized Locking：在創(chuàng)建或聲明時，為組件配置適當類型的鎖實例。使用該鎖實例來保護組件中的所有臨界區(qū)。
Scoped Locking：解決復雜繁瑣代碼中的疏忽發(fā)生漏釋放造成死鎖的問題。
Thread-Specific Storage：解決頻繁使用對象造成反復加鎖解鎖造成的性能問題。
Copied Value：解決共享的值對象必須鎖定帶來的性能問題。
Immutable Value：解決共享的值對象必須鎖定帶來的性能問題。
Observer：定義一個特定的更新接口，通過該接口，Observer獲得Subject狀態(tài)變更的通知。
Double Dispatch：根據(jù)運行時多個對象的類型確定方法調用的過程。
Mediator：封裝集合中所有對象的聚合協(xié)作行為，從而將這些對象解耦合。
Command：為這些對象定義一個通用接口，來執(zhí)行它們所代表的請求。
Memento：解決在不破壞封裝性的前提下正確存儲和讀取分布式對象狀態(tài)的問題。
Context Object：解決在松耦合系統(tǒng)中共享與程序執(zhí)行上下文相關的通用信息的問題。
Data Transfer Object：解決細粒度調用多次訪問遠程對象單個屬性所帶來的巨大開銷問題。
Message：解決網(wǎng)絡協(xié)議只支持比特流這種最簡單的數(shù)據(jù)傳輸形式，并不能識別服務調用和數(shù)據(jù)類型的問題。
Bridge：解決在下層穩(wěn)定的業(yè)務中嵌入上次變化部分的問題。
Object Adapter：解決接口變化導致的不兼容問題。
Chain of Responsibility：解決對象結構和請求分發(fā)邏輯上的變化影響到客戶端的問題。
Interceptor：解決構建一個可插拔的框架變化模型的問題。
Visitor：解決將服務的實現(xiàn)分散在定義對象結構的各個類中難以進行集中處理的問題。
Decorator：解決在穩(wěn)定的核心功能外圍添加擴展的問題。
Template Method：解決在下層穩(wěn)定的業(yè)務中嵌入上次變化部分的問題。
Strategy：解決在一個或多個方法中根據(jù)不同的情況執(zhí)行不同行為的問題。
Wrapper Facade：主要解決應用代碼使用底層API所提供的服務但代碼難以理解的問題，需要對底層API進行面向對象的封裝，通過提供一個簡潔的、健壯的、可移植的、內聚的面向對象的接口，來達到封裝函數(shù)和數(shù)據(jù)的目的。
Declarative Component Configuration：建立需要安裝各類插件的宿主基礎設施，使其能夠正確管理運行時環(huán)境，可靠運用系統(tǒng)資源和服務的問題。
Container：解決領域對象直接處理平臺環(huán)境造成它與平臺緊密耦合并增加實現(xiàn)的復雜性的問題。
Component Configurator：解決在組件生命周期后期和升級時重新配置組件的問題。
Object Manager：解決客戶端依賴對象管理增加應用內部的耦合度和復雜度的問題。
Virtual Proxy：解決從一個巨大數(shù)據(jù)庫中把所有的對象全部加載進來消耗大量資源的問題。
Resource Pool：解決獲取和釋放資源(網(wǎng)絡連接、線程或者內容)引入一定的性能開銷問題。
Resource Cache：解決幾個有限的資源用戶頻繁創(chuàng)建和釋放資源帶來不必要的性能開銷問題。
Automated Garbage Collection：解決不能及時將不再使用的內存收回可能耗盡內存的問題。
Counting Handles：解決確保在堆上創(chuàng)建的共享對象能夠可靠地、安全地、及時地回收的問題。
Abstract Factory：解決一批對象用統(tǒng)一的方法進行創(chuàng)建和銷毀的問題。
Builder：解決對需要多步完成對象的創(chuàng)建時，簡化創(chuàng)建過程的復雜性和多樣性問題。
Factory Method：解決直接創(chuàng)建對象可能導致代碼的混亂并影響調用端代碼的獨立性問題。
Disposal Method：解決銷毀對象時可能需要多個步驟而引人過度的耦合問題。
Database Access Layer：它通過在兩種之間引人一個映射層將面向對象應用設計同關系型數(shù)據(jù)庫分離開。
Data Mapper：解決數(shù)據(jù)模型和持久化的表結構之間完全的解耦合的問題。
Row Data Gateway：解決更細致的數(shù)據(jù)模型和持久化的表結構之間完全解耦的問題。
Table Data Gateway：解決更細致的數(shù)據(jù)模型和持久化的表結構之間完全解耦的問題。
Active Record：解決降低應用中面向對象數(shù)據(jù)模型與數(shù)據(jù)庫中表結構之間的耦合的問題。
一、分層架構模式（Layered Architecture）
1. 定義
將系統(tǒng)按功能劃分為自上而下的多層結構（通常為表現(xiàn)層、業(yè)務邏輯層、數(shù)據(jù)訪問層、數(shù)據(jù)存儲層），層間通過標準化接口通信，上層依賴下層，下層不依賴上層。
2. 適用場景
傳統(tǒng)企業(yè)應用（如 ERP、CRM 系統(tǒng)）、中小型 Web 應用、需求穩(wěn)定且變更較少的系統(tǒng)。
3. 核心特點
職責清晰：每層專注單一功能（如表現(xiàn)層負責用戶交互，業(yè)務層處理核心邏輯）；
低耦合高內聚：層間通過接口隔離，修改某一層不影響其他層；
易于維護：問題定位精準，運維成本低。
4. 優(yōu)缺點
優(yōu)點：架構簡單易懂、開發(fā)效率高、便于團隊協(xié)作；
缺點：靈活性不足、多層調用導致性能損耗、難以應對高并發(fā)場景。
二、微服務架構模式（Microservices Architecture）
1. 定義
將系統(tǒng)拆分為多個獨立部署、松耦合的小型服務，每個服務聚焦單一業(yè)務領域（如用戶服務、訂單服務），通過 API 網(wǎng)關、服務注冊發(fā)現(xiàn)等組件實現(xiàn)通信與協(xié)同。
2. 適用場景
大型互聯(lián)網(wǎng)應用（如電商平臺、社交 APP）、業(yè)務場景復雜且需快速迭代的系統(tǒng)、高并發(fā)高可用需求的系統(tǒng)。
3. 核心特點
獨立部署：每個服務可單獨升級、擴容，不影響整體系統(tǒng)；
技術異構：不同服務可選用不同技術棧（如 Java、Python、Go）；
彈性伸縮：針對高負載服務單獨擴容，資源利用率更高。
4. 優(yōu)缺點
優(yōu)點：靈活性強、迭代速度快、容錯性高（單個服務故障不影響全局）；
缺點：架構復雜、運維成本高（需解決服務治理、分布式事務等問題）、跨服務調用延遲。
三、事件驅動架構模式（Event-Driven Architecture）
1. 定義
以 “事件” 為核心，系統(tǒng)組件通過發(fā)布 / 訂閱（Pub/Sub）機制異步通信：事件生產(chǎn)者發(fā)布事件，事件消費者訂閱并響應事件，組件間無直接依賴。
2. 適用場景
異步處理場景（如訂單支付后通知物流、短信發(fā)送）、數(shù)據(jù)流處理系統(tǒng)（如實時數(shù)據(jù)分析）、松耦合的分布式系統(tǒng)。
3. 核心特點
異步通信：組件間無需同步等待，提升系統(tǒng)響應速度；
高擴展性：新增消費者無需修改生產(chǎn)者代碼，易于橫向擴展；
容錯性強：單個組件故障不影響事件傳遞（通過消息隊列重試機制）。
4. 優(yōu)缺點
優(yōu)點：解耦效果好、支持高并發(fā)、適應業(yè)務變更；
缺點：事件追蹤難度大、一致性保障復雜、需依賴可靠的消息隊列組件。
四、微內核架構模式（Microkernel Architecture）
1. 定義
又稱 “插件架構”，核心由 “微內核”（提供基礎服務，如插件管理、通信機制）和 “插件模塊”（實現(xiàn)具體業(yè)務功能）組成，插件可動態(tài)加載、卸載，不影響內核運行。
2. 適用場景
功能可擴展的平臺型系統(tǒng)（如 IDE 工具、電商開放平臺）、需支持第三方集成的系統(tǒng)、業(yè)務功能頻繁變更的系統(tǒng)。
3. 核心特點
內核輕量化：僅包含核心依賴與基礎能力，無業(yè)務邏輯；
插件化擴展：通過插件實現(xiàn)功能增減，無需重構內核；
高靈活性：支持按需加載插件，適配不同業(yè)務場景。
4. 優(yōu)缺點
優(yōu)點：擴展性強、維護成本低、核心系統(tǒng)穩(wěn)定；
缺點：插件間通信復雜、內核設計難度高、性能略低于單體架構。
五、服務網(wǎng)格架構模式（Service Mesh）
1. 定義
專為微服務架構設計，通過 “數(shù)據(jù)平面”（Sidecar 代理，如 Istio 的 Envoy）和 “控制平面”（管理代理集群）分離服務通信與業(yè)務邏輯，代理負責流量控制、安全認證、監(jiān)控追蹤等非業(yè)務功能。
2. 適用場景
大規(guī)模微服務集群（如超過 50 個服務的系統(tǒng)）、對服務治理（流量控制、可觀測性）要求高的系統(tǒng)、跨團隊協(xié)作的微服務項目。
3. 核心特點
無侵入式：業(yè)務代碼無需關注通信細節(jié)，由 Sidecar 代理處理；
統(tǒng)一治理：通過控制平面集中配置流量路由、熔斷降級、安全策略；
可觀測性：自帶監(jiān)控、日志、追蹤功能，便于問題排查。
4. 優(yōu)缺點
優(yōu)點：降低微服務治理復雜度、提升系統(tǒng)可觀測性與安全性；
缺點：架構引入額外開銷、學習成本高、部署維護復雜。
六、領域驅動設計架構（DDD Architecture）
1. 定義
以 “領域模型” 為核心，通過限界上下文（Bounded Context）劃分業(yè)務領域，每個限界上下文對應獨立的業(yè)務模塊，模塊內包含領域實體、值對象、領域服務等核心組件，模塊間通過領域事件或 API 通信。
2. 適用場景
業(yè)務邏輯復雜的大型系統(tǒng)（如金融核心系統(tǒng)、供應鏈管理系統(tǒng)）、需長期演進的業(yè)務系統(tǒng)、跨部門協(xié)作的復雜項目。
3. 核心特點
業(yè)務驅動：架構設計貼合業(yè)務場景，領域模型與業(yè)務邏輯高度一致；
邊界清晰：限界上下文明確模塊職責，減少跨領域依賴；
可演進性：支持業(yè)務規(guī)則變更，領域模型可逐步優(yōu)化。
4. 優(yōu)缺點
優(yōu)點：業(yè)務與技術融合度高、系統(tǒng)可維護性強、適應業(yè)務迭代；
缺點：學習成本高、建模難度大、小型系統(tǒng)應用性價比低。
七、無服務器架構模式（Serverless Architecture）
1. 定義
又稱 “函數(shù)即服務（FaaS）”，開發(fā)者無需關注服務器部署與運維，僅需編寫 “函數(shù)”（響應特定事件的代碼片段），由云廠商自動負責資源分配、彈性擴容、運行調度。
2. 適用場景
事件觸發(fā)型場景（如文件上傳后處理、定時任務）、流量波動大的應用（如秒殺活動、節(jié)日營銷）、小型工具類應用（如 API 接口服務）。
3. 核心特點
按需付費：僅為函數(shù)運行時間計費，閑置時無資源消耗；
彈性伸縮：云廠商自動根據(jù)請求量擴容，應對高并發(fā)；
簡化運維：無需管理服務器、操作系統(tǒng)、中間件。
4. 優(yōu)缺點
優(yōu)點：開發(fā)效率高、運維成本低、資源利用率高；
缺點：冷啟動延遲、函數(shù)運行時長受限、調試與監(jiān)控難度大。
八、管道 - 過濾器架構模式（Pipe-Filter Architecture）
1. 定義
將系統(tǒng)拆分為 “過濾器”（對數(shù)據(jù)進行處理，如驗證、轉換、計算）和 “管道”（傳遞數(shù)據(jù)的通道），數(shù)據(jù)通過管道在過濾器間流轉，每個過濾器獨立處理輸入數(shù)據(jù)并輸出結果。
2. 適用場景
數(shù)據(jù)處理類系統(tǒng)（如 ETL 工具、日志分析系統(tǒng)）、流式計算應用、批量處理任務（如報表生成）。
3. 核心特點
組件獨立：過濾器無狀態(tài)，僅依賴輸入數(shù)據(jù)，可單獨替換；
可組合性：通過管道靈活組合過濾器，實現(xiàn)不同數(shù)據(jù)處理流程；
并行處理：多個過濾器可并行工作，提升數(shù)據(jù)處理效率。
4. 優(yōu)缺點
優(yōu)點：靈活性強、可擴展性好、支持并行計算；
缺點：不適合復雜業(yè)務邏輯、數(shù)據(jù)格式需統(tǒng)一、調試難度大。
九、客戶端 - 服務器架構模式（Client-Server Architecture）
1. 定義
經(jīng)典分布式架構，分為 “客戶端”（提供用戶交互界面，如桌面 APP、瀏覽器）和 “服務器”（提供數(shù)據(jù)存儲、業(yè)務處理服務），客戶端通過網(wǎng)絡請求服務器資源，服務器響應請求并返回結果。
2. 適用場景
網(wǎng)絡應用（如 Web 網(wǎng)站、移動 APP 后端）、需要集中管理數(shù)據(jù)的系統(tǒng)（如企業(yè)數(shù)據(jù)庫應用）、客戶端與服務器分離的場景。
3. 核心特點
職責分離：客戶端專注交互，服務器專注數(shù)據(jù)與業(yè)務處理；
集中管理：數(shù)據(jù)存儲在服務器，便于維護、備份與權限控制；
可擴展性：支持多客戶端接入，服務器可單獨擴容。
4. 優(yōu)缺點
優(yōu)點：架構簡單、數(shù)據(jù)一致性強、維護成本低；
缺點：服務器壓力集中、網(wǎng)絡依賴高、客戶端靈活性受限。
十、對等網(wǎng)絡架構模式（Peer-to-Peer Architecture）
1. 定義
又稱 “P2P 架構”，網(wǎng)絡中所有節(jié)點（Peer）地位平等，無中心服務器，每個節(jié)點既可以作為客戶端請求資源，也可以作為服務器提供資源，通過節(jié)點間直接通信實現(xiàn)數(shù)據(jù)共享與協(xié)同。
2. 適用場景
文件共享系統(tǒng)（如 BitTorrent）、分布式計算網(wǎng)絡、即時通信工具（如早期 QQ）、去中心化應用（如區(qū)塊鏈）。
3. 核心特點
去中心化：無中心節(jié)點依賴，單個節(jié)點故障不影響網(wǎng)絡運行；
可擴展性強：新增節(jié)點即可提升網(wǎng)絡算力與存儲能力；
資源共享：節(jié)點間直接共享數(shù)據(jù)，無需經(jīng)過中間服務器。
4. 優(yōu)缺點
優(yōu)點：容錯性高、擴展性好、網(wǎng)絡帶寬利用率高；
缺點：節(jié)點管理復雜、數(shù)據(jù)一致性難保障、安全性較低（易受攻擊）。
【系統(tǒng)架構設計模式】相關文章：
旅游管理系統(tǒng)功能架構的設計07-08
集團資產(chǎn)管理系統(tǒng)的架構與設計07-10
系統(tǒng)架構師知識：高可用系統(tǒng)設計09-19
基于云架構的系統(tǒng)安全設計10-19
系統(tǒng)架構設計師要素06-17
航標業(yè)務系統(tǒng)架構的設計和實現(xiàn)05-17
web系統(tǒng)分層架構設計06-24