Day29-06｜8.1.2 面向架构评估的质量属性：把抽象目标转化为架构证据

一、教材定位

上一节介绍了质量属性的概念，本节进一步说明哪些质量属性需要在架构层面重点关注，以及如何把它们用于架构评估。架构评估不是检查架构图是否美观，而是判断架构设计是否能够满足重要质量目标，并识别不同方案的风险、权衡和改进方向。性能、可用性、安全性、可修改性、可测试性、互操作性和可靠性等属性，往往会直接受到系统分解、数据边界、通信方式、部署拓扑和技术选型的影响。

二、为什么质量属性能够驱动架构评估

架构决定系统的骨架。模块如何划分、数据由谁拥有、组件如何通信、状态放在哪里、故障如何传播、部署如何扩展，这些决策一旦确定，后续实现就会受到约束。很多质量问题在编码阶段才暴露，修复成本很高；如果在架构阶段通过场景和证据评估，就能提前发现不可行方案。

架构评估关注三个问题：第一，架构是否覆盖了关键质量场景；第二，架构策略是否能够产生期望响应；第三，是否存在足够的证据证明策略有效。只写“采用高可用架构”不算证据，必须说明冗余、切换、数据恢复、故障演练和度量结果。

三、面向架构评估的主要质量属性

1. 性能

性能评估关注响应时间、吞吐量、并发数、资源利用率、容量上限和性能衰减。架构评估要检查关键路径上的同步调用、数据库访问、网络跳数、锁竞争、缓存命中、批量策略和扩展方式。性能目标必须结合负载模型，包括用户数量、请求分布、峰值比例、数据量增长和第三方依赖延迟。

2. 可用性

可用性评估关注系统在故障、维护和异常负载下继续提供服务的能力。需要检查单点、冗余、健康检查、故障检测、自动切换、降级、限流、备份、恢复和跨地域容灾。评估不能只问“有没有集群”，还要问集群中的网络、存储、配置、注册中心和数据库是否仍有单点。

3. 安全性

安全架构评估关注身份、授权、机密性、完整性、审计、不可否认性和攻击面。评估内容包括信任边界、数据流、认证协议、权限模型、密钥生命周期、敏感数据处理、日志防篡改、接口防护、依赖漏洞和应急响应。安全性要与业务风险联系起来，不能只罗列加密、防火墙等技术。

4. 可修改性

可修改性关注需求变化影响多少模块、需要多长时间修改、修改是否容易测试和发布。评估要检查职责边界、依赖方向、接口稳定性、配置和代码的分离、插件与策略机制、数据库耦合以及版本兼容。可修改性差的常见表现是新增一个规则必须修改多个核心模块，或者公共数据库表被大量系统直接使用。

5. 可测试性

可测试性关注系统是否容易构造测试环境、替换依赖、注入故障、观察内部行为和复现问题。架构评估要检查模块是否可独立测试，外部依赖是否可模拟，日志是否包含关联ID，异步消息是否可追踪，配置和数据是否可重置，测试是否能覆盖关键状态和异常路径。

6. 互操作性

互操作性关注不同系统之间交换信息和正确协作的能力。评估需要检查接口协议、数据格式、语义映射、版本演进、错误处理、时间和编码约定、身份信任以及外部系统不可用时的处理方式。接口“能够调用”不等于真正互操作，语义、可靠性和版本兼容同样重要。

7. 可靠性

可靠性关注系统在给定条件和时间内无故障地完成规定功能。架构评估要关注事务、幂等、校验、重试、补偿、数据一致性、异常隔离、故障恢复和运行监控。可靠性不仅要求服务存活，还要求结果正确、数据不丢失且错误可追踪。

四、质量属性场景与评估指标

质量属性场景应包含刺激源、刺激、环境、受影响对象、响应和响应度量。评估人员可以为每个场景建立证据链：需求指标、架构策略、实现机制、测试用例、测试结果和运行指标。

指标必须与场景匹配。性能用响应时间和吞吐量，可靠性用失败率、恢复时间和数据正确率，可修改性用变更影响范围和交付周期，安全性用越权拦截、漏洞修复和审计覆盖度。不能用单一指标代表所有质量属性。

五、质量属性之间的权衡评估

架构评估不是寻找绝对最优，而是判断方案是否满足优先级最高的目标，并明确牺牲了什么。实时同步通常降低延迟，但会增加耦合；异步消息提高解耦和吞吐，却引入最终一致性和重复处理；多副本提高可用性，却增加成本和数据协调；强加密提高安全性，却可能增加CPU消耗和密钥管理复杂度。

评估报告应记录候选方案、收益、代价、风险、适用条件和最终选择。对于不可逆决策，应优先做原型和压力测试；对于可逆决策，可以通过迭代逐步验证。任何权衡都要回到业务目标，例如金融扣款更重视一致性和审计，推荐查询更重视吞吐和可用性。

六、质量属性与架构视图

逻辑视图帮助评估职责、依赖和可修改性；开发视图帮助评估模块、构件和测试边界；过程视图帮助评估并发、通信、事务和性能；部署视图帮助评估冗余、网络、容灾和运维；数据视图帮助评估一致性、所有权、备份和安全。单一架构图无法说明全部质量属性，应通过多个视图和场景相互验证。

七、架构评估中的常用证据

静态证据包括架构决策记录、依赖分析、接口契约、威胁模型、容量模型和数据流图；动态证据包括原型、压测、故障注入、安全扫描、渗透测试、恢复演练和运行监控。静态分析适合提前发现结构问题，动态验证适合证明实际行为，二者缺一不可。

评估证据还要说明条件和范围。例如压测使用多少节点、多少数据、什么请求分布；故障演练关闭哪个节点、持续多久、是否包含数据恢复；安全测试覆盖哪些角色和接口。脱离条件的“测试通过”不能支撑可靠结论。

八、案例分析：高并发票务系统架构评估

某票务系统需要支持突发抢购、库存准确、支付回调和订单查询。架构方案一使用单体和共享数据库，方案二使用服务化、缓存、消息和库存分片。评估时发现方案二吞吐和扩展能力较好，但引入库存一致性、消息重复和运维复杂度问题；方案一实现简单，但高峰期数据库容易成为瓶颈，扩展和故障隔离能力不足。

最终采用模块化服务架构：库存服务拥有库存数据，预扣使用幂等请求和超时释放；缓存只用于快速读取，最终扣减必须经过库存服务；订单和支付通过事件协作，回调使用交易号幂等；高峰期通过排队和限流保护核心；部署采用多实例和数据库高可用；通过压测、重复请求、支付超时、节点宕机和库存校验验证质量目标。

评估结论不是简单说方案二“更先进”，而是说明它在高并发和扩展方面满足优先目标，同时通过幂等、补偿、监控和演练控制其一致性与运维风险。

九、练习题

题1

架构评估为什么不能只检查架构图？

参考答案

架构图只能展示部分结构，无法证明性能、故障恢复、安全控制和版本兼容。必须结合质量属性场景、架构决策、实现机制、测试结果和运行指标形成证据链。

题2

如何评估一个系统的可修改性？

参考答案

分析需求变化会影响哪些模块、数据和接口，检查职责边界、依赖方向、扩展点、配置与代码分离、版本兼容和测试范围，并用实际变更的影响模块数、修改周期、回归缺陷和发布时间进行验证。

题3

异步架构通常改善哪些质量属性，又引入哪些风险？

参考答案

异步架构通常改善解耦、吞吐、弹性和部分可用性，但引入最终一致性、重复消息、顺序、延迟、补偿、追踪和运维复杂度。必须设计幂等、重试、死信、对账、监控和人工补偿机制。

十、论文写作素材

论文可以写“我以质量属性场景为主线开展架构评估，针对峰值性能、节点故障、新规则变更、越权访问和外部接口升级分别建立指标。通过逻辑、过程、部署和数据视图识别风险，再使用压测、故障演练、契约测试和安全测试取得证据。对于性能与一致性、可用性与运维复杂度之间的矛盾，我结合业务优先级选择方案，并记录权衡和后续改进计划。”

十一、今日复盘

面向架构评估的质量属性，核心不是背定义，而是建立“属性—场景—架构策略—证据”的链条。性能、可用性、安全、可修改性、可测试性、互操作性和可靠性都要结合业务场景评估，并明确权衡而不是追求所有指标同时最大化。