系统架构设计模式

时间：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. 优缺点

　　优点：容错性高、扩展性好、网络带宽利用率高；

　　缺点：节点管理复杂、数据一致性难保障、安全性较低（易受攻击）。

【系统架构设计模式】相关文章：