🏛️ 第四章 · 系统架构设计
系统架构设计
本章是软考高级系统架构设计师最核心的章节，占综合知识考试21%-37%的分值。涵盖软件架构核心概念、架构风格与模式、ABSD与DSSA、架构评估方法等关键知识点。
21%-37%考试分值占比
8知识模块
★★★★★重要程度
15章节测验题
软件架构核心概念
核心考点📐软件架构定义
定义：软件架构是软件系统的组织结构，包括构件、构件之间的连接件、以及指导其设计与演化的约束和原理
核心要素：构件（Component）、连接件（Connector）、配置/约束（Configuration）
架构重要性：决定了系统的质量属性（性能、可用性、安全性、可维护性等）
👁️4+1视图模型
由Philippe Kruchten提出，从五个不同视角描述软件架构，"+1"指的是场景视图驱动其他四个视图。
| 视图名称 | 关注点 | 面向人员 | 描述内容 | 典型工具 |
|---|---|---|---|---|
| 逻辑视图 | 功能需求 | 用户/需求分析师 | 系统提供的功能服务，对象模型 | 类图、对象图 |
| 开发视图 | 软件模块组织 | 开发人员 | 源代码组织结构、模块划分、依赖关系 | 包图、组件图 |
| 进程视图 | 并发与性能 | 系统集成人员 | 进程、线程、任务组织，并发与分布 | 活动图、状态图 |
| 物理视图 | 部署拓扑 | 运维人员 | 软件到硬件的映射，网络拓扑 | 部署图 |
| 场景视图 | 用例驱动 | 所有利益相关者 | 用典型用例场景串联其他四个视图 | 用例图、序列图 |
常考陷阱：4+1视图中描述系统并发和同步机制的是进程视图；描述系统部署到物理硬件的是物理视图；场景视图是"+1"，用于驱动和验证其他四个视图。
🔧架构描述语言（ADL）
构件（Component）：具有独立功能的计算单元，具有明确定义的接口
连接件（Connector）：用于连接构件，实现构件间交互的机制。例如：过程调用、管道、事件广播
架构配置（Configuration）：构件和连接件的拓扑结构描述，定义系统的整体架构组织方式
架构设计原则
基础重点🅰️SOLID 五原则详解
| 原则 | 全称 | 核心含义 | 示例 |
|---|---|---|---|
| SRP 单一职责 | Single Responsibility Principle | 一个类应该只有一个引起变化的原因。每个类只负责一项职责 | 用户类只负责用户数据管理，不应同时负责日志记录和邮件发送 |
| OCP 开闭原则 | Open-Closed Principle | 对扩展开放，对修改关闭。通过抽象和多态实现，新增功能不修改已有代码 | 支付方式扩展：新增支付宝不需要修改支付接口和已有微信支付代码 |
| LSP 里氏替换 | Liskov Substitution Principle | 子类对象可以替换父类对象，程序行为不变。子类不能破坏父类的行为约定 | 正方形继承矩形违反LSP——设置正方形宽度会同时改变高度，破坏了矩形的行为 |
| ISP 接口隔离 | Interface Segregation Principle | 客户端不应依赖它不需要的接口。接口应尽量小而专一 | 将"全能接口"拆分为"打印接口"、"扫描接口"，打印机实现两者，传真机只实现打印 |
| DIP 依赖倒置 | Dependency Inversion Principle | 高层模块不应依赖低层模块，两者都应依赖抽象。抽象不应依赖细节，细节应依赖抽象 | 业务逻辑层依赖"数据库接口"而非具体的"MySQL实现类"，便于切换数据库 |
🎯其他重要原则
高内聚低耦合：模块内部元素紧密相关（内聚性高），模块间依赖尽量少（耦合度低）。内聚类型：功能内聚（最强）> 顺序内聚 > 通信内聚 > 过程内聚 > 时间内聚 > 逻辑内聚 > 巧合内聚（最弱）
关注点分离（SoC）：将系统分解为不同的关注点，每个关注点独立处理。例如MVC将界面、逻辑、数据分离
KISS原则：Keep It Simple, Stupid。设计应尽可能简单，避免不必要的复杂性
DRY原则：Don't Repeat Yourself。系统中每一块知识都应该有单一、明确、权威的表示，避免重复
考试要点：SOLID原则中，OCP（开闭原则）是架构设计中最核心的原则，它是实现可维护性和可扩展性的基础。SRP（单一职责）是最容易识别和违反的原则。
架构风格总览
★★★★★📊Garlan & Shaw 架构风格分类法
| 风格大类 | 具体风格 | 构件 | 连接件 | 典型应用 |
|---|---|---|---|---|
| 数据流风格 | 管道-过滤器、批处理 | 过滤器/处理步骤 | 管道/数据流 | 编译器、ETL、图像处理 |
| 调用/返回风格 | 主程序-子程序、面向对象、分层架构 | 主程序/对象/层 | 过程调用/方法调用 | 大多数应用程序 |
| 独立构件风格 | 进程通信、事件驱动 | 独立进程/组件 | 消息传递/事件广播 | GUI系统、分布式系统 |
| 虚拟机风格 | 解释器、规则系统 | 解释引擎/规则 | 指令执行/规则匹配 | 脚本引擎、专家系统 |
| 仓库风格 | 数据库系统、黑板系统、超文本系统 | 知识源/客户端 | CRUD操作/共享数据访问 | 数据库、AI系统、Wiki |
🔄数据流风格详解
管道-过滤器：数据流经一系列独立处理步骤（过滤器），每个过滤器独立完成特定转换。优点：可复用、可组合、支持并行。缺点：数据转换开销大、不适合交互式系统。适用：编译器（词法→语法→语义→代码生成）
批处理：整个处理过程作为一个步骤执行，每一步独立完成。与管道-过滤器的区别：中间结果需要暂存，非实时流式处理
📞调用/返回风格详解
主程序-子程序：传统结构化编程模型，主程序控制执行流程，子程序实现具体功能
面向对象：通过对象封装数据和行为，对象间通过方法调用交互。核心：封装、继承、多态
分层架构：系统分为多层，每层为上层提供服务，使用下层服务。层间调用仅允许相邻层间进行
⚡独立构件风格详解
进程通信：每个构件是独立进程，通过消息传递或RPC进行通信
事件驱动（隐式调用）：构件不直接调用过程，而是触发事件，系统自动调用注册的事件处理程序。优点：松耦合、高扩展性。缺点：控制流不明确、调试困难。适用：GUI系统、消息驱动架构
💾仓库风格详解
数据库系统：中央数据结构（数据库）+ 独立组件（客户端）。组件通过SQL等操作访问中央数据
黑板系统：中央数据结构（黑板）+ 多个知识源 + 控制模块。知识源独立地读写黑板，控制模块决定哪个知识源被触发。适用：信号处理、语音识别、模式识别
超文本系统：节点（信息单元）+ 链接（导航关系）。适用：Wiki、Web
🖥️虚拟机风格详解
解释器：模拟执行自定义语言或指令。包括：解释引擎、内存状态、指令集合。适用：脚本语言、虚拟机
规则系统：基于规则的推理系统。包括：规则库（if-then规则）、工作内存、推理引擎。适用：专家系统、业务规则引擎
Garlan & Shaw 架构风格分类树
数据流风格
管道-过滤器
批处理
管道-过滤器
批处理
调用/返回风格
主程序-子程序
面向对象 / 分层
主程序-子程序
面向对象 / 分层
独立构件风格
进程通信
事件驱动
进程通信
事件驱动
虚拟机风格
解释器
规则系统
解释器
规则系统
仓库风格
数据库系统
黑板系统 / 超文本
数据库系统
黑板系统 / 超文本
五大类架构风格 — 考试高频考点
经典架构模式详解
★★★★★🏢分层架构
典型四层：表现层（UI）→ 业务逻辑层（Service）→ 数据访问层（DAO）→ 数据库层
优点：职责清晰、易于测试和维护、团队可并行开发、技术替换灵活
缺点：性能开销（层间调用）、可能导致"单调石头"（巨石应用）、可扩展性受限
封闭层 vs 开放层：封闭层只能调用相邻下层；开放层可以跨层调用（牺牲封装换取性能）
🔀MVC / MVP / MVVM 对比
| 对比维度 | MVC | MVP | MVVM |
|---|---|---|---|
| 全称 | Model-View-Controller | Model-View-Presenter | Model-View-ViewModel |
| View与Model关系 | View可以直接访问Model | View不能直接访问Model | View不能直接访问Model |
| 中间层职责 | Controller处理用户输入，选择视图 | Presenter完全负责View与Model的交互 | ViewModel暴露Model数据供View绑定 |
| 数据流 | 双向：View←→Model | 单向：View→Presenter→Model→Presenter→View | 双向绑定：View↔ViewModel↔Model |
| 测试性 | View与Model耦合，测试性一般 | Presenter不依赖UI，易测试 | ViewModel不依赖UI，最易测试 |
| 典型框架 | Spring MVC、Ruby on Rails | Android MVP | Vue.js、WPF、Angular |
| 耦合度 | 较高（View依赖Model） | 低（完全隔离） | 最低（双向绑定） |
常考点：MVC中View可以直接访问Model，这是与MVP最大的区别；MVP中Presenter完全隔离了View和Model；MVVM通过双向数据绑定进一步简化了View层的代码量。
🔬微服务架构
核心特征：将单一应用拆分为一组小型服务，每个服务运行在独立进程中，服务间通过轻量级通信机制（HTTP/REST、RPC）协作
优势：独立部署和扩展、技术栈灵活、故障隔离、团队自治
挑战：分布式事务、服务治理复杂度增加、运维成本上升、数据一致性难以保证
关键组件：API网关（统一入口）、服务注册与发现、配置中心、熔断器、负载均衡
🌐SOA（面向服务架构）
核心思想：将业务功能封装为可复用的服务，通过ESB（企业服务总线）进行服务编排和集成
与微服务区别：SOA使用ESB集中管理，服务粒度较大；微服务去中心化，服务粒度更小
协议：SOAP/WSDL/UDDI、RESTful API
📡事件驱动架构
核心模式：事件生产→事件路由→事件消费。组件通过发布/订阅事件实现解耦
实现方式：消息队列（Kafka/RabbitMQ）、事件总线（Event Bus）、事件溯源（Event Sourcing）
优点：松耦合、高扩展性、支持异步处理
缺点：控制流复杂、调试困难、最终一致性
📋其他重要架构模式
CQRS（命令查询职责分离）：将读（查询）和写（命令）操作分离到不同的模型中，可以独立优化读写性能。常与Event Sourcing结合
六边形架构（端口与适配器）：核心业务逻辑位于中心，通过端口（接口）定义与外部交互，适配器实现具体的技术细节。实现业务逻辑与技术框架的完全解耦
REST：基于资源的架构风格，使用HTTP方法（GET/POST/PUT/DELETE）操作资源。核心约束：无状态、统一接口、可缓存、分层系统
架构风格对比表
速查🔗架构风格全维度对比
| 架构风格 | 核心思想 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 分层架构 | 按层次组织，层间单向依赖 | 职责清晰、易维护、易替换层实现 | 性能开销（层间调用）、级联修改风险 | 企业级Web应用、管理系统 |
| 微服务 | 拆分为独立部署的小型服务 | 独立部署扩展、技术栈灵活、故障隔离 | 分布式复杂度、运维成本高 | 大型互联网系统、快速迭代产品 |
| 事件驱动 | 基于事件发布/订阅机制 | 松耦合、高扩展、异步处理 | 调试困难、最终一致性、消息丢失风险 | 物联网、实时数据处理 |
| SOA | 服务通过ESB编排集成 | 服务复用性高、企业级集成能力强 | ESB单点瓶颈、治理复杂、服务粒度大 | 企业系统集成、遗留系统改造 |
| 管道-过滤器 | 数据流经独立处理步骤 | 高复用、可组合、支持并行处理 | 数据转换开销大、不适合交互式 | 编译器、ETL、图像处理 |
| 黑板 | 多知识源共享中央数据 | 灵活、适合不确定解空间的问题 | 性能难保证、控制策略复杂 | 信号处理、语音识别、模式识别 |
| CQRS | 读写操作分离 | 读写独立优化、可扩展性强 | 实现复杂、数据一致性挑战 | 读写差异大的系统（如电商） |
| REST | 资源导向、统一接口 | 简洁、无状态、可缓存 | 不适合复杂操作、过度获取数据 | Web API、前后端分离 |
ABSD（基于架构的软件开发）
★★★★★📌ABSD三个基础
架构驱动：由功能需求和质量属性需求共同驱动架构设计。不仅考虑功能，更强调性能、可用性、安全性等质量属性
基于特定领域：利用领域内的公共架构和可复用构件，减少重复开发
基于复用：在架构设计过程中积极复用已有的架构模式和构件
📋ABSD六个步骤
| 步骤 | 名称 | 核心内容 | 关键产出 |
|---|---|---|---|
| ① | 架构需求 | 获取功能需求和质量属性需求，使用效用树对质量属性排序 | 质量属性效用树 |
| ② | 架构设计 | 选择架构风格，确定构件和连接件，设计接口 | 架构设计方案 |
| ③ | 文档化 | 记录架构决策及其理由（ADR），使用多视图描述架构 | 架构文档 |
| ④ | 架构复审 | 评估架构是否满足需求，发现潜在问题和风险 | 复审报告 |
| ⑤ | 架构实现 | 基于架构设计进行具体编码实现 | 可运行的软件 |
| ⑥ | 架构演化 | 根据需求变化对架构进行调整和演进 | 新版本架构 |
🌳效用树（Utility Tree）
定义：将质量属性需求从抽象到具体逐层分解的树形结构
层次：根节点（效用）→ 质量属性（性能/可用性等）→ 属性分类（响应时间/吞吐量等）→ 具体场景
优先级标记：每个场景标注（重要性, 实现难度），如（H, M）表示高重要性、中等难度
常考：ABSD六个步骤的顺序是常考点，必须牢记"需求→设计→文档化→复审→实现→演化"。效用树用于质量属性的获取和优先级排序。
ABSD 六步骤流程图
① 架构需求
② 架构设计
③ 文档化
④ 架构复审
⑤ 架构实现
⑥ 架构演化
循环迭代：演化后可重新进入需求阶段
DSSA（特定领域软件架构）
★★★★📐DSSA三层次
领域开发环境：支持领域分析、设计和实现的工具环境
领域特定应用开发环境：基于DSSA开发具体应用的环境
应用执行环境：应用系统最终运行的环境
👥DSSA三类参与人员
领域专家：提供领域知识，定义领域需求和约束
领域设计人员：负责领域分析和架构设计，提取公共架构
领域实现人员：实现可复用的构件和架构
🔄DSSA基本活动
| 活动 | 输入 | 过程 | 输出 |
|---|---|---|---|
| 领域分析 | 领域需求、已有系统 | 识别领域边界、共性/可变点分析 | 领域模型 |
| 领域设计 | 领域模型 | 提取公共架构、设计可复用构件 | DSSA架构 |
| 领域实现 | DSSA架构 | 实现可复用构件和架构 | 可复用构件库 |
架构评估方法
★★★★★🔍三种主要评估方法对比
| 对比维度 | ATAM | SAAM | CBAM |
|---|---|---|---|
| 全称 | Architecture Tradeoff Analysis Method | Software Architecture Analysis Method | Cost Benefit Analysis Method |
| 中文 | 架构权衡分析法 | 软件架构分析法 | 成本效益分析法 |
| 关注点 | 多个质量属性间的权衡 | 架构的可修改性 | 架构变更的成本与效益 |
| 地位 | 最常用、最全面 | 第一个架构评估方法 | 基于ATAM结果进行经济分析 |
| 主要步骤 | 介绍→业务驱动→架构→属性→权衡→风险 | 场景生成→评估影响→综合评估 | 整理策略→计算效益→确定优先级 |
| 输出 | 敏感点、权衡点、风险点、非风险点 | 场景分类（直接/间接）、复杂度评估 | 策略优先级排序、投资回报分析 |
📌ATAM 详细步骤
阶段1（评估团队）：①介绍ATAM方法 ②介绍业务动机 ③介绍架构 ④确定架构方法 ⑤生成质量属性效用树 ⑥分析架构方法
阶段2（利益相关者）：⑦头脑风暴确定场景优先级 ⑧分析架构方法（补充） ⑨展示结果
关键概念：敏感点（影响单一质量属性的架构参数）、权衡点（影响多个质量属性的架构参数）、风险点（可能导致问题的决策）、非风险点（已验证为可行的决策）
敏感点 vs 权衡点：敏感点只影响一个质量属性（如加密算法选择只影响安全性）；权衡点影响多个质量属性（如加密算法选择影响安全性也影响性能）。这是高频考点！
ATAM 评估流程图
① 介绍ATAM
② 业务驱动
③ 介绍架构
④ 确定方法
⑤ 效用树
⑥ 分析方法
阶段1（评估团队）↑ —— ↓ 阶段2（利益相关者）
⑨ 展示结果
⑧ 补充分析
⑦ 场景优先级
📝质量属性场景六要素
| 要素 | 说明 | 示例（性能场景） |
|---|---|---|
| 刺激源 | 产生刺激的实体 | 用户提交订单请求 |
| 刺激 | 到达系统的事件 | 同时1000个并发用户提交 |
| 环境 | 刺激发生时系统状态 | 系统在正常运行状态下 |
| 制品 | 被刺激影响的系统部分 | 订单处理子系统 |
| 响应 | 系统对刺激的反应 | 系统处理所有请求并返回结果 |
| 响应度量 | 度量响应的量化指标 | 平均响应时间≤2秒，成功率≥99.9% |
记忆技巧：六要素可以用"谁（刺激源）→做了什么（刺激）→在什么情况下（环境）→影响了什么（制品）→怎么应对（响应）→效果如何（响应度量）"来记忆。
章节测验
15题🏛️ 第四章 · 系统架构设计
第 1/15 题