架构特征是什么
架构特征是非功能维度的设计目标，也叫 -ilities：可用性、可伸缩性、弹性、性能、安全性、可部署性、可测试性、可维护性等。它们相互制约，提升一项往往牺牲另一项，例如强一致换取更高延迟、加密换取吞吐下降。因此架构工作的核心不是“全都满足”，而是排出优先级、给出可度量目标，并明确本版愿意让步的是什么。
常见特征
| 特征 | 含义 | 度量示例 |
|---|---|---|
| 可用性 | 系统可对外服务的时间比例 | 月度可用率、单次故障恢复时长 |
| 可伸缩性 | 资源增加时容量与性能的提升程度 | 水平扩容后吞吐变化曲线 |
| 弹性 | 负载波动时按需自动伸缩的能力 | 扩容触发到生效的时长 |
| 性能 | 单位请求的延迟与吞吐 | p95 延迟、峰值 QPS |
| 安全性 | 抵御攻击与保护数据的能力 | 高危漏洞数、越权测试通过率 |
| 可维护性 | 修改与排错的难易程度 | 变更前置时间、缺陷修复时长 |
| 可部署性 | 发布与回滚的效率与风险 | 发布耗时、回滚成功率 |
基本信息
| 识别时机 | 需求阶段就要识别，架构阶段才有取舍依据 |
|---|---|
| 量化要求 | 每个特征配上场景、指标与度量方式，否则无法验证 |
| 优先级 | 显式排序为第一、第二、第三，避免“全都要” |
| 让步项 | 写明为满足首要特征主动牺牲了哪些次要特征 |
| 记录方式 | 写入架构决策记录，作为后续评审基线 |
典型使用场景
- 架构选型：按特征优先级比较候选方案，而不是按技术偏好
- 评审答辩：回答“为什么这样设计”时给出特征与取舍证据
- 压测目标制定：把性能与可用性特征转成可执行的测试指标
- 预算与资源申请：用可用率与扩容指标解释成本构成
- 技术债排序：以特征受损程度判断哪些债优先还
- 上线验收：逐项核对特征目标是否被监控覆盖
特征数量要克制：一份架构方案同时宣称兼顾十项特征，通常意味着没有任何一项被真正验证过。
架构特征缺失或不排序时，评审容易退化成对具体技术栈的口味之争，最终决策无法追溯。