一、基本概念
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 数据库系统
定义：以共享数据库为核心，多个构件通过读写数据库来交互。
特点：数据集中存储、构件通过数据库协作
适用场景：传统信息管理系统、ERP
5.2 黑板系统（Blackboard）
定义：由三部分组成：黑板（共享数据区域）、知识源（独立的专家模块）、控制器（协调知识源）。多个知识源观察黑板上的数据变化，当条件满足时主动贡献自己的结果。
结构：
知识源A ──┐ 知识源B ──┼── 黑板（共享数据）←── 控制器 知识源C ──┘适用场景：语音识别、图像识别、自然语言理解等 AI 问题求解
优点：
- 支持多种不同的知识表示和推理方法
- 易于添加新的知识源
- 适合无确定性算法的复杂问题
缺点：
- 控制逻辑复杂
- 调试与测试困难
- 不保证解的质量
考试高频对比：黑板 vs 数据库
| 维度 | 黑板系统 | 数据库系统 |
|---|---|---|
| 触发方式 | 知识源主动观察黑板 | 应用主动查询数据库 |
| 交互模式 | 数据驱动 + 控制器协调 | 请求-响应 |
| 适用领域 | AI、信号处理 | 企业信息系统 |
5.3 超文本系统
定义：以网状结构组织信息，节点之间通过超链接连接。
适用场景：Web 系统、在线文档
四、其他高频架构模式
除了五大风格下的子风格，以下架构模式也是案例题高频考点。
1. MVC（Model-View-Controller）
定义：将系统分为三个部分：
- Model（模型）：业务数据与逻辑
- View（视图）：用户界面展示
- Controller（控制器）：处理用户输入、协调 Model 与 View
交互关系：用户操作 -> Controller -> 更新 Model -> 通知 View -> 展示给用户
优点：
- 职责分离，便于并行开发
- View 可替换、Model 可复用
- 易于测试（Model 可独立测试）
缺点：
- 增加了系统复杂度
- View 与 Model 之间可能存在紧耦合
- 小型项目过度设计
2. MVP 与 MVVM
| 模式 | Presenter / ViewModel 的职责 | View 的特点 |
|---|---|---|
| MVC | Controller 转发请求 | View 直接读取 Model |
| MVP | Presenter 完全中介 | View 被动，只通过接口与 Presenter 交互 |
| MVVM | ViewModel 通过数据绑定同步 | View 与 ViewModel 双向绑定 |
3. 微内核（Microkernel）
定义：系统分为最小化的核心和可插拔的插件/扩展。核心只提供最基本的功能，所有扩展功能以插件形式加载。
适用场景：操作系统、IDE、可插拔平台
优点：极高的可扩展性、核心稳定
缺点：插件间协调复杂、核心接口设计难度高
4. SOA（面向服务架构）
定义：将系统功能封装为标准化的服务，服务之间通过**企业服务总线（ESB）**或标准协议通信，实现松耦合与复用。
三大角色：服务提供者、服务消费者、服务注册中心
核心思想：服务注册 -> 服务发现 -> 服务调用
优点：
- 松耦合、标准化接口
- 服务可复用
- 支持异构系统集成
缺点：
- ESB 可能成为单点瓶颈
- 服务粒度难以把控
- 治理与运维复杂
5. 微服务架构
定义：将单体应用拆分为一组小型服务，每个服务运行在独立进程中，围绕业务能力构建，通过轻量级通信机制（通常为 HTTP/JSON）协作，可独立部署。
与 SOA 的对比：
| 维度 | SOA | 微服务 |
|---|---|---|
| 服务粒度 | 较粗 | 较细 |
| 通信方式 | ESB（重量级） | HTTP/REST/gRPC（轻量级） |
| 数据管理 | 共享数据库 | 每个服务独立数据库 |
| 治理方式 | 集中治理 | 分散治理 |
| 部署方式 | 整体部署 | 独立部署 |
微服务优点：
- 化解复杂度，便于理解与维护
- 独立开发，技术选型自由
- 独立部署，加快发布节奏
- 独立扩展，资源利用精细
微服务挑战：
- 分布式系统复杂度（网络、一致性）
- 部署与运维成本高
- 接口治理与版本管理
- 数据一致性难保证
6. C/S 与 B/S
| 维度 | C/S | B/S |
|---|---|---|
| 客户端 | 需安装专用客户端 | 浏览器即可 |
| 升级维护 | 需要更新客户端 | 只需更新服务端 |
| 性能 | 客户端可承担部分计算 | 服务端压力较大 |
| 适用场景 | 专业软件、游戏 | Web 应用、信息系统 |
五、架构风格选型思路
案例题给出业务场景让你选架构时，可以从以下维度判断：
| 判断依据 | 适合的风格 |
|---|---|
| 数据需要经过多步顺序处理 | 管道-过滤器 |
| 系统分为展示、业务、数据三层 | 分层 |
| 需要高度松耦合、异步通信 | 事件驱动 / 发布-订阅 |
| AI 类问题、多种不确定推理策略 | 黑板 |
| 规则频繁变化、需要动态执行 | 解释器 / 规则引擎 |
| 需要插件化扩展 | 微内核 |
| 多团队独立开发、独立部署 | 微服务 |
| 异构系统集成、标准化接口 | SOA |
| Web 前端交互复杂 | MVC / MVVM |
六、答题模板
概念定义题
[风格名称]是一种[描述构件类型]的架构风格，构件之间通过[连接方式]交互。适用于[场景类型]系统。
优缺点题
优点：1. … 2. … 3. …
缺点：1. … 2. … 3. …
适用场景：…
对比题
按以下维度逐条对比：定义、结构、通信方式、优点、缺点、适用场景。
选型题
该场景适合采用[风格名称]。因为[从业务特征出发]，该风格在[质量属性]方面具有优势。
