Day29-07｜8.1.3 质量属性场景描述：让架构目标可讨论、可设计、可验证

一、教材定位

质量属性场景描述是系统质量属性与架构评估之间的桥梁。性能、可靠性、安全性、可修改性等质量目标如果只停留在“高性能”“高可靠”“安全可控”等形容词层面，就无法指导架构决策，也无法形成测试标准。质量属性场景把抽象愿望转换为具体刺激、环境、系统响应和度量指标，使需求人员、架构师、开发人员、测试人员和运维人员能够围绕同一目标协作。

二、质量属性场景的六个要素

一个完整的质量属性场景通常包含刺激源、刺激、环境、受刺激对象、响应和响应度量六个要素。

场景描述的重点不在于格式本身，而在于消除歧义。例如“系统要支持高并发”没有说明并发请求是什么、在什么数据规模下、哪些接口、允许多长响应时间；“促销期间每秒5000次下单请求，95%请求在300毫秒内完成，超过容量的请求进入排队且不丢失”才是可设计和可验证的描述。

三、质量属性场景的来源

场景来源包括业务目标、用户需求、法规标准、运营指标、历史故障、架构风险、开发维护经验和未来演进计划。用户常提出功能和体验目标，运维人员关注恢复和监控，安全人员关注攻击和越权，开发人员关注变更和测试，架构师要把这些来源整合起来。

历史故障尤其有价值。一次数据库连接耗尽可以转化为容量和资源隔离场景；一次错误配置导致的全站故障可以转化为配置校验、灰度和回滚场景；一次接口升级造成的数据错误可以转化为版本兼容和契约测试场景。

四、场景的分类

1. 一般场景

一般场景描述某类质量属性通常关注的刺激和响应，适合在架构设计早期建立候选场景。例如性能的一般场景包括用户请求、系统处理和响应时间；可用性的一般场景包括故障发生、检测、恢复和服务继续提供。

2. 具体场景

具体场景将一般场景结合当前系统的业务和环境。例如“在春运售票高峰期，外部用户并发查询余票，系统在六万并发连接下保持95%查询响应不超过200毫秒”。具体场景可以直接用于架构权衡和测试计划。

3. 变化场景

变化场景描述需求、业务规则、技术环境或外部接口发生变化时，系统应如何修改。例如“新增一种支付渠道后，核心订单服务无需修改，适配和回归测试在五个工作日内完成”。变化场景适合评估可修改性、可扩展性和互操作性。

4. 故障和攻击场景

故障场景描述节点、网络、存储、消息、外部系统或配置发生异常时的系统响应；攻击场景描述未授权访问、恶意输入、凭证泄露、重放和数据篡改时的防护和审计。这类场景能够避免架构只描述正常路径。

五、从场景到架构策略

场景本身不是解决方案。架构师要根据刺激和响应目标选择策略。例如高峰请求场景可能需要缓存、负载均衡、水平扩展、限流和排队；节点故障场景可能需要冗余、健康检查、故障转移和数据恢复；新增规则场景可能需要策略接口、规则引擎或插件；越权访问场景可能需要集中认证、细粒度授权、审计和零信任边界。

同一个场景可能有多个候选策略，架构师需要比较成本、复杂度和副作用。缓存可能改善性能但增加一致性风险，异步消息可能提高吞吐但引入延迟和补偿，强加密可能提高安全但增加资源消耗。因此场景描述必须带有优先级，才能指导权衡。

六、响应度量的设计

响应度量应满足明确、可测、可重复和与业务目标相关。性能常用平均值、百分位、吞吐和资源利用率，但只看平均响应时间可能掩盖长尾；可用性需要结合服务时间、故障时间和恢复时间；可靠性要关注失败率、数据正确率和恢复后重放；可修改性可以用修改模块数、交付周期和回归缺陷衡量。

指标还要说明统计窗口、负载条件和采集方法。例如“可用率99.99%”要说明统计周期、计划维护是否计入、哪些接口属于核心服务；“响应时间小于200毫秒”要说明百分位、数据规模、网络范围和是否包含外部调用。

七、场景优先级与冲突处理

场景应根据业务影响、发生概率、不可逆程度和验证成本排序。高优先级场景通常包括核心交易正确性、关键数据安全、重大故障恢复和高峰性能。场景之间可能冲突，应记录权衡而不是分别承诺最高指标。

例如在线教育系统在课程查询时可以接受短暂旧数据，但在支付和扣课时必须保证一致；同一个系统中不同场景的质量优先级并不相同。架构师应通过业务分级、数据分区、读写模型和不同服务等级实现差异化目标。

八、场景与架构决策记录

每个关键场景都应追踪到架构决策。决策记录至少包括背景、场景、候选方案、选择方案、理由、后果、验证方式和责任人。例如针对“节点宕机后核心服务五分钟内恢复”，决策可能是多实例、无状态服务、自动健康检查和数据库高可用；后果是增加部署和运维复杂度；验证方式是定期故障演练和恢复时间监控。

这种追踪关系可以形成需求到测试的闭环：质量场景对应架构策略，架构策略对应组件和配置，组件对应测试用例，测试用例对应结果和监控指标。缺少其中一环，目标就可能停留在文档中。

九、案例分析：在线医疗平台场景化设计

某在线医疗平台需要支持预约、问诊、处方和支付。质量场景包括：高峰预约时每秒处理3000个请求且不产生重复号源；医生服务暂时不可用时患者能够看到明确状态并可重试；处方数据只能被授权角色访问并保留审计；新增支付渠道不修改问诊核心；数据库节点故障后关键预约数据在规定时间内恢复。

架构策略分别为：预约服务使用幂等键、号源锁定和排队保护；问诊服务使用超时、降级和状态提示；处方服务采用细粒度授权、加密和审计；支付通过适配器和稳定接口扩展；数据库采用高可用和备份恢复。测试包括高峰压测、重复提交、权限越权、支付契约、节点故障和恢复后数据校验。通过场景，业务目标、架构设计和测试证据建立了直接联系。

十、练习题

题1

把“系统要高可用”改写为一个完整质量属性场景。

参考答案

当生产环境中的一个应用节点发生宕机时，负载均衡和健康检查机制应在30秒内识别故障并将新请求切换到健康节点；已有请求按照幂等和重试策略处理，核心业务持续可用，用户错误率不超过规定阈值，故障和切换事件进入监控与审计系统。

题2

为什么场景需要说明环境？

参考答案

同一系统在正常、峰值、维护、网络分区和故障恢复环境下的表现可能不同。没有环境就无法确定负载、资源和故障条件，指标也无法重复验证。

题3

“新增一个业务规则不影响已有功能”应如何设计和验证？

参考答案

可以通过策略接口、规则引擎、插件或版本化配置隔离规则变化，保持核心流程和数据契约稳定；通过规则单元测试、回归测试、灰度发布、旧版本对比和异常回滚验证不影响已有功能。

十一、论文写作素材

论文中可以写：项目初期将模糊的质量目标转化为性能、可用性、安全性和可修改性场景，为每个场景明确刺激、环境、对象、响应和度量；架构评审时将场景映射到缓存、冗余、授权、插件和数据隔离等策略；通过压测、故障演练、契约测试和安全测试建立证据，并将运行指标持续反馈到场景和架构决策中。

十二、今日复盘

质量属性场景的六要素是刺激源、刺激、环境、对象、响应和响应度量。复习时要能够把抽象目标写成可验收句子，并进一步说明架构策略、权衡、测试方法和运行证据。