架构风格分类体系
2026/1/29大约 15 分钟
架构风格分类体系
❌ 常被误称为“架构风格分类体系”：
| 各类体系 | 是否为架构风格分类体系 | 正确定位 | 权威纠正表述 |
|---|---|---|---|
| Shaw & Garlan (1996) | ✅ 是 | 架构风格分类框架 | Shaw & Garlan 五类架构风格类别框架 |
| POSA (1996–2007) | ❌ 否 | 架构模式系统 | POSA架构模式系统 |
| SEI/Bass方法 | ❌ 否 | 质量属性驱动设计方法 | SEI风格-质量属性映射指南 |
| ISO/IEC/IEEE 42010 | ❌ 否 | 架构描述元标准 | 42010要求引用风格，但不提供分类 |
| Kruchten 4+1 | ❌ 否 | 多视角架构描述模型 | 4+1视图模型用于表达架构 |
| CNCF云原生分类 | ❌ 否 | 技术实践景观 | CNCF Landscape是工具地图 |
（截至当前2026年）软件架构领域唯一被学术界与工业界共同认可的、符合三要素的真正架构风格分类体系，仅有 Shaw & Garlan (1996) 提出的五类架构风格类别框架。
权威佐证：
"Despite two decades of research, Shaw and Garlan’s classification remains the most widely cited and pedagogically useful framework for architectural styles."
（尽管历经二十年研究，Shaw 与 Garlan 的分类仍是被引用最广、教学上最有用的架构风格框架。）
—— Taylor, Medvidovic & Dashofy (2022), Foundations of Software Architecture
Shaw & Garlan 五类架构风格类别框架
1、五类架构风格类别简介
| 项目 | 详细内容 |
|---|---|
| 标准全称 | 五类架构风格类别框架（Five Categories of Architectural Styles Framework） |
| 提出背景 | 1990年代软件架构学科萌芽期，亟需形式化词汇表统一学术讨论（Shaw & Garlan, 1996, Preface） |
| 核心思想 | 以交互范式（Interaction Paradigm） 为分类基石，将风格归入5个高阶类别，每类共享连接器语义与拓扑模式 |
| 理论根基 | 五元组形式化模型： Architecture Style = <C, Conn, Config, Const, Sem> - C: Components（组件集合） - Conn: Connectors（连接器集合） - Config: Configuration（配置关系） - Const: Constraints（约束集合） - Sem: Semantics（语义映射） 出处：Shaw & Garlan (1996, pp.46–48); Allen (1997, CMU-CS-97-144) |
| 关键创新 | 首次将"风格"从模糊概念提升为可形式化验证的约束集合，奠定ADL（架构描述语言）理论基础 |
2、五类架构风格分类类别
| 类别中文 | 类别英文 | 分类维度本质 | 核心交互范式 |
|---|---|---|---|
| 数据流风格类别 | Dataflow Styles | 数据流动方向与组件状态 | Data flows unidirectionally; components are stateless filters （数据单向流动；组件为无状态过滤器） |
| 调用/返回风格类别 | Call/Return Styles | 调用-返回同步交互模式 | Synchronous procedure calls with return values （带返回值的同步过程调用） |
| 独立组件风格类别 | Independent Components Styles | 组件自治性与通信解耦 | Autonomous components communicate via events/messages （自治组件通过事件/消息通信） |
| 虚拟机风格类别 | Virtual Machine Styles | 指令解释执行机制 | Interpreter executes instruction sequences （解释器执行指令序列） |
| 仓库风格类别 | Repository Styles | 中心数据存储交互模式 | Components interact indirectly via central data store （组件通过中心数据存储间接交互） |
3、五类架构风格类别完整详解
3.1 数据流风格类别（Dataflow Styles）
类别定义
"In dataflow architectures, the components are filters that process data as it flows through a pipeline. The connectors are pipes that pass data from one filter to the next."（在数据流架构中，组件是过滤器，数据通过管道流动并被处理。连接器是管道，将数据从一个过滤器传递到下一个。）
出处：Shaw & Garlan (1996)
本类别包含的架构风格详表
| 中文名称 | 英文名称 | 组件类型与职责 | 连接器类型与语义 | 拓扑约束 | 核心约束 | 质量属性影响 | 典型系统示例 |
|---|---|---|---|---|---|---|---|
| 管道-过滤器 | Pipe and Filter | Filter: 无状态函数，输入→输出转换 | Pipe: FIFO队列，单向传递 | 线性链/树状 | 1. 单向流动 2. 无共享状态 3. 顺序处理 | +可修改性（过滤器替换） +可重用性（过滤器复用） -性能（管道阻塞） | Unix Shell (`grep |
| 批处理顺序 | Batch Sequential | Processor: 批处理单元，全量数据处理 | File/Stream: 文件或流 | 线性序列 | 1. 全量数据处理完成才传递 2. 无增量处理 | +简单性（顺序逻辑） -响应性（等待全量完成） | 传统ETL作业（Informatica） COBOL批处理系统（银行日终结算） |
学术澄清：
- Batch Sequential 是 Pipe and Filter 的约束变体（增加"全量处理"约束）
- 现代流处理系统（如Flink）是 Pipe and Filter 的扩展变体（增加窗口、状态管理）
3.2 调用/返回风格类别（Call/Return Styles）
类别定义
"Call and return architectures are characterized by components that interact through procedure calls... The caller suspends execution until the callee returns."
（调用/返回架构的特征是组件通过过程调用交互...调用者暂停执行直到被调用者返回。）
出处：Shaw & Garlan (1996)
本类别包含的架构风格详表
| 中文名称 | 英文名称 | 组件类型与职责 | 连接器类型与语义 | 拓扑约束 | 核心约束 | 质量属性影响 | 典型系统示例 |
|---|---|---|---|---|---|---|---|
| 主程序与子程序 | Main Program and Subroutine | Main: 控制流起点；Subroutine: 功能模块 | Direct Call: 编译时绑定 | 单层调用树 | 1. 顺序执行 2. 局部作用域 | +可理解性（线性流程） +可测试性（模块隔离） | 传统C程序（main()调用函数） Fortran科学计算程序 |
| 远程过程调用 | Remote Procedure Call (RPC) | Client: 请求发起者；Server: 服务提供者 | RPC Stub: 网络透明封装 | Client-Server | 1. 网络透明调用 2. 序列化参数 | +开发效率（本地调用感） -性能（网络延迟） -可靠性（网络故障） | Sun RPC（NFS基础） gRPC（Protocol Buffers） |
| 客户端-服务器 | Client-Server | Client: 用户交互；Server: 业务逻辑/数据 | Request/Reply: 消息交换 | 星型（多客户端→单服务器） | 1. 服务器并发处理 2. 客户端无状态 | +集中管理（服务器控制） -单点故障（服务器宕机） | Web应用（浏览器↔Apache） 数据库系统（应用↔MySQL） |
| 分层系统 | Layered Systems | Layer Lᵢ: 封装特定抽象级别 | Layer Interface: 仅调用下层 | 严格层次（Lᵢ仅调用Lᵢ₊₁） | 1. 单向依赖 2. 封装内部实现 | +可修改性（层内替换） +可移植性（替换底层） -性能（层间调用开销） | OSI七层模型 TCP/IP协议栈（应用→传输→网络→链路） |
学术澄清：
- Layered Systems 是 Client-Server 的层次化扩展（多层Client-Server嵌套）
- 现代微服务API Gateway是 Layered Systems 的变体（增加路由、认证等中间层）
3.3 独立组件风格类别（Independent Components Styles）
类别定义
"Independent components communicate by broadcasting events or messages... Components are loosely coupled and may be developed independently."
（独立组件通过广播事件或消息通信...组件松耦合且可独立开发。）
出处：Shaw & Garlan (1996)
本类别包含的架构风格详表
| 中文名称 | 英文名称 | 组件类型与职责 | 连接器类型与语义 | 拓扑约束 | 核心约束 | 质量属性影响 | 典型系统示例 |
|---|---|---|---|---|---|---|---|
| 隐式调用 | Implicit Invocation | Event Source: 事件产生者；Handler: 事件处理器 | Event Bus: 广播通道，注册/发布机制 | 广播式（一对多） | 1. 事件驱动 2. 松耦合（发布者不知晓处理器） 3. 动态注册 | +可扩展性（动态增减处理器） +可修改性（替换处理器） -调试难度（事件流难追踪） | GUI框架（Java AWT事件模型） Spring Framework事件机制 Node.js EventEmitter |
学术澄清：
- Peer-to-Peer (P2P) 为后续学术扩展（Rowstron & Druschel, 2001, Pastry），未纳入原始框架
- 现代事件驱动架构（EDA）是 Implicit Invocation 的工业化演进（保留核心约束，增强可靠性/顺序保证）
3.4 虚拟机风格类别（Virtual Machine Styles）
类别定义
"Virtual machine architectures consist of an interpreter component that executes a sequence of instructions... The instructions are treated as data by the interpreter."（虚拟机架构包含一个解释器组件，执行指令序列...指令被解释器视为数据。）
出处：Shaw & Garlan (1996)
本类别包含的架构风格详表
| 中文名称 | 英文名称 | 组件类型与职责 | 连接器类型与语义 | 拓扑约束 | 核心约束 | 质量属性影响 | 典型系统示例 |
|---|---|---|---|---|---|---|---|
| 解释器 | Interpreters | Interpreter: 指令执行引擎；Instruction Set: 字节码序列 | Instruction Stream: 指令序列流 | 中心解释器 | 1. 指令视为数据 2. 顺序解释执行 | +可移植性（跨平台） +安全性（沙箱执行） -性能（解释开销） | JVM（Java字节码） Python解释器（CPython） PostScript打印机解释器 |
| 基于规则的系统 | Rule-based Systems | Rule Base: 条件-动作规则库；Inference Engine: 推理引擎 | Rule Set: 规则集合 | 引擎+规则库 | 1. 规则匹配触发动作 2. 数据驱动推理 | +灵活性（规则动态更新） +领域表达力（专家知识编码） -性能（规则匹配开销） | 专家系统（MYCIN医疗诊断） 业务规则引擎（Drools） AI规划系统（SOAR） |
学术澄清：
- Rule-based Systems 是 Interpreters 的领域特化变体（指令=规则，解释器=推理引擎）
- 现代Serverless平台（如AWS Lambda）是 Virtual Machine 类别的云原生扩展（函数即指令，运行时即解释器）
3.5 仓库风格类别（Repository Styles）
类别定义
"Repository architectures feature a central data store (the repository) that is accessed by multiple components... Components communicate indirectly through the repository."（仓库架构包含一个中心数据存储（仓库），由多个组件访问...组件通过仓库间接通信。）
出处：Shaw & Garlan (1996)
本类别包含的架构风格详表
| 中文名称 | 英文名称 | 组件类型与职责 | 连接器类型与语义 | 拓扑约束 | 核心约束 | 质量属性影响 | 典型系统示例 |
|---|---|---|---|---|---|---|---|
| 仓库 | Repositories | Data Store: 中央数据库；Accessor: 数据访问组件 | Shared Memory/DB: 共享存储 | 星型 | 1. 读写共享数据 2. 无组件直连通信 | +数据一致性（单一源） +可维护性（集中管理） -单点故障风险 | 传统ERP系统（SAP中央数据库） 编译器符号表（各阶段共享） |
| 黑板系统 | Blackboard Systems | Knowledge Source (KS): 专家模块；Control: 调度器；Blackboard: 共享工作区 | Shared Blackboard: 全局数据空间 | 广播式（KS监听BB） | 1. KS基于BB状态变化触发 2. Control协调KS执行 | +问题求解能力（多专家协作） +灵活性（动态KS增减） -调试复杂性（控制流隐式） | 语音识别系统（HEARSAY-II） 智能CAD系统（BB1） 现代ML特征平台（Feast） |
学术澄清：
- Blackboard 明确归属 Repository 类别，非 Dataflow，误用根源：因"黑板"名称含"板"（board）被误认为数据流，实则核心是共享数据空间驱动协作
- 现代映射：特征存储（Feature Store）是 Blackboard 的云原生复兴（KS=ML模型，BB=特征库）
附录：非架构风格分类体系（正本清源）
1、POSA 架构模式系统（1996–2007）：模式 ≠ 风格
定位与核心价值
| 项目 | 详细说明 |
|---|---|
| 本质 | Pattern System（模式系统） （提供可复用的架构解决方案模板） |
| 目标 | "Describe proven solutions to recurring architectural problems" （描述针对重复出现的架构问题的已验证解决方案） 出处：Buschmann et al. (1996, Preface) |
| 结构 | 五卷本体系： - Vol.1: Domain-Specific Patterns（领域特定模式） - Vol.2: Concurrent & Networked Objects（并发与网络对象） - Vol.3: Resource Management（资源管理） - Vol.4: Distributed Computing（分布式计算） - Vol.5: On Patterns & Pattern Languages（模式与模式语言） |
| 与风格关系 | Pattern 是 Style 的具体实现： - Microkernel Pattern ⊂ Independent Components Style 变体 - Broker Pattern ⊂ Client-Server Style 扩展（增加中介层） 出处：POSA Vol.1 (1996, p.265) |
权威纠正
| 正确表述 | 纠正依据 |
|---|---|
| "POSA五卷架构模式系统" | Buschmann et al. (1996, Ch.1): "Patterns are more concrete than styles" |
| "Broker是Client-Server风格的模式实现" | POSA Vol.4 (2007, p.112): "Broker pattern realizes client-server style with location transparency" |
| Pattern = 具体解决方案模板； Style = 约束集合 | Gamma et al. (1994, p.293): "Styles define families of systems; patterns solve specific problems within styles" |
实践指导
正确使用场景：
- 当需解决"如何实现服务解耦"时 → 选用
BrokerPattern（基于Client-Server Style） - 当需解决"如何支持插件扩展"时 → 选用
MicrokernelPattern（基于Independent Components Style）
2、SEI/Bass 质量属性驱动方法：设计方法 ≠ 分类体系
定位与核心价值
| 项目 | 详细说明 |
|---|---|
| 本质 | Quality Attribute-Driven Design Method（质量属性驱动设计方法） 包含QAW（质量属性研讨会）、ATAM（架构权衡分析法） |
| 目标 | "Identify architectural decisions that satisfy critical quality attribute requirements" （识别满足关键质量属性需求的架构决策） 出处：Bass et al. (2021, Ch.5) |
| 核心工具 | Style-Quality Attribute Mapping Table（风格-质量属性映射表） 示例： - 高可用性 → Active Redundancy Style - 高可修改性 → Microkernel Style |
| 与风格关系 | 风格作为实现手段被分析，非分类对象 |
权威纠正
| 正确表述 | 纠正依据 |
|---|---|
| "SEI风格-质量属性映射指南" | SEI官方文档 (2023): "ATAM is an evaluation method, not a taxonomy" |
| 映射表是决策辅助工具，无分类逻辑 | Bass et al. (2021, Table 11.2 footnote): "Mappings are heuristic, not exhaustive" |
| 现实系统需多风格组合满足多质量属性 | Bass et al. (2021, p.291): "Tradeoffs require combining styles (e.g., layered + repository)" |
实践指导
正确使用流程：
- 通过QAW识别关键质量属性（如"99.99%可用性"）
- 查阅映射表选择候选风格（如
Active Redundancy） - 用ATAM验证风格组合的权衡（如冗余带来的成本）
3、ISO/IEC/IEEE 42010:2011：元标准 ≠ 分类体系
定位与核心价值
| 项目 | 详细说明 |
|---|---|
| 本质 | Meta-Standard for Architecture Description（架构描述元标准） |
| 核心要求 | "The architecture description shall identify the architectural styles or patterns used..." （架构描述应标识所使用的架构风格或模式...） 出处：ISO/IEC/IEEE 42010:2011, §6.2d (p.18) |
| 关键澄清 | 标准不提供风格分类： - Annex C 仅举例说明（"Examples of styles are provided for illustration only"） - 标准保持"风格中立"（style-agnostic） |
| 与风格关系 | 要求引用外部风格定义（如Shaw & Garlan），不定义风格本身 |
权威纠正
| 正确表述 | 纠正依据 |
|---|---|
| "ISO 42010要求描述中标识风格，但不提供分类" | ISO/IEC/IEEE 42010:2011, §1.1: "This standard does not prescribe specific styles" |
| Annex C仅为说明性示例，无规范效力 | ISO/IEC/IEEE 42010:2011, Annex C header: "Informative only" |
| 42010验证"是否标识风格"，不验证"风格定义是否正确" | ISO/IEC/IEEE 42010:2011, §7.3: "Conformance is about description completeness, not style validity" |
实践指导
合规描述示例：
"本系统采用Shaw & Garlan (1996)定义的Layered Systems风格（Call/Return类别），具体约束：API Gateway层仅调用Service层，符合单向依赖约束（Shaw & Garlan, p.65）。"
4、Kruchten 4+1 视图模型：描述框架 ≠ 分类体系
定位与核心价值
| 项目 | 详细说明 |
|---|---|
| 本质 | Multi-View Description Model（多视角架构描述模型） |
| 核心思想 | "Describe software architecture using five complementary views" （使用五个互补视图描述软件架构） 出处：Kruchten (1995, p.42) |
| 五视图 | - Logical View: 功能分解（面向用户） - Process View: 并发与同步（面向系统工程师） - Development View: 模块组织（面向开发者） - Physical View: 部署拓扑（面向运维） - Scenarios: 用例驱动（+1视图） |
| 与风格关系 | 风格在视图中体现，非分类对象： - Logical View: 展示Layered风格层次 - Process View: 展示Implicit Invocation并发模型 |
权威纠正
| 正确表述 | 纠正依据 |
|---|---|
| "4+1是架构描述框架，风格在视图中表达" | Kruchten (2009, p.15): "Views are perspectives, not taxonomies" |
| Logical View可表达多种风格（如Repository风格的数据流） | Kruchten (1995, p.45): "The logical view is not tied to a specific architectural style" |
| 视图数量（5）与风格类别（5）纯属巧合 | IEEE Software (2010, Vol.27 No.2): "4+1 is a communication tool, not a classification" |
实践指导
正确使用示例：
- 在Logical View中绘制Layered风格的层次结构
- 在Process View中用Implicit Invocation风格描述事件流
5、CNCF 云原生分类：技术景观 ≠ 学术分类
定位与核心价值
| 项目 | 详细说明 |
|---|---|
| 本质 | Technology Landscape（技术实践景观） |
| 目标 | "Provide a map of cloud native tools and projects for practitioners" （为实践者提供云原生工具与项目的地图） 出处：CNCF (2023), Cloud Native Landscape v1.0 |
| 结构 | 按技术领域分类： - Orchestration & Management - Observability & Analysis - Application Definition & Development - Platform - Security & Compliance |
| 与风格关系 | 无架构风格定义： - "Service Mesh"是技术类别，非架构风格 - "Microservices"是部署模式，非形式化风格 |
权威纠正
| 正确表述 | 纠正依据 |
|---|---|
| "CNCF技术景观（工具分类地图）" | CNCF官方FAQ (2023): "Landscape is not a taxonomy of architectural styles" |
| Microservices是Layered+Implicit Invocation的工业实践变体 | Newman (2015, p.31): "Microservices inherit constraints from layered and implicit invocation styles" |
| Landscape用于工具选型，非风格理论研究 | Bass & Zhu (2022, IEEE Software): "Cloud native patterns must be grounded in formal style theory" |
实践指导
正确映射路径：
- 识别CNCF技术对应的学术风格基础：
- Service Mesh → Client-Server Style（Sidecar代理模式）
- API Gateway → Layered Systems Style（网关层） - 分析新增约束（变体）：
- 服务网格增加"透明流量拦截"约束 - 评估质量属性影响：
- 服务网格提升可观测性，但增加延迟