架构权衡如何被分析

架构决策很少只改善一个方面。缓存可能降低读取延迟，却增加一致性和失效复杂度；拆分服务可能支持独立部署，也会增加网络故障与协调成本。权衡分析不是给方案做总分排名，而是找出业务目标之间的张力、关键假设和可能失效的位置。

业务目标决定哪些属性重要

评审应先明确系统为何存在、哪些结果不可接受、未来可能怎样变化。相同技术方案用于公共资讯站和资金交易系统时，风险排序不会相同。没有业务背景，所有质量属性都容易被写成“越高越好”。

利益相关方对后果的理解也不同。运营关注恢复和诊断，开发关注修改成本，安全人员关注资产与威胁，用户关注响应与可用性。权衡分析要让这些关注点进入同一讨论，而不是只由实现团队猜测。

质量属性场景描述刺激来源、刺激、环境、受影响制品、系统响应和响应度量。例如，在依赖服务部分不可用时，核心读取请求仍在规定延迟内返回降级结果。这样的场景能够检查具体架构机制。

“高性能”“高可用”无法直接比较。只有说明负载、故障和目标值，才能判断缓存、冗余或限流解决了什么问题，并识别它们引入的新风险。

敏感点是某项架构决策对质量属性影响显著的位置，例如缓存过期时间对新鲜度和后端负载都很敏感。一个决策同时影响多个属性且方向不同，就形成权衡点。

风险来自未经验证的重要假设，例如预计写入量很低、第三方接口始终幂等或单一区域故障可以接受。非风险则是已有充分机制和证据支持的决策。分析结果应记录风险主题、证据缺口和后续验证动作，而不是只保留会议结论。

不同方案必须面对同一组场景、规模和约束。用成熟方案的生产数据对比另一个方案的理想估算，结论没有可比性。原型、容量测试、故障演练和历史指标可以降低关键不确定性。

成本也不仅是采购价格。迁移时间、团队技能、运维负担、供应商约束和退出成本都可能决定方案是否可持续。某个属性的优化若超过业务需要，新增复杂度会成为长期风险。

SEI 的 Architecture Tradeoff Analysis Method 有明确参与角色、步骤和产出，用于系统化识别风险、敏感点与权衡点。团队可以借鉴其场景和风险思路，但一次内部设计会不能因此被称为正式 ATAM。

无论采用何种评审形式，结果都应进入决策记录：选择了什么、基于哪些场景和证据、放弃了什么、何时需要重新评估。权衡不会在会议结束后消失，负载、组织和业务目标改变时，原结论也需要重新验证。

Carnegie Mellon University Software Engineering Institute：Architecture Tradeoff Analysis Method Collection，https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
Carnegie Mellon University Software Engineering Institute：Quality Attribute Workshop Collection，https://www.sei.cmu.edu/library/quality-attribute-workshop-collection/