一、核心概念：什么是质量属性？
- 定义 ：质量属性是影响系统用户体验、开发效率和长期演进的非功能性特征。它们不是系统"做什么"，而是系统"做得怎么样"。
- 与功能需求的区别 ：
- 功能需求：系统必须完成的具体行为或功能。例如："系统允许用户通过关键词搜索商品。"
- 质量属性 ：系统在执行这些功能时所表现出来的条件和标准 。例如："搜索结果的响应时间 95% 以上应小于 2 秒。"（性能 ），"系统应能同时为 10,000 名用户提供搜索服务。"（可扩展性）
架构师视角 ：功能需求决定了架构的广度 ，而质量属性决定了架构的深度和形状。一个不能满足关键质量属性的架构是失败的架构。
二、质量属性的分类
通常将质量属性分为两大类：运行期质量属性 和开发期质量属性。
（一）运行期质量属性 - 用户和运维人员可直接感知
这些属性与系统的运行时行为密切相关。
1. 性能 (Performance)
- 定义：系统在给定资源和时间约束下，完成指定任务的能力。
- 衡量指标 ：
- 响应时间：从发出请求到收到响应所需的时间（如页面加载时间、API 返回时间）。
- 吞吐量：单位时间内系统处理的请求数量（如每秒处理的事务数 TPS、每秒查询率 QPS）。
- 资源利用率：CPU、内存、网络、I/O 等资源的使用情况。
- 架构策略 ：
- 引入缓存（Redis, Memcached）减少数据库压力。
- 使用异步处理（消息队列）削峰填谷。
- 进行负载均衡，将请求分发到多个服务器。
- 优化数据库（索引、SQL 优化、读写分离）。
- 对代码进行性能调优。
2. 可用性 (Availability)
- 定义：系统在需要时能够正常运行和提供服务的概率。
- 衡量指标 ：可用率 ，通常用"几个 9"来表示。
- 99.9% （三个九）-> 年停机时间约 8.76 小时。
- 99.99%（四个九）-> 年停机时间约 52.6 分钟。
- 99.999%（五个九）-> 年停机时间约 5.26 分钟。
- 架构策略 ：
- 消除单点故障：对关键组件进行集群部署。
- 故障转移：当主节点故障时，能自动切换到备用节点。
- 冗余：提供额外的组件或系统作为备份。
- 实现容错 和弹性设计。
3. 安全性 (Security)
- 定义：系统保护自身数据和资源，防止未授权访问、恶意攻击，并确保合法用户不被拒绝服务的能力。
- 衡量指标：漏洞数量、安全事件发生率、渗透测试通过率等。
- 架构策略 ：
- 部署防火墙、WAF。
- 实施身份认证与授权（OAuth 2.0, JWT, RBAC）。
- 对敏感数据加密（传输加密 TLS，存储加密）。
- 记录并监控审计日志。
- 防止常见攻击（SQL 注入、XSS、CSRF）。
4. 可伸缩性 (Scalability)
- 定义：系统通过增加资源来提升处理能力的难易程度。
- 类型 ：
- 垂直扩展 ：提升单个服务器的性能（如增加 CPU、内存）。简单但有上限。
- 水平扩展 ：增加服务器的数量。更灵活，是现代架构的主流。
- 架构策略 ：
- 无状态设计：使请求可以被任何服务器处理，便于水平扩展。
- 微服务架构：可以针对特定服务进行独立扩展。
- 使用分布式缓存 和数据库分库分表。
5. 可靠性 (Reliability)
- 定义 ：系统在规定条件下、规定时间内，无故障地执行所需功能的能力。
- 衡量指标 ：
- 平均无故障时间：系统连续正常运行的平均时间。
- 平均修复时间：系统从故障状态恢复到正常状态所需的平均时间。
- 与可用性的区别 ：
- 可靠性 关注的是"别出故障"（故障频率）。
- 可用性 关注的是"出了故障能尽快恢复"（故障后恢复速度）。
- 高可用性可以通过快速的故障恢复（低 MTTR）来弥补较低的可靠性（低 MTBF）。
6. 易用性 (Usability)
- 定义：用户学习和使用系统的容易程度。
- 架构策略：提供清晰的 API 文档、设计直观的用户界面、提供一致的操作体验。虽然主要由 UI/UX 设计师负责，但架构师需要提供技术支持。
（二）开发期质量属性 - 开发与维护人员关注
这些属性与系统的静态结构密切相关，影响开发成本和系统寿命。
1. 可维护性 (Maintainability)
- 定义 ：发现并修复缺陷、改进性能或适应环境变化的难易程度。这是最重要的开发期质量属性。
- 架构策略 ：
- 高内聚、低耦合的设计原则。
- 采用分层架构 、模块化设计。
- 编写清晰的文档 和注释。
- 遵循设计模式 和编码规范。
2. 可移植性 (Portability)
- 定义：系统从一种硬件或软件环境迁移到另一种环境的难易程度。
- 架构策略 ：
- 使用跨平台的编程语言（如 Java, Python）。
- 将平台相关的代码进行抽象和封装。
- 采用容器化技术（如 Docker），实现"一次构建，到处运行"。
3. 可测试性 (Testability)
- 定义：为系统建立验证准则，并通过测试执行来验证的容易程度。
- 架构策略 ：
- 支持单元测试（依赖注入、面向接口编程）。
- 提供测试驱动 和模拟能力。
- 系统模块化，便于隔离测试。
4. 可复用性 (Reusability)
- 定义：系统的组件或架构能在其他项目中重复使用的程度。
- 架构策略 ：
- 设计可复用的构件、框架和库。
- 采用面向对象的设计原则（如 SOLID）。
- 构建领域特定软件体系结构。
三、质量属性场景 - 架构师的沟通与分析工具
为了精确描述和分析质量属性，架构师使用质量属性场景这一标准化工具。一个完整的场景包括六个部分：
- 刺激源：谁发起了这个刺激？（用户、管理员、外部系统）
- 刺激：发生了什么事件？（数据请求、故障、攻击尝试）
- 环境：刺激发生时，系统处于什么状态？（正常模式、高负载、降级模式）
- 制品：刺激作用于系统的哪个部分？（整个系统、某个组件、数据库）
- 响应：系统应该如何应对外部的这个刺激？（处理请求、屏蔽攻击、记录日志）
- 响应度量：如何量化地衡量响应是否合格？（在 2 秒内返回结果，阻止 99.9% 的 SQL 注入）
示例（性能场景）：
- 刺激源：注册用户
- 刺激：提交关键词搜索请求
- 环境：正常操作模式下，系统并发用户数为 5000
- 制品：商品搜索服务
- 响应：系统返回与关键词相关的商品列表
- 响应度量：在 95% 的情况下，响应时间在 2 秒以内
四、质量属性之间的权衡
没有架构能完美满足所有质量属性，架构师的核心工作就是权衡。
- 安全性与性能：严格的加密和身份验证会增加系统开销，降低性能。
- 可用性与一致性：在分布式系统中，要保证所有节点数据强一致性（CP），可能会牺牲可用性（A）；而要保证高可用性（AP），则必须接受数据的最终一致性。
- 可扩展性与可维护性：微服务架构提升了可扩展性，但由于服务数量增多，也增加了运维和监控的复杂性，降低了可维护性。
- 可复用性与性能：高度抽象和通用的可复用组件，可能无法为特定场景提供最优性能。
架构师必须与利益相关者（如产品经理、客户）沟通，明确哪些质量属性是核心约束，哪些是美好愿望，从而做出合理的决策。
五、软考考点总结与应用
-
选择题：
- 直接考查各类质量属性的定义 和衡量指标。
- 区分易混淆的概念，如可用性 vs 可靠性 ，性能 vs 可伸缩性。
- 给出一个场景，判断其描述的是哪种质量属性。
- 考查实现特定质量属性的常见架构策略。
- 考查质量属性之间的权衡关系。
-
案例分析题：
- 题目给出一个系统需求描述，其中包含明确的或隐含的质量属性要求。
- 问题：请分析该系统应重点关注哪些质量属性，并为你设计架构方案以满足这些属性。
- 答题套路 ：
- 识别质量属性：从案例描述中提取关键词（如"高并发"、"7x24小时"、"安全稳定"、"易于升级"），并将其对应到具体的质量属性（性能、可用性、安全性、可维护性）。
- 提出架构策略 ：
- 为满足性能，建议引入缓存、负载均衡。
- 为满足可用性，建议采用集群、故障转移。
- 为满足安全性，建议部署 WAF、实施鉴权。
- 为满足可扩展性，建议采用微服务架构。
- 阐述权衡：说明你的架构方案在权衡不同质量属性时的考虑。
-
论文题：
- 可能围绕"论软件系统质量属性及其实现 "、"某系统架构设计中的权衡策略 "、"高可用/高并发/安全系统的设计与实践"等主题。
- 写作时，必须：
- 明确点出项目关键的质量属性目标（最好用量化指标）。
- 详细论述你的架构决策是如何针对这些质量属性进行设计的。
- 讨论你在权衡不同质量属性时所做的取舍和理由。
- 分享在保障质量属性过程中遇到的挑战和解决方案。
总结
对于软考架构师，掌握软件系统质量属性的关键在于：
- 精准理解：清晰掌握每个质量属性的内涵、外延和度量方式。
- 熟练运用场景：能用"质量属性场景"这一工具精确描述需求。
- 精通策略：对实现每个质量属性的常用架构策略了如指掌。
- 善于权衡：具备在复杂约束下进行决策和权衡的思维和能力。