本文档系统梳理软考系统架构设计师考试中软件质量属性的核心知识点，包含概念定义、设计策略及实例讲解。软件架构师考试：软件质量属性详解

---

一、质量属性概述

软件质量属性（Quality Attributes）是系统架构设计的重要考量维度，决定了系统的非功能性需求（NFR）。在架构师考试中，质量属性通常分为6大核心属性：

1. 性能（Performance）
2. 可用性（Availability）
3. 安全性（Security）
4. 可修改性（Modifiability）
5. 可测试性（Testability）
6. 易用性（Usability）

---

二、六大核心质量属性详解

1. 性能（Performance）

定义

系统响应外部刺激（事件）的及时性，主要指标包括：

• 响应时间：请求到响应的时间间隔
• 吞吐量：单位时间处理的事务数
• 资源利用率：CPU、内存、网络等资源使用情况

刺激/响应场景要素

要素	说明	示例
刺激源	触发性能需求的事件来源	用户请求、系统定时任务
刺激	具体事件	1000用户同时下单
环境	系统运行状态	正常负载/峰值负载
制品	被影响的系统部分	订单处理模块
响应	系统行为	处理请求并返回结果
响应度量	量化指标	响应时间 < 3秒

设计策略

运行时策略：

• 资源需求控制：减少计算开销、减少数据传输、限制事件队列长度
• 资源管理：引入并发机制、增加资源副本、采用调度算法
• 资源仲裁：优先级队列、最早截止时间优先（EDF）

实例讲解 🌰

场景：某电商平台"双11"大促期间，每秒需要处理10万笔订单。

架构设计：

1. 负载均衡：使用Nginx集群分发请求到多台应用服务器
2. 缓存策略：Redis缓存热点商品数据，减少数据库访问
3. 异步处理：订单创建后通过消息队列（Kafka）异步处理库存扣减
4. 数据库优化：读写分离 + 分库分表（Sharding）
5. CDN加速：静态资源分发到边缘节点

效果：系统TPS从500提升到100,000，响应时间控制在2秒内。

---

2. 可用性（Availability）

定义

系统正常运行时间的比例，通常用"9"的数量衡量：

• 99.9%（三个9）：年停机时间 < 8.76小时
• 99.99%（四个9）：年停机时间 < 52.6分钟
• 99.999%（五个9）：年停机时间 < 5.26分钟

计算公式

可用性 = MTBF / (MTBF + MTTR)

• MTBF（Mean Time Between Failures）：平均故障间隔时间
• MTTR（Mean Time To Repair）：平均修复时间

设计策略

故障检测策略：

• Ping/Echo：心跳检测
• 异常监控：日志分析、指标监控（Prometheus）

故障恢复策略：

• 主动冗余（热备）：主备同时运行，故障时无缝切换
• 被动冗余（冷备）：备用节点待机，故障时启动
• 选举机制：Raft/Paxos算法选举新主节点

故障预防策略：

• 事务回滚、优雅降级、限流熔断

实例讲解 🌰

场景：银行核心系统要求7×24小时不间断服务，可用性需达到99.999%。

架构设计：

1. 同城双活：两个数据中心同时提供服务，数据实时同步
2. 异地灾备：第三地部署灾备中心，RPO < 1分钟，RTO < 5分钟
3. 微服务熔断：使用Hystrix实现服务熔断，防止故障扩散
4. 数据库高可用：MySQL主从复制 + MHA（Master High Availability）自动故障转移
5. 监控告警：Zabbix + 钉钉/短信告警，故障30秒内通知运维

效果：系统全年可用性达到99.9992%，全年非计划停机仅4分钟。

---

3. 安全性（Security）

定义

系统防止未授权访问、数据泄露、恶意攻击的能力。

核心维度（CIA三元组）

• 机密性（Confidentiality）：防止未授权的信息泄露
• 完整性（Integrity）：防止未授权的数据篡改
• 可用性（Availability）：防止拒绝服务攻击（DoS）

设计策略

抵抗攻击策略：

• 身份认证：OAuth 2.0、JWT、双因素认证（2FA）
• 访问控制：RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）
• 数据加密：传输层TLS 1.3、存储层AES-256加密
• 入侵检测：WAF（Web应用防火墙）、IDS/IPS

检测攻击策略：

• 日志审计、异常行为分析、蜜罐技术

从攻击中恢复策略：

• 数据备份与恢复、灾难恢复计划（DRP）

实例讲解 🌰

场景：某医疗云平台存储患者隐私数据，需符合《网络安全法》和等保2.0三级要求。

架构设计：

1. 网络层安全：
   • DMZ区隔离：Web服务器部署在DMZ，数据库在内网
   • VPN专线：医院接入使用IPSec VPN
2. 应用层安全：
   • 接口鉴权：OAuth 2.0 + JWT Token，Token有效期15分钟
   • 敏感数据脱敏：患者身份证号显示为110***********1234
3. 数据层安全：
   • 数据库透明加密（TDE）
   • 字段级加密：患者手机号AES加密存储
4. 审计合规：
   • 全量操作日志，保存6个月
   • 堡垒机运维审计

效果：通过等保三级测评，数据泄露风险降低95%。

---

4. 可修改性（Modifiability）

定义

系统能够高效、经济地进行变更的能力，包括：

• 功能扩展
• 缺陷修复
• 架构演进

关键指标

• 局部化修改：变更影响范围小
• 防止连锁反应：修改不破坏其他模块
• 延迟绑定时间：架构决策推迟到合适时机

设计策略

局部化修改策略：

• 高内聚低耦合：单一职责原则（SRP）
• 信息隐藏：通过接口隔离实现细节

防止连锁反应策略：

• 抽象接口：依赖倒置原则（DIP），面向接口编程
• 配置文件：将可变部分外置到配置文件
• 服务注册发现：微服务架构中的服务治理

延迟绑定策略：

• 依赖注入（DI）、插件架构、微内核模式

实例讲解 🌰

场景：某SaaS平台需要支持多种支付方式（支付宝、微信、银联），且未来可能新增支付方式。

架构设计：

// 1. 定义抽象接口（策略模式）
public interface PaymentStrategy {
    PaymentResult pay(Order order);
    boolean supports(String paymentType);
}

// 2. 具体实现类
@Component
public class AlipayStrategy implements PaymentStrategy { ... }

@Component  
public class WechatStrategy implements PaymentStrategy { ... }

// 3. 上下文类（依赖注入）
@Service
public class PaymentService {
    private final List<PaymentStrategy> strategies;
    
    public PaymentService(List<PaymentStrategy> strategies) {
        this.strategies = strategies; // Spring自动注入所有策略
    }
    
    public PaymentResult pay(String type, Order order) {
        return strategies.stream()
            .filter(s -> s.supports(type))
            .findFirst()
            .orElseThrow(() -> new UnsupportedOperationException("不支持的支付方式"))
            .pay(order);
    }
}

优势：

• 新增支付方式只需添加新类，无需修改现有代码（开闭原则）
• 各支付方式独立测试部署
• 支持运行时动态切换

---

5. 可测试性（Testability）

定义

系统能够被有效验证和确认的程度，包括：

• 单元测试、集成测试、系统测试的便利性
• 故障重现和诊断的容易程度

设计策略

输入/输出控制：

• 接口抽象：通过Mock对象隔离依赖
• 依赖注入：便于替换真实依赖为测试替身

内部监控：

• 日志记录：结构化日志（JSON格式）
• 健康检查：/health端点暴露系统状态
• 性能指标：Micrometer + Prometheus暴露Metrics

测试支持架构：

• 测试驱动开发（TDD）
• 契约测试（Pact）
• 混沌工程（Chaos Engineering）

实例讲解 🌰

场景：某金融系统核心交易模块需要达到90%单元测试覆盖率，且支持自动化回归测试。

架构设计：

1. 分层架构便于测试：

   Controller层 → 集成测试（@SpringBootTest）
   Service层   → 单元测试（JUnit + Mockito）
   DAO层      → 使用H2内存数据库测试
   

2. 依赖注入示例：

   @Service
   public class TradeService {
       private final RiskChecker riskChecker;
       private final TradeRepository repository;
       
       // 通过构造函数注入，便于测试时传入Mock对象
       public TradeService(RiskChecker riskChecker, 
                         TradeRepository repository) {
           this.riskChecker = riskChecker;
           this.repository = repository;
       }
   }
   

3. 测试代码示例：

   @ExtendWith(MockitoExtension.class)
   class TradeServiceTest {
       @Mock private RiskChecker riskChecker;
       @Mock private TradeRepository repository;
       @InjectMocks private TradeService service;
       
       @Test
       void shouldRejectHighRiskTrade() {
           when(riskChecker.check(any())).thenReturn(RiskLevel.HIGH);
           assertThrows(RiskException.class, () -> 
               service.execute(new TradeRequest()));
       }
   }
   

4. CI/CD集成：
   • 提交代码自动触发测试流水线
   • SonarQube静态代码分析
   • 测试覆盖率门禁（Coverage Gate）

---

6. 易用性（Usability）

定义

用户学习、操作、准备输入和解释系统输出的难易程度。

关键指标

• 学习时间：用户掌握基本操作所需时间
• 错误率：用户操作出错的频率
• 主观满意度：用户满意度调查评分

设计策略

运行时策略：

• 模型-视图分离（MVC/MVVM）
• 用户反馈：进度条、操作确认、撤销功能
• 一致性设计：遵循平台设计规范（iOS HIG、Material Design）

设计时策略：

• 用户参与设计（User-Centered Design）
• 原型验证：低保真原型→高保真原型→可用性测试

实例讲解 🌰

场景：某B端ERP系统用户抱怨操作复杂，培训成本高。

架构与UX改进：

1. 前端架构重构：
   • 采用Ant Design Pro组件库，统一交互规范
   • 实现"面包屑导航"+"标签页缓存"，支持多任务并行
2. 智能化功能：
   • 全局搜索：支持拼音、模糊搜索（如搜"dd"匹配"订单"）
   • 智能表单：根据用户角色自动隐藏不相关字段
   • 批量操作：Excel导入导出、批量审批
3. 反馈机制：
   • 操作成功：Toast提示 + 自动刷新列表
   • 操作失败：明确错误原因 + 解决建议链接
   • 危险操作：二次确认弹窗（防误触）
4. 辅助系统：
   • 新手引导：首次登录交互式教程
   • 上下文帮助：每个页面悬浮"?"按钮链接帮助文档
   • 快捷键支持：Ctrl+S保存、Ctrl+F搜索

效果：新用户上手时间从3天缩短到2小时，客服咨询量减少60%。

---

三、质量属性权衡（Trade-offs）

经典权衡关系

        安全性
          ↑
          |    性能 ←————→ 可用性
          |     ↑      ↘  /
          |     |        \/
          |   可修改性 ←——→ 可测试性
          |                
          └————→ 易用性

常见冲突与解决方案

冲突场景	矛盾点	解决方案
安全性 vs 性能	加密/认证增加延迟	硬件加速（AES-NI）、TLS会话复用、边缘认证
可用性 vs 一致性	分布式系统CAP定理	根据业务选择CP或AP，采用最终一致性
可修改性 vs 性能	抽象层增加开销	热点路径保留内联优化，非热点保持抽象
安全性 vs 易用性	复杂密码策略影响体验	生物识别、无密码认证（FIDO2）

实例讲解 🌰

场景：设计一个金融交易系统，如何平衡强一致性和高可用性？

架构决策（基于CAP定理）：

1. 账户余额查询（AP）：
   • 允许读取缓存数据，可能读到旧值（最终一致性）
   • 优先保证查询服务不中断
2. 转账操作（CP）：
   • 使用分布式事务（Seata AT模式）
   • 两阶段提交保证强一致性，牺牲部分可用性（阻塞等待）
3. 对账补偿：
   • 日终对账发现不一致时，触发补偿事务
   • 使用Saga模式处理长事务

结果：查询可用性99.99%，转账一致性100%，平均响应时间200ms。

---

四、架构评估方法（ATAM）

软件架构权衡分析方法（Architecture Tradeoff Analysis Method）是软考重点：

ATAM 9大步骤

1. 呈现ATAM：介绍评估方法
2. 呈现业务驱动：明确质量属性目标
3. 呈现架构：架构师讲解设计方案
4. 确定架构方法：识别采用的架构模式
5. 生成质量属性效用树：优先级排序（高H/中M/低L）
6. 分析架构方法：评估方法对质量属性的支持
7. 头脑风暴和优先场景：收集利益相关者场景
8. 分析架构方法：针对新场景重新评估
9. 呈现结果：风险点、敏感点、权衡点

效用树示例

效用树根
├── 性能（H）
│   ├── 场景1：1000并发用户响应<2s（H,M）
│   └── 场景2：数据库查询<100ms（M,H）
├── 可用性（H）  
│   ├── 场景3：故障恢复时间<5min（H,H）
│   └── 场景4：数据备份RPO<1min（H,M）
└── 安全性（M）
    └── 场景5：防SQL注入攻击（M,H）

注：（业务重要性，技术实现难度）

---

五、历年真题考点

高频考点总结

1. 质量属性场景识别：给定描述判断属于哪种质量属性
2. 设计策略选择：根据需求选择合适的设计策略
3. 架构风格匹配：
   • 管道-过滤器：数据流处理，高可修改性
   • 事件驱动：高可扩展性、松耦合
   • 微内核：高可配置性、延迟绑定
   • 分层架构：可移植性、可测试性
4. ATAM评估：效用树构建、风险点识别

真题示例（2023年）

题目：某系统要求在用户并发增加时，通过增加服务器数量保持响应时间不变，这主要体现了哪种质量属性？

答案：可扩展性（属于性能的子属性，或广义的可修改性）

---

六、速记口诀

性能快，可用稳，安全防攻击；
修改易，测试便，易用好学习；
ATAM评估九步走，效用树里排优先级；
架构设计讲权衡，没有银弹全能型。