上一篇讲了架构风格——那是「架构长什么样」。这一篇讲架构评估——那是「这个架构到底好不好怎么证明」。两者在教材里前后相邻在考卷上也经常一起出现风格题考你识别评估题考你判断。一、架构评估在评什么先说清楚一个前提否则后面的方法会显得很玄。架构评估最大的特点是它不运行代码。评估发生在详细设计和编码之前此时系统还不存在你没法压测、没法看监控。那怎么判断架构好坏答案是用场景当探针。思路是这样的架构决策会影响质量属性性能、可用性、可修改性等而质量属性可以写成具体的、可度量的场景。于是只要把场景往架构上一放就能看出这个架构在哪些场景下会吃力——这是一种绕过实现、直接推理的评估方式。所以场景的质量直接决定评估的质量。这就引出了那个必考的六要素要素含义例子主库宕机场景刺激源谁发起的刺激数据库节点刺激发生了什么主库宕机环境发生时的系统状态系统正常运行中制品受影响的部分主库与数据访问服务响应系统应该做什么检测故障 → 切换备库 → 恢复连接 → 告警响应度量响应的量化标准30 秒内切换、5 分钟内恢复六要素缺一不可且响应度量必须量化。只写提高性能是不得分的必须落到响应时间小于 1 秒可用性 99.99%这种可核对的标准上。教材里质量属性场景主要关注六类可用性、可修改性、性能、可测试性、易用性、安全性。二、SAAM最早的架构分析方法SAAMSoftware Architecture Analysis Method是最早形成文档、并被广泛使用的架构分析方法。它的出身很具体——最初就是为了分析架构的可修改性后来才扩展到其他质量属性。它的五步流程如下步骤做的事1场景开发各类风险承担者协商开发能体现系统活动或未来变化的场景2软件体系结构描述用各方都能理解的表示法描述架构计算构件、数据构件、连接关系3单个场景的评估把场景分类为直接场景与间接场景分别处理4场景交互的评估找出需要修改同一批构件的场景衡量构件的划分质量5总体评估按重要性给场景和场景交互赋权值加权得出总体评价直接场景 vs 间接场景核心概念这是 SAAM 里最容易考、也最容易记反的一组类型定义处理方式直接场景现有架构已经能够支持的场景说清架构是如何实现它的间接场景需要对现有构件/连接件做出修改才能支持的场景列出所需修改并估算改动代价记忆钩子改不动的叫直接要动刀的叫间接。场景交互为什么重要如果两个语义上不相干的间接场景却需要修改同一个构件这说明什么说明这个构件承担了本该分开的职责——功能划分不合理。反过来语义相近的场景交互在同一个构件上是正常的。所以场景交互评估本质上是在检测架构的关注点分离做得如何。这一点在案例题里经常作为请分析该架构存在什么问题的答案素材。三、ATAM四阶段九步ATAMArchitecture Tradeoff Analysis Method是 SAAM 的演进。它名字里的Tradeoff权衡就是核心差异SAAM 主要看架构满足不满足某个质量属性ATAM 进一步看多个质量属性之间如何互相牵制。ATAM 关注的质量属性通常是四类性能、安全性、可修改性、可用性。九个步骤按四个阶段组织死记九步容易乱按阶段记就稳了阶段步骤关键输出一 呈现1 呈现 ATAM 方法参与者对方法的理解2 呈现商业动机重要质量属性需求清单3 呈现架构对架构方法的初步理解二 调查与分析4 识别架构方法已采用的架构风格/战术目录5 生成质量属性效用树标注重要度与难度的场景集合6 分析架构方法敏感点、权衡点、风险点、非风险点三 测试7 头脑风暴并确定场景优先级全体干系人投票产生的排序8 再次分析架构方法更多四类判定交叉验证步骤 6四 报告9 呈现评估结果评估报告三个年年考的易混点第一步骤 4 只识别、不分析。这一步是把已有的架构方法登记下来分析推迟到步骤 6。如果选项说步骤 4 用于评估架构方法的优劣是错的。第二两批人、两批场景。步骤 5 的效用树场景来自项目决策者一侧步骤 7 再由更广泛的干系人头脑风暴补充并投票。这个设计是刻意的——防止评估被小圈子的需求绑架。第三步骤 6 与步骤 8 做的事同构。都是针对场景分析架构、产出四类判定区别只在场景来源一个来自效用树一个来自集体头脑风暴。两者互为交叉验证所以这个阶段叫测试。ATAM 的三类参与角色角色类别具体角色评估小组评估负责人、场景书记员、进度书记员、过程观察员项目决策者架构师、项目经理、客户代表其他项目干系人开发、测试、运维等受架构影响的人注意参与时机的差异步骤 1–6 只有评估小组与项目决策者参与步骤 7 起更广泛的干系人才加入头脑风暴并投票。评估通常分两天或两次集会进行。四、效用树ATAM 的核心工具效用树Utility Tree是把系统好不好这个模糊问题结构化的工具。它的结构是四层层级内容例子第 1 层根效用系统整体效用第 2 层质量属性性能、可修改性、可用性、安全性第 3 层属性细化响应时间、吞吐量、可扩展性第 4 层叶场景具体的、可测试的场景叶节点要标注优先级对重要度, 难易度各取 H / M / L。例如(H, M)高并发下单响应小于 1 秒——重要但实现有中等难度(H, L)重要且容易实现——这类应该优先处理投入产出比最高(M, L)中等重要、容易实现效用树生成后会经过修剪通常只保留不超过 50 个场景。为什么要修剪因为效用树是给后续步骤 6 做分析用的输入场景太多会导致分析无法收敛。效用树的结构包括树根—质量属性—属性分类—质量属性场景叶子节点重点记忆五、四类判定案例题的给分点这是整章最有得分感的一块。ATAM 的分析结论最终落在四个概念上案例题几乎每年都出现。类别定义一句话识别敏感点一个或多个构件和/或构件之间关系的特性对实现某个质量属性至关重要「它一变某个属性跟着变」权衡点影响多个质量属性的敏感点「它一变好几个属性一起变有好的有坏的」风险点可能导致问题的架构决策不支持某项质量属性或对其有负面影响「这样设计某个属性恐怕达不成」非风险点经分析确认没有问题的架构决策有时本身就是优势「这样设计没问题可以放心」关键理解这是两个独立维度很多资料把四者串成一条判断链容易把人绕晕。更准确的理解是两个互相独立的维度维度一影响范围影响一个属性 → 敏感点影响多个属性 → 权衡点维度二风险性质可能危及目标 → 风险点确认无虞 → 非风险点同一个决策完全可以既是权衡点、又是风险点。比如为了提高吞吐量把连接池调到 500它同时影响性能和资源占用权衡点如果评估发现高并发下会导致内存告罄那它同时也是风险点。用一道典型题收尾「提高加密级别」属于哪一类加密级别提高安全性变好、性能变差——一个决策影响多个质量属性因此是权衡点。这也是教材里频繁出现的原例。六、三种评估方法对比维度SAAMATAMCBAM定位最早的架构分析方法SAAM 的演进进一步引入经济视角关注点以可修改性为主多质量属性的权衡性能/安全性/可修改性/可用性成本与收益ROI决策核心工具场景、场景交互效用树 四类判定成本效益模型流程规模5 步四阶段 9 步—一句话记住三者的递进关系SAAM 回答行不行ATAM 回答哪里行哪里不行、为什么CBAM 回答值不值得。七、选择题高频陷阱清单直接场景 / 间接场景别记反现有架构就能支持的是直接需要改架构的才是间接。ATAM 是自顶向下还是自底向上效用树是自上而下细化效用 → 属性 → 场景不是自底向上归纳。步骤 4 只识别不分析出现评估优劣即为错误项。效用树的优先级对是重要度, 难易度两个维度不要只写一个。效用树的根是效用不是质量属性也不是场景。敏感点的定义落在构件/构件之间关系的特性上不是笼统的设计决策。权衡点是影响多个质量属性的敏感点——它是敏感点的特例这个包含关系常被反过来考。风险点与非风险点是判断结论不是流程步骤不会出现在九步里。步骤 7 才引入更广泛的干系人步骤 1–6 没有。响应度量必须量化凡是只写提高改善而没有指标的都是错的。八、记忆锚点汇总考点锚点评估的前提不运行代码用场景当探针场景六要素刺激源 · 刺激 · 环境 · 制品 · 响应 · 响应度量SAAM 五步场景开发 → 架构描述 → 单场景评估 → 场景交互 → 总体评估直接 vs 间接改不动的叫直接要动刀的叫间接ATAM 四阶段呈现 → 调查与分析 → 测试 → 报告效用树四层树根—质量属性—属性分类—质量属性场景敏感点 vs 权衡点影响一个属性 vs 影响多个属性风险 vs 非风险是否危及质量目标三种方法SAAM 行不行 → ATAM 哪里不行 → CBAM 值不值九、小结架构评估这一章的复习顺序建议和上一篇反过来先背答案再理解流程。理由是四类判定、效用树结构、SAAM 五步、ATAM 四阶段九步这些都是定义型考点背下来就能拿分性价比极高而为什么 ATAM 要分两批人收场景这类理解型内容是帮你记住定义、防止记混的辅助。先把硬骨头定义与步骤啃下来理解会自然跟上。下一篇我会拆「ABSD 基于架构的软件设计」——它和架构风格、架构评估共同构成本章选择题的主力分值。本文为软考系统架构设计师备考系列文章内容依据《系统架构设计师教程》与历年真题考点分布整理。