论软件架构评估

在架构评审准备阶段，我们采用质量属性场景分析来明确性能、可用性和可修改性等评估对象

项目早期，业务人员常用“下单要快、系统要稳定、活动要容易配置”等语言描述质量要求，如果直接据此评估架构方案，容易停留在主观判断，难以形成可以验证的结论

为解决这一问题，我组织需求、开发、测试和运维人员，把关键质量要求整理为具体场景，并按照刺激源、刺激、环境、制品、响应和响应度量进行描述

具体做法是围绕活动高峰、支付回传、库存处理和规则调整等场景，明确受影响模块、系统响应和度量口径

以活动开始后用户集中提交订单为例，刺激源是普通用户，刺激是集中下单请求，环境是活动高峰，制品涉及统一网关、订单模块和库存模块，系统响应是完成限流、校验、库存处理和状态反馈，响应度量则关注主流程响应时间和异常订单恢复情况

通过这种场景化表达，项目组能够结合 Spring Cloud Gateway、Redis、RocketMQ 和 MySQL 等方案讨论架构是否支撑关键场景，避免了只凭经验判断架构优劣的问题

在架构方案比较阶段，我们采用效用树优先级排序来确定评估重点

该平台涉及用户交易、运营管理、支付协作和对账分析等业务，如果把所有质量属性放在同一层面讨论，不但评审时间难以控制，也容易忽视影响上线成败的关键场景

为解决这一问题，我组织项目组以系统总体质量目标为根节点，将性能、可用性、可修改性和安全性作为主要质量属性，再向下分解为活动高峰下单、外部支付延迟、活动规则变更、异常订单追溯等场景，并从业务重要性和实现风险两个角度排序

为解决这一问题，我组织项目组以系统总体质量目标为根节点，将性能、可用性、可修改性和安全性作为主要质量属性，再向下分解为活动高峰下单、外部支付延迟、活动规则变更、异常订单追溯等场景，并从业务重要性和实现风险两个角度排序

以活动高峰下单场景为例，该场景与用户体验、交易成功率和库存准确性直接相关，因此被列为重点评估对象

通过效用树排序，架构评估从泛泛讨论转变为围绕重点质量属性展开，项目资源也能够优先投入到交易主链路的方案验证中

在评估结论形成阶段，我们采用风险点与权衡点分析来检查架构决策的影响

如果只看到缓存提高性能、消息队列削峰、服务拆分便于扩展，就可能忽视数据一致性、链路追踪和运维复杂度等问题

为解决这一问题，我在核心方案评审中要求项目组记录关键决策对应的收益、风险和缓解措施

为解决这一问题，我在核心方案评审中要求项目组记录关键决策对应的收益、风险和缓解措施

以库存处理方案为例，项目组原计划在用户下单时直接访问数据库完成库存扣减，这种方式逻辑简单，但在活动高峰期容易造成数据库压力集中

通过这种风险和权衡分析，项目组没有把架构评估停留在优点描述上，而是提前识别了关键风险，并为上线后的运行维护准备了可执行的处理措施