分篇二：架构风格与架构模式

一、基本概念1. 什么是架构风格架构风格描述的是一类系统的结构组织方式。它定义了一组构件类型如过滤器、层、服务构件之间的连接方式如管道、调用、事件构件如何组合为系统对构件交互的约束简单说架构风格 构件 连接件 约束。2. 架构风格 vs 架构模式 vs 设计模式概念粒度关注点举例架构风格系统级系统的整体组织方式与家族特征分层、管道-过滤器、客户端-服务器架构模式系统/子系统级解决系统级重复出现的结构问题MVC、微内核、Broker设计模式类/对象级解决代码级重复出现的设计问题单例、工厂、观察者、策略考试中架构风格与架构模式经常互换使用答题时不必纠结概念边界。二、五大架构风格分类教材将架构风格分为五大类每类下有具体的子风格。总览表大类子风格关键词数据流风格批处理序列、管道-过滤器数据驱动、流水线调用/返回风格主程序/子程序、面向对象、分层层次、调用链独立构件风格进程通信、事件驱动隐式调用松耦合、事件、消息虚拟机风格解释器、基于规则的系统灵活、可编程仓库风格数据库系统、黑板系统、超文本系统共享数据、知识源三、每种架构风格详解1. 数据流风格1.1 批处理序列定义数据按照一系列固定顺序的处理步骤依次传递每个步骤处理完全部数据后再将结果交给下一步。结构步骤1 - 步骤2 - 步骤3 - … - 最终结果特点每个步骤是独立的程序步骤之间通过文件或数据集传递数据前一步必须全部完成后下一步才能开始适用场景传统 ETL、数据报表、离线数据处理优点逻辑清晰、各步骤独立、便于管理缺点无法实时处理、延迟高、交互性差1.2 管道-过滤器Pipes and Filters定义每个处理步骤称为过滤器数据通过管道在过滤器之间流动。与批处理不同过滤器可以增量式处理数据不必等前一步全部完成。结构数据源 - |过滤器A| - |过滤器B| - |过滤器C| - 数据汇特点过滤器之间互相独立只通过管道通信过滤器不知道上游和下游是谁支持并行处理便于复用与组合适用场景编译器词法-语法-语义-代码生成、Unix Shell 管道、数据清洗流水线优点高内聚低耦合易于理解、维护和复用支持并行与流水线处理易于添加新的过滤器缺点不适合需要共享大量状态的交互式系统过滤器之间的数据格式转换可能成为负担错误处理困难考试高频对比管道-过滤器 vs 分层维度管道-过滤器分层数据流向线性数据流层间调用/返回交互方式数据驱动接口调用构件关系各过滤器独立上层依赖下层适用场景数据处理流水线企业应用、Web 系统2. 调用/返回风格2.1 主程序/子程序定义系统由一个主程序和若干子程序组成主程序通过调用子程序来完成功能子程序可以继续调用更底层的子程序。特点层次分解、自顶向下、顺序执行适用场景结构化程序设计优点结构清晰、易于理解缺点灵活性差、扩展不便2.2 面向对象定义系统由一组对象构成每个对象封装了数据和操作对象之间通过消息/方法调用交互。特点封装、继承、多态适用场景大部分现代软件系统优点高复用、易扩展、便于维护缺点对象间调用链可能复杂、性能开销2.3 分层架构Layers定义将系统划分为若干层次每层只能调用相邻下层的服务层与层之间通过接口通信。典型结构表示层UI ↓ 业务逻辑层 ↓ 数据访问层 ↓ 数据库特点每层职责单一层间通过接口隔离严格分层只能调用直接下层松散分层允许跨层调用适用场景企业级应用、Web 系统、操作系统优点职责清晰、关注点分离易于维护和测试支持并行开发不同团队负责不同层层间可替换缺点严格分层可能影响性能每次请求要穿越所有层层间接口变更可能引发连锁修改不适合高性能实时系统3. 独立构件风格3.1 进程通信定义系统由多个独立运行的进程构成进程之间通过消息传递通信。特点进程独立运行、通过消息交换数据适用场景分布式系统、微服务间通信3.2 事件驱动 / 隐式调用定义构件不直接调用彼此而是通过发布事件来触发其他构件的响应。一个构件发布事件系统自动将事件传递给所有注册了该事件的构件。特点发布者不知道谁会处理事件接收者不知道事件从哪里来松耦合适用场景GUI 系统、消息中间件、EDA事件驱动架构优点极高的松耦合易于添加新的事件处理者支持动态注册与注销缺点控制流难以追踪和理解事件处理顺序不确定调试困难性能难以预测考试高频关联发布-订阅模式属于事件驱动的典型实现。4. 虚拟机风格4.1 解释器定义系统内嵌一个虚拟机能够解释执行自定义语言或规则。结构解释引擎 被解释的程序/规则 程序/规则的内部表示 解释引擎当前状态适用场景脚本引擎、规则引擎、DSL领域特定语言优点极高的灵活性可以动态修改规则缺点性能较差解释执行比编译执行慢4.2 基于规则的系统定义是解释器的一种特化系统行为由一组规则驱动规则引擎根据当前数据匹配规则并执行。适用场景专家系统、业务规则引擎、风控系统5. 仓库风格5.1 数据库系统定义以共享数据库为核心多个构件通过读写数据库来交互。特点数据集中存储、构件通过数据库协作适用场景传统信息管理系统、ERP5.2 黑板系统Blackboard定义由三部分组成黑板共享数据区域、知识源独立的专家模块、控制器协调知识源。多个知识源观察黑板上的数据变化当条件满足时主动贡献自己的结果。结构知识源A ──┐ 知识源B ──┼── 黑板共享数据←── 控制器 知识源C ──┘适用场景语音识别、图像识别、自然语言理解等 AI 问题求解优点支持多种不同的知识表示和推理方法易于添加新的知识源适合无确定性算法的复杂问题缺点控制逻辑复杂调试与测试困难不保证解的质量考试高频对比黑板 vs 数据库维度黑板系统数据库系统触发方式知识源主动观察黑板应用主动查询数据库交互模式数据驱动 控制器协调请求-响应适用领域AI、信号处理企业信息系统5.3 超文本系统定义以网状结构组织信息节点之间通过超链接连接。适用场景Web 系统、在线文档四、其他高频架构模式除了五大风格下的子风格以下架构模式也是案例题高频考点。1. MVCModel-View-Controller定义将系统分为三个部分Model模型业务数据与逻辑View视图用户界面展示Controller控制器处理用户输入、协调 Model 与 View交互关系用户操作 - Controller - 更新 Model - 通知 View - 展示给用户优点职责分离便于并行开发View 可替换、Model 可复用易于测试Model 可独立测试缺点增加了系统复杂度View 与 Model 之间可能存在紧耦合小型项目过度设计2. MVP 与 MVVM模式Presenter / ViewModel 的职责View 的特点MVCController 转发请求View 直接读取 ModelMVPPresenter 完全中介View 被动只通过接口与 Presenter 交互MVVMViewModel 通过数据绑定同步View 与 ViewModel 双向绑定3. 微内核Microkernel定义系统分为最小化的核心和可插拔的插件/扩展。核心只提供最基本的功能所有扩展功能以插件形式加载。适用场景操作系统、IDE、可插拔平台优点极高的可扩展性、核心稳定缺点插件间协调复杂、核心接口设计难度高4. SOA面向服务架构定义将系统功能封装为标准化的服务服务之间通过**企业服务总线ESB**或标准协议通信实现松耦合与复用。三大角色服务提供者、服务消费者、服务注册中心核心思想服务注册 - 服务发现 - 服务调用优点松耦合、标准化接口服务可复用支持异构系统集成缺点ESB 可能成为单点瓶颈服务粒度难以把控治理与运维复杂5. 微服务架构定义将单体应用拆分为一组小型服务每个服务运行在独立进程中围绕业务能力构建通过轻量级通信机制通常为 HTTP/JSON协作可独立部署。与 SOA 的对比维度SOA微服务服务粒度较粗较细通信方式ESB重量级HTTP/REST/gRPC轻量级数据管理共享数据库每个服务独立数据库治理方式集中治理分散治理部署方式整体部署独立部署微服务优点化解复杂度便于理解与维护独立开发技术选型自由独立部署加快发布节奏独立扩展资源利用精细微服务挑战分布式系统复杂度网络、一致性部署与运维成本高接口治理与版本管理数据一致性难保证6. C/S 与 B/S维度C/SB/S客户端需安装专用客户端浏览器即可升级维护需要更新客户端只需更新服务端性能客户端可承担部分计算服务端压力较大适用场景专业软件、游戏Web 应用、信息系统五、架构风格选型思路案例题给出业务场景让你选架构时可以从以下维度判断判断依据适合的风格数据需要经过多步顺序处理管道-过滤器系统分为展示、业务、数据三层分层需要高度松耦合、异步通信事件驱动 / 发布-订阅AI 类问题、多种不确定推理策略黑板规则频繁变化、需要动态执行解释器 / 规则引擎需要插件化扩展微内核多团队独立开发、独立部署微服务异构系统集成、标准化接口SOAWeb 前端交互复杂MVC / MVVM六、答题模板概念定义题[风格名称]是一种[描述构件类型]的架构风格构件之间通过[连接方式]交互。适用于[场景类型]系统。优缺点题优点1. … 2. … 3. …缺点1. … 2. … 3. …适用场景…对比题按以下维度逐条对比定义、结构、通信方式、优点、缺点、适用场景。选型题该场景适合采用[风格名称]。因为[从业务特征出发]该风格在[质量属性]方面具有优势。