系統架構設計模式

時間：2025-11-27 08:45:37 銀鳳系統架構師我要投稿

相關推薦

系統架構設計模式大全

　　目前系統架構大約有110多種設計模式，模式不是教條，模式僅僅是經驗的總結，下面小編為大家整理了一些系統架構設計模式，一起來看看吧：

　　Domain Model：定義了一個應用領域結構和工作流的精確模型，其中還包括它們的變化。

　　Layers：解決系統合理分層的問題。

　　Model-View-Controller：解決對用戶界面變化的支持問題。支持某一特定用戶界面的變化。

　　Presentation-Abstraction-Control：解決相同業務具有多種表現形式問題。

　　Microkernel：解決業務具有多種不同業務方法的問題。

　　Refelection：解決需要動態改變軟件系統結構和行為的問題。

　　Pipes and Filters：解決算法的結構化并可以重新構建的問題。

　　Shared Repository：適用于網絡管理和控制系統領域。

　　Blackboard：解決運行中智能化改進處理方法的問題。

　　Domain Object：表現為已經將自我完備的連貫功能和基礎性責任封裝成定義良好的實體，通過一個或多個”顯示接口”提供功能，并隱藏內部結構和實現。

　　Messaging：由一系列相互連接的MessageChannel和Message Router管理著跨網絡的不同服務間的消息交換。

　　Message Channel：解決如何把彼此協作的客戶端和服務連接起來的問題。

　　Message Router：解決如何根據條件接受”信道”消息的問題。

　　Message Translator：解決如何轉換消息格式的問題。

　　Message Endpoint：解決把數據轉換為消息中間件能夠理解的形式的問題。

　　Publisher-Subscriber：為了在應用中更好的把彼此關注的事件通知給其它領域對象。

　　Broker：通過一個代理管理器管理領域對象間遠程互操作的各個關鍵方面。

　　Client Proxy：解決客戶端應用與網絡基礎設施相互屏蔽的問題。

　　Requestor：解決應用代碼被基礎設施的代碼污染而影響可移植性的問題。

　　Invoker：解決服務代碼被基礎設施的代碼污染而影響可移植性的問題。

　　Client Request Handler：解決客戶端應用與通信相互影響的問題，它封裝了客戶端在統一的接口背后進行的進程間通信的細節。

　　Server Request Handler：解決服務端應用與通信相互影響的問題，封裝了服務器端在統一的接口背后進行的進程間通信的細節。

　　Reactor：解決在應用中避免使用多線程的問題。

　　Proactor：解決在多線程的背景下出現性能問題的缺陷。

　　Acceptor-Connector：把事件初始化與具體處理方法分離，從而提高可維護性。

　　Asynchronous Completion Token：解決異步到達的事件仍然能按一定順序處理的問題。

　　Explicit Interface：解決如何正確設計接口的問題。

　　Extension Interface：隨著時間的推移，組件的接口是會膨脹的，一個胖的接口將更脆弱。解決防止”胖”接口并分離接口。

　　Introspective Interface：解決公開內部信息接口的問題。

　　Dynamic Invocation Interface：解決同一個接口允許客戶端調用多種方法的問題。

　　Proxy：解決在同一個接口下通過代理屏蔽某些實現的問題。

　　Business Delegate：由本地業務代表來完成所有網絡任務，分離了應用和網絡處理的業務，減少了開發難度、提高了可理解性和可維護性。

　　Facade：解決屏蔽子系統的變化輻射到高層應用的問題。

　　Combined Method：解決多種相互關聯的方法不合理的分布的問題。

　　Iterator：解決分布式元素能夠方便迭代的問題。

　　Enumeration Method：解決減少外部迭代方式多次對聚合中的元素進行獨立訪問開銷的問題。

　　Batch Method：解決多次訪問加大網絡開銷的問題。

　　Encapsulated Implementation：解決對象劃分的基本原則和方法問題。

　　Composite：建立一種結構靈活的樹狀結構對象組織形式，形成“整體/部分”層級結構。

　　Half-Object plus Protocol：通過在分布式系統中合理布局對象，以減少不合理的網絡流量和服務器壓力。

　　Replicated Component Group：解決分布式系統容錯的問題，復制的組件實現位于不同的網絡節點，并組成一個組件組。

　　Half-Sync/Half-Async：對并發系統中的異步和同步服務處理解耦合以簡化編程，但又不會過度地影響性能。

　　Leader/Followers：解決大批量小處理的環境下減少并發線程應用的問題。

　　Active Object：為了減少服務器并發線程應用。

　　Monitor Object：解決并發業務相互協調的問題。

　　Guarded Suspension：在并發性程序中，當某個線程對一個資源進行訪問的時候，首先需要判斷這個資源的警戒條件是否成立。

　　Future：并發調用的服務可能需要向客戶端返回結果。

　　Thread-Safe Interface：避免自死鎖和加鎖開銷。

　　Strategized Locking：在創建或聲明時，為組件配置適當類型的鎖實例。使用該鎖實例來保護組件中的所有臨界區。

　　Scoped Locking：解決復雜繁瑣代碼中的疏忽發生漏釋放造成死鎖的問題。

　　Thread-Specific Storage：解決頻繁使用對象造成反復加鎖解鎖造成的性能問題。

　　Copied Value：解決共享的值對象必須鎖定帶來的性能問題。

　　Immutable Value：解決共享的值對象必須鎖定帶來的性能問題。

　　Observer：定義一個特定的更新接口，通過該接口，Observer獲得Subject狀態變更的通知。

　　Double Dispatch：根據運行時多個對象的類型確定方法調用的過程。

　　Mediator：封裝集合中所有對象的聚合協作行為，從而將這些對象解耦合。

　　Command：為這些對象定義一個通用接口，來執行它們所代表的請求。

　　Memento：解決在不破壞封裝性的前提下正確存儲和讀取分布式對象狀態的問題。

　　Context Object：解決在松耦合系統中共享與程序執行上下文相關的通用信息的問題。

　　Data Transfer Object：解決細粒度調用多次訪問遠程對象單個屬性所帶來的巨大開銷問題。

　　Message：解決網絡協議只支持比特流這種最簡單的數據傳輸形式，并不能識別服務調用和數據類型的問題。

　　Bridge：解決在下層穩定的業務中嵌入上次變化部分的問題。

　　Object Adapter：解決接口變化導致的不兼容問題。

　　Chain of Responsibility：解決對象結構和請求分發邏輯上的變化影響到客戶端的問題。

　　Interceptor：解決構建一個可插拔的框架變化模型的問題。

　　Visitor：解決將服務的實現分散在定義對象結構的各個類中難以進行集中處理的問題。

　　Decorator：解決在穩定的核心功能外圍添加擴展的問題。

　　Template Method：解決在下層穩定的業務中嵌入上次變化部分的問題。

　　Strategy：解決在一個或多個方法中根據不同的情況執行不同行為的問題。

　　Wrapper Facade：主要解決應用代碼使用底層API所提供的服務但代碼難以理解的問題，需要對底層API進行面向對象的封裝，通過提供一個簡潔的、健壯的、可移植的、內聚的面向對象的接口，來達到封裝函數和數據的目的。

　　Declarative Component Configuration：建立需要安裝各類插件的宿主基礎設施，使其能夠正確管理運行時環境，可靠運用系統資源和服務的問題。

　　Container：解決領域對象直接處理平臺環境造成它與平臺緊密耦合并增加實現的復雜性的問題。

　　Component Configurator：解決在組件生命周期后期和升級時重新配置組件的問題。

　　Object Manager：解決客戶端依賴對象管理增加應用內部的耦合度和復雜度的問題。

　　Virtual Proxy：解決從一個巨大數據庫中把所有的對象全部加載進來消耗大量資源的問題。

　　Resource Pool：解決獲取和釋放資源(網絡連接、線程或者內容)引入一定的性能開銷問題。

　　Resource Cache：解決幾個有限的資源用戶頻繁創建和釋放資源帶來不必要的性能開銷問題。

　　Automated Garbage Collection：解決不能及時將不再使用的內存收回可能耗盡內存的問題。

　　Counting Handles：解決確保在堆上創建的共享對象能夠可靠地、安全地、及時地回收的問題。

　　Abstract Factory：解決一批對象用統一的方法進行創建和銷毀的問題。

　　Builder：解決對需要多步完成對象的創建時，簡化創建過程的復雜性和多樣性問題。

　　Factory Method：解決直接創建對象可能導致代碼的混亂并影響調用端代碼的獨立性問題。

　　Disposal Method：解決銷毀對象時可能需要多個步驟而引人過度的耦合問題。

　　Database Access Layer：它通過在兩種之間引人一個映射層將面向對象應用設計同關系型數據庫分離開。

　　Data Mapper：解決數據模型和持久化的表結構之間完全的解耦合的問題。

　　Row Data Gateway：解決更細致的數據模型和持久化的表結構之間完全解耦的問題。

　　Table Data Gateway：解決更細致的數據模型和持久化的表結構之間完全解耦的問題。

　　Active Record：解決降低應用中面向對象數據模型與數據庫中表結構之間的耦合的問題。

　　一、分層架構模式（Layered Architecture）

　　1. 定義

　　將系統按功能劃分為自上而下的多層結構（通常為表現層、業務邏輯層、數據訪問層、數據存儲層），層間通過標準化接口通信，上層依賴下層，下層不依賴上層。

　　2. 適用場景

　　傳統企業應用（如 ERP、CRM 系統）、中小型 Web 應用、需求穩定且變更較少的系統。

　　3. 核心特點

　　職責清晰：每層專注單一功能（如表現層負責用戶交互，業務層處理核心邏輯）；

　　低耦合高內聚：層間通過接口隔離，修改某一層不影響其他層；

　　易于維護：問題定位精準，運維成本低。

　　4. 優缺點

　　優點：架構簡單易懂、開發效率高、便于團隊協作；

　　缺點：靈活性不足、多層調用導致性能損耗、難以應對高并發場景。

　　二、微服務架構模式（Microservices Architecture）

　　1. 定義

　　將系統拆分為多個獨立部署、松耦合的小型服務，每個服務聚焦單一業務領域（如用戶服務、訂單服務），通過 API 網關、服務注冊發現等組件實現通信與協同。

　　2. 適用場景

　　大型互聯網應用（如電商平臺、社交 APP）、業務場景復雜且需快速迭代的系統、高并發高可用需求的系統。

　　3. 核心特點

　　獨立部署：每個服務可單獨升級、擴容，不影響整體系統；

　　技術異構：不同服務可選用不同技術棧（如 Java、Python、Go）；

　　彈性伸縮：針對高負載服務單獨擴容，資源利用率更高。

　　4. 優缺點

　　優點：靈活性強、迭代速度快、容錯性高（單個服務故障不影響全局）；

　　缺點：架構復雜、運維成本高（需解決服務治理、分布式事務等問題）、跨服務調用延遲。

　　三、事件驅動架構模式（Event-Driven Architecture）

　　1. 定義

　　以 “事件” 為核心，系統組件通過發布 / 訂閱（Pub/Sub）機制異步通信：事件生產者發布事件，事件消費者訂閱并響應事件，組件間無直接依賴。

　　2. 適用場景

　　異步處理場景（如訂單支付后通知物流、短信發送）、數據流處理系統（如實時數據分析）、松耦合的分布式系統。

　　3. 核心特點

　　異步通信：組件間無需同步等待，提升系統響應速度；

　　高擴展性：新增消費者無需修改生產者代碼，易于橫向擴展；

　　容錯性強：單個組件故障不影響事件傳遞（通過消息隊列重試機制）。

　　4. 優缺點

　　優點：解耦效果好、支持高并發、適應業務變更；

　　缺點：事件追蹤難度大、一致性保障復雜、需依賴可靠的消息隊列組件。

　　四、微內核架構模式（Microkernel Architecture）

　　1. 定義

　　又稱 “插件架構”，核心由 “微內核”（提供基礎服務，如插件管理、通信機制）和 “插件模塊”（實現具體業務功能）組成，插件可動態加載、卸載，不影響內核運行。

　　2. 適用場景

　　功能可擴展的平臺型系統（如 IDE 工具、電商開放平臺）、需支持第三方集成的系統、業務功能頻繁變更的系統。

　　3. 核心特點

　　內核輕量化：僅包含核心依賴與基礎能力，無業務邏輯；

　　插件化擴展：通過插件實現功能增減，無需重構內核；

　　高靈活性：支持按需加載插件，適配不同業務場景。

　　4. 優缺點

　　優點：擴展性強、維護成本低、核心系統穩定；

　　缺點：插件間通信復雜、內核設計難度高、性能略低于單體架構。

　　五、服務網格架構模式（Service Mesh）

　　1. 定義

　　專為微服務架構設計，通過 “數據平面”（Sidecar 代理，如 Istio 的 Envoy）和 “控制平面”（管理代理集群）分離服務通信與業務邏輯，代理負責流量控制、安全認證、監控追蹤等非業務功能。

　　2. 適用場景

　　大規模微服務集群（如超過 50 個服務的系統）、對服務治理（流量控制、可觀測性）要求高的系統、跨團隊協作的微服務項目。

　　3. 核心特點

　　無侵入式：業務代碼無需關注通信細節，由 Sidecar 代理處理；

　　統一治理：通過控制平面集中配置流量路由、熔斷降級、安全策略；

　　可觀測性：自帶監控、日志、追蹤功能，便于問題排查。

　　4. 優缺點

　　優點：降低微服務治理復雜度、提升系統可觀測性與安全性；

　　缺點：架構引入額外開銷、學習成本高、部署維護復雜。

　　六、領域驅動設計架構（DDD Architecture）

　　1. 定義

　　以 “領域模型” 為核心，通過限界上下文（Bounded Context）劃分業務領域，每個限界上下文對應獨立的業務模塊，模塊內包含領域實體、值對象、領域服務等核心組件，模塊間通過領域事件或 API 通信。

　　2. 適用場景

　　業務邏輯復雜的大型系統（如金融核心系統、供應鏈管理系統）、需長期演進的業務系統、跨部門協作的復雜項目。

　　3. 核心特點

　　業務驅動：架構設計貼合業務場景，領域模型與業務邏輯高度一致；

　　邊界清晰：限界上下文明確模塊職責，減少跨領域依賴；

　　可演進性：支持業務規則變更，領域模型可逐步優化。

　　4. 優缺點

　　優點：業務與技術融合度高、系統可維護性強、適應業務迭代；

　　缺點：學習成本高、建模難度大、小型系統應用性價比低。

　　七、無服務器架構模式（Serverless Architecture）

　　1. 定義

　　又稱 “函數即服務（FaaS）”，開發者無需關注服務器部署與運維，僅需編寫 “函數”（響應特定事件的代碼片段），由云廠商自動負責資源分配、彈性擴容、運行調度。

　　2. 適用場景

　　事件觸發型場景（如文件上傳后處理、定時任務）、流量波動大的應用（如秒殺活動、節日營銷）、小型工具類應用（如 API 接口服務）。

　　3. 核心特點

　　按需付費：僅為函數運行時間計費，閑置時無資源消耗；

　　彈性伸縮：云廠商自動根據請求量擴容，應對高并發；

　　簡化運維：無需管理服務器、操作系統、中間件。

　　4. 優缺點

　　優點：開發效率高、運維成本低、資源利用率高；

　　缺點：冷啟動延遲、函數運行時長受限、調試與監控難度大。

　　八、管道 - 過濾器架構模式（Pipe-Filter Architecture）

　　1. 定義

　　將系統拆分為 “過濾器”（對數據進行處理，如驗證、轉換、計算）和 “管道”（傳遞數據的通道），數據通過管道在過濾器間流轉，每個過濾器獨立處理輸入數據并輸出結果。

　　2. 適用場景

　　數據處理類系統（如 ETL 工具、日志分析系統）、流式計算應用、批量處理任務（如報表生成）。

　　3. 核心特點

　　組件獨立：過濾器無狀態，僅依賴輸入數據，可單獨替換；

　　可組合性：通過管道靈活組合過濾器，實現不同數據處理流程；

　　并行處理：多個過濾器可并行工作，提升數據處理效率。

　　4. 優缺點

　　優點：靈活性強、可擴展性好、支持并行計算；

　　缺點：不適合復雜業務邏輯、數據格式需統一、調試難度大。

　　九、客戶端 - 服務器架構模式（Client-Server Architecture）

　　1. 定義

　　經典分布式架構，分為 “客戶端”（提供用戶交互界面，如桌面 APP、瀏覽器）和 “服務器”（提供數據存儲、業務處理服務），客戶端通過網絡請求服務器資源，服務器響應請求并返回結果。

　　2. 適用場景

　　網絡應用（如 Web 網站、移動 APP 后端）、需要集中管理數據的系統（如企業數據庫應用）、客戶端與服務器分離的場景。

　　3. 核心特點

　　職責分離：客戶端專注交互，服務器專注數據與業務處理；

　　集中管理：數據存儲在服務器，便于維護、備份與權限控制；

　　可擴展性：支持多客戶端接入，服務器可單獨擴容。

　　4. 優缺點

　　優點：架構簡單、數據一致性強、維護成本低；

　　缺點：服務器壓力集中、網絡依賴高、客戶端靈活性受限。

　　十、對等網絡架構模式（Peer-to-Peer Architecture）

　　1. 定義

　　又稱 “P2P 架構”，網絡中所有節點（Peer）地位平等，無中心服務器，每個節點既可以作為客戶端請求資源，也可以作為服務器提供資源，通過節點間直接通信實現數據共享與協同。

　　2. 適用場景

　　文件共享系統（如 BitTorrent）、分布式計算網絡、即時通信工具（如早期 QQ）、去中心化應用（如區塊鏈）。

　　3. 核心特點

　　去中心化：無中心節點依賴，單個節點故障不影響網絡運行；

　　可擴展性強：新增節點即可提升網絡算力與存儲能力；

　　資源共享：節點間直接共享數據，無需經過中間服務器。

　　4. 優缺點

　　優點：容錯性高、擴展性好、網絡帶寬利用率高；

　　缺點：節點管理復雜、數據一致性難保障、安全性較低（易受攻擊）。

【系統架構設計模式】相關文章：