小明学完了架构风格，信心满满地打开了公司的系统设计文档。
翻了几页，他愣住了。
文档里反复出现的不是"用了什么风格"，而是一堆他不熟悉的词：性能指标、可用性要求、安全性等级、可修改性评估、ATAM……
"我知道系统要快、要稳、要安全。但怎么把这些模糊的'好'变成可以衡量、可以比较、可以评估的标准？怎么在'更快'和'更安全'之间做取舍？"
他意识到，知道了"有哪些架构风格"只是第一步。更关键的问题是：怎么判断一个架构"好不好"？
于是小明又花了一周，啃完了架构质量属性和评估方法。这篇文章，就是他的学习笔记。
如果你也和小明一样，知道"系统要好"，但说不清"好在哪里、怎么衡量、怎么评估"——这篇就是为你准备的。
架构质量：系统"好不好"的衡量标准
小明首先搞明白了一个基本区分：
💡功能属性（Functional）：系统做什么——能下单、能支付、能查询。这是用户需求，是"面子"。质量属性（Non-Functional）：系统做得怎么样——下单快不快、支付稳不稳、查询安不安全。这是架构决定的，是"里子"。
打个比方：买车的时候，"能坐4个人、能开空调"是功能属性；"百公里加速几秒、油耗多少、碰撞测试几星"是质量属性。
架构师的核心工作，就是在功能确定的前提下，把质量属性做到最优。
但质量属性不能只说"要快""要稳"——这些是口号，不是标准。架构师需要把每个质量属性拆解成可量化、可验证的指标。
下面，小明带你逐个拆解软考最常考的六大核心质量属性。
六大核心质量属性详解
⚡ 1. 性能（Performance）
定义：系统在规定时间内响应请求的能力。
生活类比：餐厅上菜速度——从你点完菜到菜端上桌，要等多久？一小时能服务多少桌客人？
💡关键指标：📊响应时间— 从发出请求到收到响应的时间间隔（如"页面加载 📊吞吐量— 单位时间内处理的请求数（如"每秒处理1万笔订单"，即 TPS/QPS） 📊资源利用率— CPU、内存、网络、磁盘的使用百分比
架构设计策略：
💡减少计算开销：优化算法、减少中间步骤、避免重复计算引入并发：多线程、异步处理、消息队列削峰增加资源：水平扩容（加服务器）、垂直扩容（升配置）引入缓存：Redis/Memcached缓存热点数据，减少数据库访问资源调度：负载均衡（Nginx）、优先级队列、CDN加速
小明的经验："我们系统最慢的环节是报表查询。加了一层Redis缓存，响应时间从8秒降到0.5秒——这就是性能优化的威力。"
🛡️ 2. 可用性（Availability）
定义：系统在需要时能够正常提供服务的时间比例。
生活类比：电梯的可用率——你每天需要坐电梯的时候，它是不是都能用？如果一年里有5天坏了不能用，你会很崩溃。
💡关键公式：可用性 = MTBF / (MTBF + MTTR)MTBF（Mean Time Between Failures）：平均故障间隔时间——越长越好MTTR（Mean Time To Repair）：平均修复时间——越短越好💡📊 "几个9"到底意味着什么？99%（2个9）→ 年停机3.65天（勉强能用） 99.9%（3个9）→ 年停机8.76小时（大多数系统目标） 99.99%（4个9）→ 年停机52.6分钟（金融级要求） 99.999%（5个9）→ 年停机5.26分钟（电信核心网级别）</