Day29-08｜8.2.1 系统架构评估中的重要概念：从架构判断到风险与权衡

一、教材定位

系统架构评估不是对代码进行一般性检查，而是在系统实现或重大变更之前，依据业务目标、质量属性和架构决策，判断架构方案是否可行、是否满足关键约束、是否存在高风险以及是否需要调整。架构评估中的概念很多，容易混淆：架构评估不等于架构设计，质量属性不等于指标，场景不等于用例，风险不等于问题，利益相关者也不只是项目用户。

二、什么是系统架构评估

系统架构评估是对软件系统架构满足业务目标和质量属性要求的程度进行分析、判断和改进的活动。它既可以发生在架构方案阶段，也可以发生在详细设计、系统演进、重大技术变更和运行复盘阶段。

架构评估的对象包括架构决策、系统结构、组件职责、交互关系、数据组织、部署拓扑、技术约束和质量属性策略。评估的输出通常包括满足项、不满足项、风险项、权衡记录、改进建议、验证计划和决策结论。

三、利益相关者

利益相关者是对系统有利益、受系统影响或能够影响系统决策的个人、团队或组织。用户只是其中一类。业务负责人关心价值和流程，管理者关心成本、进度和风险，开发团队关心可实现性和可维护性，运维团队关心部署、监控和恢复，安全人员关心信任边界和合规，外部供应商关心接口与责任边界。

如果评估只听取技术团队意见，可能忽略业务规则和运维风险；如果只听取业务方意见，可能得到不可实现或成本过高的架构。架构评估的价值就在于把不同利益相关者的质量期望放到同一个决策框架中。

四、架构决策

架构决策是对系统结构、技术、数据、通信、部署和质量策略作出的重要选择。它通常具有影响范围大、修改成本高、会限制后续方案的特点。例如选择共享数据库还是服务自治，采用同步调用还是事件驱动，采用集中式部署还是多地域部署，采用强一致还是最终一致，都属于架构决策。

架构决策不能只有结论，还应记录背景、问题、候选方案、选择结果、理由、后果、假设和验证方式。评估人员要检查决策是否与质量属性场景相匹配，是否考虑了替代方案，以及假设是否仍然成立。

五、架构驱动因素

架构驱动因素是对架构产生重大影响的业务、技术、组织、法规和质量要求。常见驱动因素包括核心业务流程、关键质量属性、数据规模、并发峰值、组织结构、开发能力、遗留系统、监管要求、预算和交付周期。

架构评估前应区分驱动因素的优先级。某些因素是硬约束，例如必须满足的数据合规要求；某些因素是目标，例如希望三年内支持十倍业务增长；某些因素是假设，例如外部支付平台始终可用。把假设误认为约束，或者把目标写成没有指标的口号，都会影响评估结论。

六、质量属性场景

质量属性场景是架构评估的重要输入。它把刺激源、刺激、环境、对象、响应和响应度量组织起来，使评估可以回答“在什么情况下，系统应如何表现”。例如可修改性场景：业务人员提出新增支付渠道的需求，在正常开发环境中，系统通过实现标准适配器完成接入，核心订单和支付状态模块无需修改，五个工作日内完成开发和回归测试。

场景应该有优先级和来源，并能追踪到架构策略、组件实现和测试结果。没有场景，评估容易变成评审者凭经验发表意见；有了场景，讨论就可以围绕目标、证据和风险展开。

七、架构权衡

架构权衡是在多个相互冲突的质量目标、成本和风险之间作出选择。权衡不是妥协，更不是拍脑袋，而是基于优先级和证据的决策。常见权衡包括性能与一致性、可用性与一致性、安全性与易用性、灵活性与复杂度、复用性与领域适配、交付速度与长期维护成本。

评估时要问：方案改善了哪个属性，牺牲了哪个属性，牺牲是否可接受，是否有补偿措施，如何验证。比如采用异步消息提高吞吐和解耦，需要用幂等、重试、死信、补偿、对账和监控控制一致性风险。

八、风险、问题、假设和约束

风险是尚未发生但可能对目标产生负面影响的不确定事件；问题是已经发生并需要处理的事实；假设是当前设计暂时依赖但尚未完全证实的条件；约束是必须遵守的限制。四者不能混为一谈。

架构评估要识别高风险决策，优先验证影响大、发生概率高、不可逆或修复成本高的风险。

九、架构评估的证据

评估证据包括架构文档、架构决策记录、原型、依赖分析、容量模型、接口契约、代码检查、压测报告、安全测试、故障演练、恢复报告和生产监控。证据需要说明环境、范围、方法、结果和局限，不能只写“测试通过”。

评估结论应区分已验证、部分验证、待验证和不满足。对于待验证项，应指定负责人、验证方法和完成时间；对于不满足项，应决定整改、接受风险、替换方案或调整目标。

十、架构评估与架构演进

架构评估不是项目启动时的一次会议。需求变化、业务规模增长、技术升级、故障事件、供应商变化和合规要求变化都可能使原有架构失效。架构治理需要在重大变更前评估，在上线前验证，在运行中监控，在故障后复盘。

架构债务也应纳入评估。为了赶进度形成的临时适配、共享数据库、人工发布和缺失测试，如果长期保留，就会增加未来变更成本。评估报告应记录债务的原因、影响、偿还计划和责任人。

十一、案例分析：统一数据平台架构评估

某集团计划建设统一数据平台，方案包含数据采集、湖仓存储、实时计算、离线计算、数据服务和权限审计。业务部门关心数据时效和分析能力，安全团队关心敏感数据分级，运维团队关心存储成本和恢复，开发团队关心数据模型变化。

评估首先识别驱动因素：实时指标要求分钟级更新，历史数据需要保存五年，敏感数据不得被无权限账号查询，平台应支持多个业务域。随后建立场景：采集链路中断后能够补采；数据模型变化不影响已有报表；敏感字段访问必须经过授权并可审计；存储节点故障后可恢复关键数据；高峰查询不能影响实时写入。

评估发现直接共享原始库会造成查询和写入相互影响，于是采用分层存储和数据服务隔离；通过数据契约和版本化模型控制变化；通过数据分级、脱敏、权限和审计满足安全要求；通过断点续传、重试和校验保证采集可靠性。方案还明确了成本、运维复杂度和一致性之间的权衡，并安排原型和压测验证。

十二、练习题

题1

架构评估中的利益相关者为什么不能只包含最终用户？

参考答案

不同角色关注的质量属性和约束不同。业务负责人关注价值，开发关注可修改性，运维关注恢复和可观测性，安全关注机密性和审计，管理者关注成本与风险。只听取用户意见会遗漏实现、运行和治理阶段的重要风险。

题2

区分风险、问题、假设和约束。

参考答案

风险是可能发生的负面不确定事件；问题是已经发生的事实；假设是设计暂时依赖但需要验证的条件；约束是必须遵守的限制。风险需要缓解和监控，问题需要纠正，假设需要验证，约束需要纳入设计。

题3

一份合格的架构决策记录至少应包含哪些内容？

参考答案

应包含背景、问题、质量属性场景、候选方案、选择结果、选择理由、后果、假设、风险、验证方法、责任人和版本。这样后续评估才能判断决策是否仍然适用。

十三、论文写作素材

论文中可以写“我在架构评估前组织业务、开发、测试、安全和运维人员识别架构驱动因素，使用质量属性场景描述峰值性能、节点故障、权限控制和需求变化等目标；针对每个场景建立架构策略、风险和验证证据，并记录性能与一致性、可用性与复杂度之间的权衡；在上线和运行阶段持续复评，避免架构决策脱离实际负载和故障情况。”

十四、今日复盘

本节重点掌握：架构评估的对象和目的；利益相关者；架构驱动因素；架构决策；质量属性场景；权衡；风险、问题、假设、约束的区别；以及评估证据链。遇到评估题，按“目标—场景—决策—权衡—风险—证据”组织答案。