Day28-30｜7.2.7 体系结构复审：在实现前发现高代价风险

对应教材：《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”——7.2.7 体系结构复审。

学习定位：体系结构复审是架构设计过程中的质量关口，连接需求分析、架构设计、实现和后续演化。高级系统架构设计师不仅要能提出方案，还要能组织独立、客观、可追踪的复审，判断架构是否满足功能与质量目标，并在软件进入大规模实现前识别高风险决策。

一、为什么架构必须复审

架构决策具有早期性、全局性和高影响性。早期做出的数据分布、服务边界、通信方式、部署拓扑和安全边界，一旦进入代码和基础设施，修改成本会显著上升。如果等到系统联调或上线后才发现性能瓶颈、单点故障或权限边界错误，修复往往需要改代码、迁移数据、调整网络、重新测试，甚至改变业务流程。

体系结构复审的核心价值，是用相对低的成本验证高影响的设计假设。它不是单纯检查文档是否漂亮，也不是让所有人投票选择自己喜欢的技术，而是围绕明确的需求和质量属性，检查架构决策是否合理、是否一致、是否可实现、是否可验证。

考试中的典型误区有三个。第一，把复审等同于代码评审；代码评审关注实现质量，架构复审关注系统整体结构、关键约束和质量属性。第二，把复审等同于项目汇报；汇报强调展示进度，复审必须产生问题、风险、结论和后续行动。第三，只邀请方案设计者参加；有效复审需要独立性和不同视角，尤其要让未参与设计的人员提出挑战性问题。

二、复审的目标和基本原则

一次完整的架构复审通常有以下目标：

1. 检查架构是否覆盖业务需求和非功能需求。
2. 判断关键质量属性是否有明确场景、指标和设计措施。
3. 发现架构中的单点、循环依赖、边界泄漏和关键技术风险。
4. 识别需求、架构、详细设计、实现和部署之间的不一致。
5. 评估架构的可实现性、可测试性、可运维性和可演化性。
6. 记录决策依据、遗留问题、风险等级和责任人。

架构复审应坚持以下原则：

三、什么时机进行体系结构复审

架构复审不应该只在项目结尾进行。可根据生命周期设置多个关口。

3.1 方案阶段复审

在需求基本稳定、架构候选方案形成后进行，重点是系统边界、主要风格、关键技术路线、质量属性目标和重大风险。此时发现问题，修改成本最低。

3.2 基线阶段复审

在架构设计完成并准备进入详细设计或开发前进行，重点检查视图完整性、模块职责、接口、数据所有权、部署方案、安全措施和验证计划。复审通过后，架构可以作为后续工作的基线。

3.3 实现阶段复审

在关键原型、技术预研或首个可运行版本完成后进行，重点验证架构决策是否能落地。特别是高性能存储、异步一致性、跨区域容灾、复杂安全机制等内容，不能只依赖纸面分析。

3.4 发布和演化阶段复审

在大版本发布、重大故障、外部依赖变化、规模显著增长或架构重构前进行。此时要检查现有架构是否仍然满足质量目标，以及技术债和历史决策是否需要重新评估。

可以把复审关口理解为：

需求基线 → 方案复审 → 架构基线复审 → 原型验证复审 → 发布复审 → 重大变更复审。

不同项目不必机械设置相同次数，但高风险系统至少要在进入大规模编码前完成一次正式架构复审。

四、复审对象：从需求到运行环境的完整链条

架构复审对象不只是架构图，至少包括以下内容：

4.1 需求与质量属性

检查业务目标、功能需求、约束和质量属性是否完整、无冲突、可度量。对于“高并发”“高可靠”“易维护”等模糊表述，要追问具体场景、负载、响应时间、可用性、恢复时间和数据丢失容忍度。

4.2 架构视图与决策

检查上下文、逻辑、开发、运行、部署、数据和安全视图是否足以说明关键问题；检查重要决策是否记录了背景、候选方案、权衡和后果。

4.3 结构与边界

检查模块或服务职责是否内聚，依赖是否有方向，是否存在循环依赖、共享数据库、公共模块膨胀、领域规则泄漏和边界绕过。

4.4 接口与交互

检查接口契约、版本、超时、重试、幂等、错误码、限流、认证和审计。同步接口要关注调用链长度与故障传播；异步接口要关注消息顺序、重复、丢失、积压和补偿。

4.5 数据与一致性

检查数据所有权、事务边界、主从关系、缓存失效、复制延迟、备份恢复、归档和敏感数据保护。跨服务写入尤其需要明确谁是事实来源，不能只写“最终保持一致”。

4.6 部署、运维和安全

检查节点、网络、故障域、资源容量、伸缩、监控、告警、发布、回滚、容灾和应急处理；检查身份认证、授权、密钥、最小权限、审计和安全事件响应是否落到具体组件与流程。

五、基于质量属性场景进行复审

高级考试中，质量属性是架构复审的主线。一个可复审的质量属性应写成场景，而不是形容词。通常包含刺激源、刺激、环境、受影响元素、响应和响应度量。

复审时可以针对每个场景追问：设计措施是什么？会不会引入新的风险？验证方法是什么？如果一个质量属性没有对应设计措施或验证证据，就不能认为它已经被架构满足。

六、复审方法与技术

6.1 检查表法

检查表适用于阶段性、重复性复审，可以覆盖文档完整性、依赖规则、接口、安全、部署和运维等内容。优点是效率高、容易形成组织资产；缺点是容易机械打勾，无法替代对复杂权衡的深入讨论。因此检查表应包含开放性问题，例如“如果消息重复，业务结果如何保持正确？”而不仅是“是否使用消息队列”。

6.2 场景分析法

场景分析法从真实或极端场景出发，观察架构如何响应。适合评估性能、可用性、可修改性、安全性和可测试性。场景必须具体，否则复审者只能发表泛泛意见。

6.3 原型和实验法

对关键不确定性建立最小原型，例如验证数据库写入吞吐、消息积压恢复、跨区域复制延迟、身份认证链路或大文件传输能力。原型不是提前开发完整系统，而是用最小成本验证最危险的假设。

6.4 权衡分析法

当多个质量属性互相冲突时，需要显式记录权衡。例如强一致性可能提高正确性，却增加延迟并降低可用性；缓存可以降低响应时间，却引入失效和数据新鲜度问题；服务拆分提升独立扩展能力，却增加分布式调用和运维复杂度。复审的重点不是寻找没有代价的方案，而是确认代价被识别、被接受并有控制措施。

6.5 模型和度量分析

可以使用容量估算、可靠性分析、调用链分析、依赖图、威胁建模和成本估算支撑复审。模型不一定非常复杂，但必须说明假设。例如容量模型要说明请求峰值、平均请求大小、缓存命中率、实例处理能力和增长系数；否则计算结果无法复现。

6.6 反向质询与故障推演

复审者可以从“最坏情况”出发提问：如果数据库不可用怎么办？如果消息重复怎么办？如果第三方返回错误怎么办？如果密钥泄露怎么办？如果一个可用区整体故障怎么办？如果流量增长十倍怎么办？通过故障推演检查架构是否有隔离、降级、恢复和补偿机制。

七、复审组织与会议流程

正式复审通常包含以下角色：架构设计者负责说明方案和回答问题；复审主持人负责范围、时间和秩序；领域专家检查业务和技术合理性；开发、测试、运维和安全代表分别从实现、验证、运行和防护角度提出意见；记录员负责问题、结论和行动项。复审者应具备足够独立性，不宜由方案作者单独给自己“验收”。

建议流程如下：

1. 准备：确定目标、范围、材料、参与者、评价标准和时间。
2. 预审：提前发送架构文档、需求、质量场景、原型数据和问题清单，让参与者独立阅读。
3. 说明背景：设计者讲清业务目标、约束、候选方案和关键风险，不要只展示结论。
4. 逐项检查：按关注点和质量属性场景提问，记录证据与疑问。
5. 风险分级：区分阻断问题、重大风险、一般问题和改进建议。
6. 形成结论：给出通过、条件通过或不通过，并明确通过条件。
7. 跟踪闭环：建立责任人、截止时间和验证证据，必要时组织重审。

“条件通过”不是模糊的折中，而是要明确条件。例如“完成压测并证明峰值吞吐达到每秒五千单”“补充灾备演练并确认恢复时间小于三十分钟”“明确库存数据的唯一写入者并通过一致性测试”。

八、风险、问题与决策的区别

复审记录中应区分三个概念。问题是已经观察到的事实，例如部署图显示数据库只有一个实例。风险是可能发生且会造成影响的不确定事件，例如单实例故障可能导致订单不可用。决策是团队在约束下选择的方案，例如采用多副本和跨故障域部署。问题可以产生风险，风险需要措施或接受，决策则要记录理由和后果。

风险最好包含描述、触发条件、影响、概率、等级、应对措施、责任人和状态。应对方式包括规避、降低、转移和接受。接受风险也必须说明接受依据、监控指标和重新评估条件，不能简单写“后续观察”。

九、案例分析：支付平台架构复审

某支付平台需要接入多个银行和第三方支付机构，要求订单支付结果可追踪，支付请求不能重复扣款，第三方接口偶发超时，系统在节假日会出现流量峰值。初始方案采用订单服务同步调用支付适配器，适配器直接更新订单数据库，并通过定时任务查询超时订单。

复审时首先将“不能重复扣款”写成质量场景：同一业务订单在网络抖动下被客户端重复提交，或支付平台返回结果超时后系统再次发起请求；系统应通过业务幂等键、支付请求号和第三方幂等能力识别重复请求，并在规定时间内返回可追踪状态。

随后发现几个风险：订单服务与适配器强耦合，新增渠道需要修改核心服务；同步调用链受第三方延迟影响；直接更新订单数据库破坏订单服务的数据所有权；定时任务缺少并发控制，可能重复发起查询；没有定义支付成功但回调丢失时的补偿路径。

复审建议保留同步入口用于参数校验和受理，支付执行通过渠道适配器隔离；为支付请求建立不可重复的业务标识和状态机；将回调处理设计为幂等操作，记录原始报文和审计信息；对超时请求使用查询、重试和人工对账相结合的补偿机制；为每个渠道设置超时、限流、熔断和监控；将压测、重复提交测试、回调乱序测试和故障演练列为通过条件。

最终结论可以是“条件通过”：核心结构和隔离方向可行，但必须完成幂等模型、状态转换表、数据所有权说明和第三方故障演练后才能进入大规模开发。这个结论既没有因为存在问题而全盘否定方案，也没有在证据不足时直接放行。

十、综合知识练习

练习1：单项选择

下列哪项最符合体系结构复审的主要目的？

A. 检查代码是否符合编码规范
B. 在架构进入大规模实现前，发现影响系统整体质量的高风险问题
C. 统计项目成员每日提交次数
D. 替代所有测试活动

答案：B。 架构复审关注整体结构、关键决策和质量属性风险；代码规范和测试分别属于其他质量活动。

练习2：多项选择

质量属性场景通常应明确哪些要素？

A. 刺激源
B. 运行环境
C. 受影响元素
D. 系统响应
E. 响应度量

答案：A、B、C、D、E。 只有把抽象质量目标转化为可观察、可度量的场景，才能进行架构设计和复审。

练习3：案例题

某业务系统架构复审会上，设计者介绍了系统分层和技术选型，参会者一致表示“整体没有问题”，但会议没有预先材料、没有质量属性指标、没有记录风险，也没有安排复审后的验证。请分析该复审的不足，并给出改进措施。

参考答案：

1. 复审目标和评价标准不明确，无法判断“通过”的依据。
2. 缺少预审材料，参与者不能独立准备，会议容易变成方案宣讲。
3. 参会角色和独立性不足，只有设计者说明而没有开发、测试、运维、安全等视角。
4. 没有把性能、可用性、安全、可修改性等质量目标转化为具体场景和指标。
5. 没有检查接口、数据所有权、部署故障域和异常处理，静态分层不能证明运行时可行。
6. 没有风险分级、责任人、截止时间和证据，问题无法闭环。

改进时应在会前确定范围、检查表、质量场景和通过条件，提前发送架构视图、需求、原型数据与决策记录；组织跨角色且具有一定独立性的复审小组；采用场景分析、故障推演、容量估算和原型验证；将问题区分为阻断、重大、一般和建议，并形成包含责任人和验证证据的行动项；对未完成事项采用条件通过或安排重审，不能用口头共识代替证据。

十一、论文写作素材

论文中论述“体系结构复审”时，建议写清四件事：复审为什么做、复审看什么、发现了什么、如何闭环。不要只写“组织专家评审，架构获得通过”，这类表述缺少过程和技术含量。

可采用以下论述框架：先写项目质量目标和架构风险，再说明在方案、基线和原型阶段分别设置复审关口；然后介绍如何围绕利益相关者建立检查表和质量属性场景；接着写一个具体问题，例如共享数据库造成服务边界泄漏、同步链路过长导致高峰超时、单可用区部署造成灾备风险；最后说明采用原型、压测、故障演练或安全测试验证改进措施，并通过问题单和重审完成闭环。

可直接使用的句式：

我将体系结构复审作为风险控制活动，而不是项目汇报活动。复审前明确范围、角色、质量属性场景和通过条件，复审中要求每个关键结论都有需求、模型、原型或测试证据，复审后将问题分级并指定责任人、截止时间和关闭证据。对于性能、可用性和安全性等高风险目标，我通过容量估算、故障推演和针对性实验验证架构假设，避免在系统实现完成后才暴露结构性问题。

十二、今日复盘

请记住体系结构复审的完整链条：

明确目标 → 提前准备 → 独立复审 → 场景分析 → 发现风险 → 分级决策 → 证据验证 → 重审闭环。

今天要能回答以下问题：

1. 架构复审与代码评审、项目汇报有什么区别？
2. 为什么“高性能、高可靠”不能直接作为复审依据？
3. 什么情况下应采用条件通过，而不是简单通过或不通过？
4. 如何证明一个复审问题已经真正关闭？

建议将自己的一个熟悉系统写出三个质量属性场景，并为每个场景列出架构措施、潜在风险和验证证据。若能进一步组织一次模拟复审，让自己分别扮演架构师、开发、测试、运维和安全人员提问，就能把本节从记忆知识点提升为案例分析和论文可用的工程能力。