本篇将围绕质量属性与架构评估进行系统性梳理。
- 首先介绍质量属性的概念及其在架构设计中的地位，帮助理解"非功能性需求"对系统整体质量的关键作用。
- 随后，通过归纳六大典型质量属性，明确每类属性在实际案例题中的识别方法与关注要素。
- 接着，结合质量属性场景六要素，展现如何将抽象的属性落地为可分析、可验证的具体场景。
通过这些知识点的有机结合，读者能够系统掌握如何识别场景中的质量属性、合理权衡架构决策，并在答题时条理清晰地展开论述，提升架构评估与答题的实战能力。
范围说明： 非功能性需求在工程实践与标准体系（如 ISO/IEC 25010 等）中的划分更广，还可能涉及兼容性、可移植性、合规性等维度。本文以案例题高频的六大质量属性 为主线，便于应试识别与作答；并不企图覆盖非功能需求的全集，与业界完整质量模型并非一一对应。
一、质量属性概述
1. 什么是质量属性
质量属性是衡量系统"好不好用"的非功能性指标。它不关心系统"能做什么"，而是关心系统在做这些事时，能做到"多快、多稳、多安全、多好改"。
软件架构的核心任务之一，就是在多个质量属性之间做出权衡------因为它们往往互相制约（例如加密提升安全性但可能降低性能）。
2. 案例题中的六大质量属性
| 质量属性 | 核心关注点 | 典型场景信号词 |
|---|---|---|
| 性能 | 系统在给定约束下的响应速度与吞吐能力 | 响应时间、吞吐量、并发数、延迟、CPU |
| 可用性 | 系统在出现故障时继续提供服务的能力 | 故障恢复、切换时间、容灾、备份、冗余 |
| 安全性 | 系统抵御非授权访问和攻击的能力 | 加密、认证、授权、攻击检测、敏感数据 |
| 可修改性 | 系统适应变更的能力与成本 | 扩展、替换模块、规则变化、工期/人月 |
| 可测试性 | 系统被测试验证的难易程度 | 测试接口、模拟、自动化测试、验证 |
| 易用性 | 用户使用系统的便利程度 | 引导、多终端适配、无障碍、学习成本 |
二、质量属性场景六要素
1. 定义
质量属性场景是将抽象的质量属性转化为可度量、可验证、可设计的具体目标。它由六个要素构成。
2. 六要素详解
| 要素 | 含义 | 通俗理解 | 举例 |
|---|---|---|---|
| 刺激源 | 触发事件的主体 | 谁触发的 | 用户、黑客、外部系统、运维人员 |
| 刺激 | 触发的具体事件 | 发生了什么 | 发起请求、发动攻击、提交变更、系统崩溃 |
| 环境 | 事件发生时的运行上下文 | 在什么条件下 | 正常负载、高峰期、弱网、恶劣天气 |
| 制品 | 被事件影响的系统构件 | 作用到谁 | 整个系统、某个模块、某个接口 |
| 响应 | 系统对刺激的行为 | 系统怎么做 | 返回数据、切换备份、记录日志、拒绝访问 |
| 响应度量 | 对响应是否合格的度量 | 做到什么程度算合格 | 3 秒内响应、恢复时间 < 5 分钟、CPU < 40% |
3. 案例题中的应用
题目常见做法是给出一段文字描述，让你判断属于六要素中的哪个。
示例：
"集成第三方支付平台的新 API 需在 3 个工作日内完成。"
分析：
- "集成第三方支付平台的新 API" -> 刺激（需要应对的变更事件）
- "3 个工作日内完成" -> 响应度量（对完成速度的量化约束）
"单点故障发生时间不超过 5 分钟。"
分析：
- "单点故障发生" -> 刺激
- "不超过 5 分钟" -> 响应度量
三、每种质量属性的详细内容
1. 性能
定义： 系统在特定约束条件下（如并发量、负载量），完成任务的速度与吞吐能力。
常见度量指标：
- 响应时间（Latency）
- 吞吐量（Throughput）
- 资源利用率（CPU、内存、I/O）
常见架构战术：
| 战术分类 | 具体手段 | 说明 |
|---|---|---|
| 资源需求 | 减少计算开销 | 算法优化、减少不必要的计算 |
| 资源需求 | 减少被处理事件数 | 采样、过滤、批处理 |
| 资源管理 | 引入并发 | 多线程、多进程、异步处理 |
| 资源管理 | 数据副本 | 缓存、CDN、读写分离 |
| 资源仲裁 | 调度策略 | FIFO、优先级队列、时间片轮转 |
案例题考法示例：
题干："用户发起充电请求后，系统需在 3 秒内响应。"
答：该场景属于性能质量属性。刺激是用户发起请求，响应度量是 3 秒内完成响应。
2. 可用性
定义： 系统在出现故障、攻击或其他异常时，继续正常运行或快速恢复的能力。常用"几个 9"表示（如 99.99% = 年停机 < 53 分钟）。
常见度量指标：
- 故障检测时间
- 故障恢复时间
- 系统可用率
常见架构战术：
| 战术分类 | 具体手段 | 说明 |
|---|---|---|
| 故障检测 | 心跳检测（Heartbeat） | 周期性探测存活 |
| 故障检测 | Ping/Echo | 主动探测响应 |
| 故障检测 | 异常检测 | 超时、错误率阈值 |
| 故障恢复 | 主动冗余（热备） | 多副本同时运行 |
| 故障恢复 | 被动冗余（温备/冷备） | 备份节点待命 |
| 故障恢复 | 故障转移（Failover） | 自动切换到备份 |
| 故障恢复 | 回滚（Rollback） | 恢复到上一个正确状态 |
| 故障预防 | 进程监控 | 监控守护进程 |
| 故障预防 | 事务机制 | 保证操作原子性 |
案例题考法示例：
题干："网络故障后，系统需在 10 秒内启用备份系统。"
答：该场景属于可用性 。系统需要具备故障检测 （发现网络异常）与故障恢复（自动切换备份）能力，响应度量为 10 秒。
3. 安全性
定义： 系统在提供服务的同时，抵御非授权访问、数据泄露、篡改与攻击的能力。
三大核心属性（CIA）：
- 机密性（Confidentiality）：数据不被未授权访问
- 完整性（Integrity）：数据不被非法篡改
- 可用性（Availability）：合法用户能正常访问（安全上下文中特指不被 DoS 等攻击中断）
常见架构战术：
| 战术分类 | 具体手段 |
|---|---|
| 抵抗攻击 | 身份认证、访问控制、数据加密、输入验证 |
| 检测攻击 | 入侵检测系统（IDS）、日志审计、异常行为分析 |
| 恢复 | 审计追踪、数据备份与恢复 |
案例题考法示例：
题干："用户敏感信息采用 AES-256 加密存储与传输。"
答：该场景属于安全性 。采用 AES-256 加密是抵抗攻击 战术中"数据加密"手段，保障数据机密性。
4. 可修改性
定义： 系统在发生变更（新增功能、修改规则、替换组件）时，所需的成本与工作量。
常见度量指标：
- 完成变更需要的人力（人天/人月）
- 变更影响范围
- 变更引入缺陷的风险
常见架构战术：
| 战术分类 | 具体手段 |
|---|---|
| 局部化修改 | 模块化、高内聚低耦合、信息隐藏 |
| 防止连锁反应 | 接口隔离、使用中间件、依赖倒置 |
| 延迟绑定 | 配置文件、插件机制、运行时注册、多态 |
案例题考法示例：
题干："集成新 API 需在 3 个工作日内完成。"
答：该场景属于可修改性。度量标准是完成变更的时间（3 个工作日），反映系统适应外部接口变更的能力。
5. 可测试性
定义： 通过测试来发现软件缺陷的难易程度。
常见架构战术：
- 提供测试接口 / 测试桩
- 记录与回放机制
- 模块间解耦便于单元测试
- 监控与日志便于定位问题
案例题考法示例：
题干："系统需模拟恶劣天气下的充电场景进行测试。"
答：该场景属于可测试性。系统需要具备模拟极端环境进行验证的能力。
6. 易用性
定义： 用户使用系统的便利程度，包括学习成本、操作效率和满意度。
常见度量指标：
- 完成任务所需时间
- 用户错误率
- 学习曲线
常见架构战术：
- 任务引导（Wizard）
- 多终端适配（响应式设计）
- 多语言支持
- 无障碍设计（Accessibility）
- 撤销/恢复操作
案例题考法示例：
题干："用户首次使用需在 30 秒内完成核心功能引导。"
答：该场景属于易用性。关注用户上手效率与学习成本。
四、效用树（Utility Tree）
1. 什么是效用树
干系人嘴里常常是「系统要成功、体验要好、别出事」这类大而空 的话。ATAM 评估时不能停在空话上，必须把「成功」拆成能开会讨论、能写进方案、能验收是否做到 的一条条目标。效用树 就是干这个的：一棵树，从根到叶，把抽象「效用」落成带数字、带时限、带条件的具体场景。
可以把它想成写可打勾的清单 ：根节点是「项目效用」，中间几层是「关心哪几类质量」，叶子是「在什么条件下，谁触发什么事，系统该怎么表现，怎么验收」------和后面「质量属性场景六要素」是同一套思维，只是用树收拢在一页里。
叶子旁常会标 H / M / L （优先级）和难度 ，意思是：先盯又重要又难的，别平均用力。
2. 从根到叶：每一层在干什么
把「效用」逐级细化的典型路径如下（不必死记名词，抓住越往下越具体、越可验收即可）：
效用 -> 质量属性 -> 质量属性细化（可选）-> 具体场景（可度量、可对应题干）| 层级 | 人话 | 网约车直觉 |
|---|---|---|
| 效用 | 整棵树的根：「系统上线后算不算成功」的总目标 | 平台能持续商业运营、用户愿意用 |
| 质量属性 | 成功拆成几大维度：快、稳、安全、好改...... | 性能、安全、可用、可修改等分支 |
| 细化（可选） | 某一属性下再分小类 | 性能下再分「响应」与「确认速度」 |
| 叶子：具体场景 | 带刺激/环境/响应 痕迹的句子，常带数字或时限 | 「正常负载下响应小于 0.5 秒」「支付后 3 秒内确认」 |
括号里的 (a)(b)(c ) 在试卷里一般是场景编号 ：题干会给你若干条描述，每个字母对应一条，树上填空就是把编号挂到正确的分支下。
3. 示例：怎么读一棵树（网约车）
下面是一棵示意树（与案例题「给树填空」的版式接近）。读的时候：自上而下 选分支，最底下 一行一句场景；括号内字母即场景编号。
text
效用
├── 性能
│ ├── 响应时间：正常负载下操作响应 < 0.5 秒 (c)
│ └── 确认速度：支付后 3 秒内确认 (k)
├── 安全性
│ ├── 防攻击：检测并抵御黑客攻击 (b)
│ └── 数据保护：敏感数据加密 (j)
├── 可用性
│ ├── 故障转移：实例故障 2 分钟内切换 (g)
│ └── 容灾：网络故障 10 秒内启用备份 (f)
└── 可修改性
├── 界面变更：Web 界面变更 4 人周内完成 (i)
└── 组件扩展：新增中间件 10 人月内完成 (l)快速对号入座（抓关键词）：
| 分支 | 叶子里的信号词 | 和别的分支别混 |
|---|---|---|
| 性能 | 秒、毫秒、负载、并发、响应、吞吐 | 「快」≠ 可用性里的「切换时间」是性能还是可用？------用户侧体验快慢 多归性能；故障后多久恢复服务多归可用性 |
| 安全性 | 攻击、加密、认证、泄露、非法访问 | 见前文「安全性 vs 可靠性」 |
| 可用性 | 故障、切换、备份、容灾、冗余 | 与「性能」区分见上表 |
| 可修改性 | 人周、人月、工期、替换模块、扩展 | 与「可测试性」区分见前文 |
4. 案例题怎么考
常见题型：
- 树上有空白质量属性 （某一级节点名缺失），根据同分支下已有叶子 或题干场景列表补全
- 树上有空白场景编号 ，题干里多条描述 (a)～(l)，把编号填回对应叶子
- 与「效用树」配套的有时是质量属性场景表述，先归类再填树
答题方法（抓关键词）：
| 步骤 | 做什么 |
|---|---|
| 1 | 扫题干场景列表 ：每条用笔画出时间数字、故障/攻击、变更工期等锚点 |
| 2 | 先定质量属性 ：用第一节 「六大质量属性」表 + 第七节 易混辨析，一条场景只归一个主属性（不确定时先排除最不可能的） |
| 3 | 对照树已有节点 ：看空缺在第几层------缺的是大分支名还是叶子编号 |
| 4 | 回填 ：属性名用教材常用词（性能/可用性/安全性/可修改性/可测试性/易用性）；编号与题干字母一一对应，勿串行 |
| 5 | 再检查：性能 vs 可用性、安全性 vs 可靠性是否混了 |
五、ATAM 架构评估方法
1. 什么是 ATAM
ATAM （Architecture Tradeoff Analysis Method，架构权衡分析方法）是在系统大规模开工之前 ，带着「性能、可用、安全......」这些质量目标去审架构：哪里可能达不到目标、哪里一动就牵全身、哪里必然顾此失彼。
把它想成给架构做体检 + 会诊：不问具体代码怎么写，而问------按现在这版设计，上线后最可能在哪些质量属性上翻车？翻车前能不能提前看见？
2. ATAM 评估的四个关键概念
| 概念 | 通俗理解 | 记法 |
|---|---|---|
| 风险点 | 设计里已经露出来的隐患 ：照现在这样走，质量目标有可能达不到 | 「还没兜住」 |
| 非风险点 | 针对某个目标，已经有靠谱手段把隐患压住了 | 「已经兜住」 |
| 敏感点 | 架构里某个旋钮 ：拧一点点 ，某一个质量属性就变化很大 | 「一动就放大」 |
| 权衡点 | 某个决策同时踩中多条质量属性 ，往往抬一个、压一个 | 「跷跷板」 |
易混辨析：
- 敏感点 vs 权衡点 ：敏感点强调「对某一个 质量属性特别灵」；权衡点强调「至少两个 质量属性绑在一起，难以两全」。教材里常把「既是 A 的敏感点，又是 B 的敏感点」叫权衡点------也就是一个决策同时在多条属性上都很「灵」且方向相反时，就是典型权衡点。
- 风险点 vs 敏感点 ：敏感点只说明「这里很灵」；是不是风险还要看目标与有没有补偿------同样「加密很强」，若业务能接受延迟，性能方面未必仍判为风险。
3. 一条例子串起来（电商下单）
假设题干描述：订单服务直连单库 MySQL；库存扣减采用同步事务；高峰期数据库 CPU 常打满；已做读写分离与主从热备，读走从库。
| 概念 | 套在这条链路上怎么说 |
|---|---|
| 风险点 | 写仍集中在主库，促销时订单写入可能超时 → 性能/可用性目标有落空可能；若题干未提限流、分库分表、异步化等，应判为风险。 |
| 非风险点 | 读 已分流到从库，「读多写少」里的读压力 已被读写分离兜住 → 对「读性能」这一项可写成非风险点（与题干一致时）。 |
| 敏感点 | 连接池大小、同步事务边界、超时时间 ：数值略调，延迟和成功率波动就很明显 → 典型敏感点（对性能/可用性「一动就放大」）。 |
| 权衡点 | 「同步强一致扣库存」 ：一致性高，但主库写入压力大、峰值吞吐与延迟 差 → 一致性 vs 性能 跷跷板，常作为权衡点作答。 |
答题时不必背整条电商，抓住题干已给出的决策 + 已给出的缓解措施：有缓解且对得上目标 → 偏非风险；只提问题没提手段 → 偏风险。
4. ATAM 评估流程
- 描述架构：把关键组件、数据流、部署讲清楚
- 生成效用树：把质量属性拆成可讨论的具体场景
- 场景优先排序 ：先盯又重要又心里没底的
- 分析架构决策：对高优先场景逐个问「靠啥手段满足？还有啥隐患？」
- 识别风险点、敏感点、权衡点（有时非风险点也会写进结论）
- 形成评估报告：汇总风险与改进建议
5. 案例题怎么考
- 给出架构方案与若干描述，让你判断哪些是风险 / 非风险 / 敏感 / 权衡
- 让你说明某个架构决策为什么是权衡点 （一般要写出波及的至少两个质量属性 及相反方向）
答题要点（抓关键词）：
| 判什么 | 怎么写最稳 |
|---|---|
| 权衡点 | 写清「一个决策 → 属性甲提升、属性乙下降」（或延迟换安全等） |
| 敏感点 | 写清「哪个参数/哪层设计 → 对某一属性影响特别大」 |
| 风险点 | 写清「在什么负载/攻击/故障下 → 哪条质量目标可能达不到」 |
| 非风险点 | 写清「针对哪条目标 ，已有何种手段 （冗余、备份、限流等）且与题干一致」 |
六、质量属性战术汇总表
| 质量属性 | 战术大类 | 典型手段 |
|---|---|---|
| 性能 | 资源需求 | 减少计算、批处理、异步 |
| 资源管理 | 缓存、CDN、读写分离、并发 | |
| 资源仲裁 | 调度策略、优先级队列 | |
| 可用性 | 故障检测 | 心跳、Ping/Echo、异常阈值 |
| 故障恢复 | 冗余、故障转移、回滚 | |
| 故障预防 | 进程监控、事务 | |
| 安全性 | 抵抗攻击 | 认证、授权、加密、验证 |
| 检测攻击 | IDS、审计、行为分析 | |
| 恢复 | 审计追踪、备份恢复 | |
| 可修改性 | 局部化 | 模块化、高内聚低耦合 |
| 防连锁 | 接口隔离、中间件、依赖倒置 | |
| 延迟绑定 | 配置文件、插件、多态 | |
| 可测试性 | 输入/输出 | 测试接口、测试桩、Mock |
| 内部监控 | 日志、监控、记录回放 | |
| 易用性 | 运行时 | 引导、撤销、适配、多语言 |
| 设计时 | 用户模型、无障碍标准 |
七、常见易混淆辨析
性能 vs 可用性
- 性能关注"快不快"：响应时间、吞吐量。
- 可用性关注"挂不挂"：故障检测、恢复、持续服务。
当题目说"正常负载下 0.5 秒响应" -> 性能 。
当题目说"故障后 10 秒切换备份" -> 可用性。
可用性 vs 可靠性
- 可靠性 关注「错不错」：在规定条件与时间范围内，系统能否持续、正确地完成规定功能；强调抵御随机故障、避免错误结果。常见信号：MTBF、容错、恢复块、N 版本程序设计、表决与冗余计算等。
- 可用性 关注「在不在」：授权用户在需要时能否访问并得到服务 ；强调可服务时间与中断后的恢复。常见信号：可用率（如 99.9%）、RTO/RPO、故障检测与切换时间、双活/灾备、冗余是为了尽快恢复对外服务。
两者相关：工程上常一起出现（高可用依赖冗余与容错）。粗略理解：可靠性偏「少出故障、出了也能算对」；可用性偏「出了故障多快能继续用」 。可用性与 MTBF、MTTR 都有关（例如可用性可表示为 MTBF / (MTBF + MTTR)），题目若突出切换时长、容灾等级、年可用性指标 多归为 可用性 ；若突出容错结构、多样表决、防算错 多归为 可靠性。
当题目说"容错、恢复块、N 版本、表决" -> 偏 可靠性 。
当题目说"故障后 10 秒切换、两地三中心、年可用性 99.99%" -> 偏 可用性。
可修改性 vs 可测试性
- 可修改性关注"改起来贵不贵"：变更工期、影响范围。
- 可测试性关注"测起来难不难"：能否方便地验证。
当题目说"3 个工作日内完成新 API 集成" -> 可修改性 。
当题目说"支持模拟恶劣天气场景测试" -> 可测试性。
安全性 vs 可靠性
- 安全性防的是"人"：黑客、非法访问、数据泄露。
- 可靠性防的是"故障"：硬件失效、软件缺陷、环境异常。
当题目说"抵御攻击、加密数据" -> 安全性 。
当题目说"容错、恢复块、N 版本" -> 可靠性。
八、答题模板
场景归类题
该场景属于 [质量属性] 。因为题目强调的是 [关键特征] ，体现了系统在 [能力方面] 的要求。
效用树填空题
- 先看已有项，确定已知的质量属性
- 逐条分析剩余场景的关键词
- 按"性能/安全/可用/可修改"四大分支归类
- 填入对应的属性名或场景编号
ATAM 概念辨析题
[某决策] 是 权衡点 。因为该决策同时影响 [质量属性A] 和 [质量属性B]：提升 A 的同时会导致 B 下降。