系统架构设计师核心考点：质量属性与架构权衡

如果系统架构设计师的备考只能保留一个考点，我会留质量属性。

原因很直接：案例分析里几乎所有问法，追到最后都是在问「这个方案如何提升了某个质量属性」；论文里那条主线，本质上也是在论述「我为了满足某个质量属性，做了哪些取舍」。把质量属性这套语言用熟，等于同时给案例和论文打好了地基。

一、六大质量属性：先记住它们各自在问什么

质量属性描述的是「系统在运行或修改时表现出的、可以被度量的特征」。考试里最常出现的六个是：

质量属性	它在问什么	典型战术关键词
性能	单位时间能处理多少、响应多快	资源调度、引入并发、减少计算开销、缓存
可用性	出故障时还能不能提供服务	心跳、冗余（主备/集群）、检查点回滚、故障转移
安全性	能否抵抗攻击、保护数据	身份认证、授权、审计、加密、限制访问
可修改性	改一处要动多少地方	关注点分离、封装、分层、延迟绑定
易用性	用户学习与使用的成本	任务模型、用户模型、界面分离、在线帮助
可测试性	能不能方便地验证正确性	记录回放、接口分离、内置监控、断言

记忆的时候不要背定义，要背**「这个属性对应什么度量」**。性能的度量是响应时间和吞吐量，可用性的度量是可用时间比例或故障恢复时间，可修改性的度量是修改一个功能点所需的工作量。没有度量的质量属性描述，在答题时基本拿不到分。

二、质量属性场景的六要素：把形容词变成可验证的句子

「系统要高可用」不是需求，是愿望。架构评审要求把它写成一个可验证的场景，标准写法包含六个要素：

1. 刺激源：谁或什么发起
2. 刺激：发生了什么
3. 环境：在什么状态下发生
4. 制品：被影响的部分
5. 响应：系统做了什么
6. 响应度量：如何判定做得好

我用一份 YAML 记录项目里的场景，写起来比散文更容易检查是否完整：

场景名称：数据库主节点故障时的服务连续性
刺激源：数据库主节点（内部）
刺激：     主节点进程崩溃
环境：     系统正常运行时
制品：     数据库集群与后端服务
响应：     检测到故障，自动切换到备节点，期间请求被重试或降级
响应度量： 故障检测 < 5s，切换完成 < 30s，年不可用时间 < 5 分钟

答题时这六要素不需要全写出来，但响应度量一定要出现。它是最能体现「你真的理解这个属性」的部分，也是很多人漏掉的得分点。

我甚至写了个小脚本在整理素材时做自检，确认每个场景都填齐了六要素：

# check_scenarios.py —— 检查质量属性场景是否六要素齐全
import re
from pathlib import Path

KEYS = ["刺激源", "刺激", "环境", "制品", "响应", "响应度量"]

for path in sorted(Path("scenarios").glob("*.txt")):
    text = path.read_text(encoding="utf-8")
    missing = [k for k in KEYS if not re.search(rf"^{k}\s*[:：]\s*\S", text, re.M)]
    if missing:
        print(f"[缺] {path.name}: {', '.join(missing)}")
    elif not re.search(r"\d", text.split("响应度量")[-1]):
        print(f"[度量无数字] {path.name}")
    else:
        print(f"[OK] {path.name}")

这个脚本本身没什么技术含量，但它逼着我每次都用同一套结构，而考场上要的正是这种结构化的表达习惯。

三、战术：从「想要什么」到「怎么做」

战术是达成质量属性的具体手段，是案例题最爱考的一层。每类属性记三到五个就够用了：

可用性战术分三组：

• 错误检测：心跳、Ping/Echo、异常监控、超时
• 错误恢复：冗余（主备、集群、冗余 spare）、检查点回滚、重试、降级
• 错误预防：移除单点、事务、进程监控、服务下线预告

性能战术分两组：

• 资源需求侧：减少计算开销（缓存、预计算）、控制资源使用（限流、优先级队列）、减少间接层
• 资源管理侧：引入并发、资源调度（负载均衡、线程池）、增加资源、引入异步

可修改性战术的关键词是「降低耦合」：关注点分离、封装、使用中间层、延迟绑定、限制依赖。

把这些战术和现实对应起来，其实一点都不抽象。心跳就是健康检查，冗余就是多实例部署，检查点回滚就是数据库的 WAL 和事务日志，资源调度就是负载均衡与线程池。考试里的战术名词，绝大多数你在生产环境里已经用过，只是没这么叫。

四、ATAM：评估方法，也是答题框架

架构权衡分析方法（ATAM）是架构评估的经典方法，考试既可能考它的步骤，也可能考它的概念。它的完整流程我习惯记成四阶段九步：

1. 介绍阶段：介绍 ATAM 方法、介绍业务驱动因素、介绍待评估的架构
2. 调查与分析阶段：识别架构方法、生成质量属性效用树、分析架构方法
3. 测试阶段：头脑风暴并确定场景优先级、再次分析架构方法
4. 报告阶段：展示评估结果

其中**效用树（Utility Tree）**值得单独记：根节点是「效用」，第二层是质量属性，第三层细化到具体场景，每个场景用「重要性」和「实现难度」两个维度打 H/M/L 标记，用来决定优先分析哪些场景。这个工具在真实评审里也很好用——它把「大家觉得哪个更重要」的口水仗，变成了一个可以排序的清单。

五、四个容易混淆的概念

这四个点是选择题和案例题的高频混淆项，我用一句话区分：

概念	定义	例子
敏感点	对某一个质量属性有显著影响的决策	加密强度直接影响安全性
权衡点	同时影响多个质量属性、且方向相反的敏感点	加密强度越高，安全性越好，性能越差
风险点	可能导致问题的架构决策（尚未验证）	引入缓存但未定义失效策略
非风险点	经过分析认为可接受、安全的决策	已通过压测验证的连接池配置

关键区别在于：敏感点只关乎一个属性，权衡点关乎多个且互相冲突，风险点是「可能有问题」，非风险点是「确认没问题」。 案例题让你「识别该设计中的敏感点与权衡点」，答题时一定要把「影响哪两个属性、方向如何」说清楚，只写一个词是拿不满分的。

六、一张可以直接对照的答题表

质量属性	高频战术	常见考题问法
性能	缓存、引入并发、负载均衡、异步化	「该系统如何满足高并发下的响应时间要求」
可用性	心跳检测、主备冗余、故障转移、降级	「如何保证系统在节点故障时仍可服务」
安全性	认证、授权、加密、审计、限流	「说明该方案在数据安全方面的设计」
可修改性	分层、封装、中间层、延迟绑定	「该架构如何支持业务功能的快速扩展」
易用性	界面与逻辑分离、任务模型、帮助机制	「从易用性角度评价该设计方案」
可测试性	接口分离、内置监控、记录回放	「如何提高该系统的可测试性」

答题时按这个顺序组织：先点出质量属性 → 再说采用的战术 → 最后给出响应度量或效果。三步齐了，一段答案就成型了。

七、这套语言在工程里同样管用

我一开始也怀疑过：这些术语是不是只在考试里有意义？

后来在一次真实的技术评审上，我试着用这套结构描述一个方案：「这个改动是个权衡点——引入本地缓存提升了读性能，代价是可修改性下降（每加一个实例就多一份不一致的窗口），我建议用短 TTL 把窗口压到可接受范围，并把失效策略写进接口约定。」讨论很快从「要不要加缓存」收敛到「TTL 定多少、失效谁负责」。

这就是我改变看法的原因：质量属性、场景六要素、敏感点与权衡点，本质是一套让技术讨论可收敛的语言。 考试要求的表达方式并不脱离工程实践，它只是把工程里那些靠经验传递的模糊判断，说成了可以互相检查的句子。

所以我的建议是：不要把质量属性当背诵材料。挑一个你熟悉的系统，用六要素给它写三个场景，用战术词汇解释它现有的设计，再找出两个权衡点。做完这一遍，案例和论文都会轻松很多。