| 题源类型 | 押题 |
| 年份/批次 | |
| 适用项目 | 某互联网公司线上商品交易与运营平台 |
| 主题概念 | 软件架构评估通常在架构设计形成后、详细设计开展前进行，主要围绕架构能否满足需求、质量属性是否得到体现、潜在风险是否可识别等方面进行分析 |
| 常见方法 | 质量属性场景、效用树、风险点、敏感点和权衡点等 |
| 已选论文点 | 质量属性场景分析 / 效用树优先级排序 / 风险点与权衡点分析 |
| 项目位置/技术/需求 | 在架构评审准备阶段，我们采用质量属性场景分析来明确性能、可用性和可修改性等评估对象 |
| 解决的问题 | 项目早期，业务人员常用“下单要快、系统要稳定、活动要容易配置”等语言描述质量要求，如果直接据此评估架构方案，容易停留在主观判断，难以形成可以验证的结论 |
| 解决的方法 | 为解决这一问题，我组织需求、开发、测试和运维人员，把关键质量要求整理为具体场景，并按照刺激源、刺激、环境、制品、响应和响应度量进行描述 |
| 具体的实现 | 具体做法是围绕活动高峰、支付回传、库存处理和规则调整等场景，明确受影响模块、系统响应和度量口径 |
| 例子 | 以活动开始后用户集中提交订单为例，刺激源是普通用户，刺激是集中下单请求，环境是活动高峰，制品涉及统一网关、订单模块和库存模块，系统响应是完成限流、校验、库存处理和状态反馈，响应度量则关注主流程响应时间和异常订单恢复情况 |
| 效果 | 通过这种场景化表达，项目组能够结合 Spring Cloud Gateway、Redis、RocketMQ 和 MySQL 等方案讨论架构是否支撑关键场景，避免了只凭经验判断架构优劣的问题 |
| 项目位置/技术/需求 | 在架构方案比较阶段，我们采用效用树优先级排序来确定评估重点 |
| 解决的问题 | 该平台涉及用户交易、运营管理、支付协作和对账分析等业务，如果把所有质量属性放在同一层面讨论，不但评审时间难以控制，也容易忽视影响上线成败的关键场景 |
| 解决的方法 | 为解决这一问题，我组织项目组以系统总体质量目标为根节点，将性能、可用性、可修改性和安全性作为主要质量属性，再向下分解为活动高峰下单、外部支付延迟、活动规则变更、异常订单追溯等场景，并从业务重要性和实现风险两个角度排序 |
| 具体的实现 | 为解决这一问题，我组织项目组以系统总体质量目标为根节点，将性能、可用性、可修改性和安全性作为主要质量属性，再向下分解为活动高峰下单、外部支付延迟、活动规则变更、异常订单追溯等场景，并从业务重要性和实现风险两个角度排序 |
| 例子 | 以活动高峰下单场景为例，该场景与用户体验、交易成功率和库存准确性直接相关，因此被列为重点评估对象 |
| 效果 | 通过效用树排序，架构评估从泛泛讨论转变为围绕重点质量属性展开，项目资源也能够优先投入到交易主链路的方案验证中 |
| 项目位置/技术/需求 | 在评估结论形成阶段，我们采用风险点与权衡点分析来检查架构决策的影响 |
| 解决的问题 | 如果只看到缓存提高性能、消息队列削峰、服务拆分便于扩展，就可能忽视数据一致性、链路追踪和运维复杂度等问题 |
| 解决的方法 | 为解决这一问题，我在核心方案评审中要求项目组记录关键决策对应的收益、风险和缓解措施 |
| 具体的实现 | 为解决这一问题，我在核心方案评审中要求项目组记录关键决策对应的收益、风险和缓解措施 |
| 例子 | 以库存处理方案为例，项目组原计划在用户下单时直接访问数据库完成库存扣减，这种方式逻辑简单，但在活动高峰期容易造成数据库压力集中 |
| 效果 | 通过这种风险和权衡分析，项目组没有把架构评估停留在优点描述上，而是提前识别了关键风险，并为上线后的运行维护准备了可执行的处理措施 |