适用项目：线上商品的销售与运营平台
复习状态：已复习 1 次 (2026-05-22T09:27:10)
软件架构评估是在架构设计完成后、详细设计开始前进行的一项重要活动，目的是验证当前架构方案是否满足系统的质量属性需求，发现潜在风险并做出合理的优化决策。常用的评估方法是 ATAM，它通过构造质量属性场景和效用树，识别架构中的风险点、敏感点和权衡点，帮助架构师在多个质量目标之间做出取舍。线上商品的销售与运营平台既要保证高峰期的订单处理性能，又要保证支付和用户数据的可靠性，同时还要让促销规则和运营活动能够快速上线。这些目标之间天然存在冲突：提高性能可能需要增加缓存和冗余，而增加冗余又会提升数据一致性保障的复杂度。因此，在本项目中，我围绕质量属性场景与效用树、风险与敏感点分析、权衡点决策三个方面对平台架构进行了系统评估。
首先，我构建了质量属性效用树并定义了关键评估场景。效用树是 ATAM 的核心工具，将系统的质量属性目标逐层分解为可度量的具体场景，使评估有据可依。在本项目中，我以性能、可用性、安全性和可修改性作为一级质量属性节点。性能下分解为订单提交响应时间和商品查询吞吐量两个场景：订单提交接口在 3000 并发用户下 95% 请求响应时间不超过 1 秒，商品搜索接口在 5000 QPS 下返回结果不超过 300 毫秒。可用性下分解为数据库故障切换时间和服务重启恢复时间两个场景：MySQL 主库故障后 20 秒内完成主从切换，关键服务 Pod 异常退出后 60 秒内重新拉起并恢复正常。安全性下分解为越权访问拦截和敏感数据加密两个场景。可修改性下分解为新增满减活动规则的上线时间场景。每个场景设定了刺激源、刺激方式、环境、制品和预期响应五个要素，共形成 20 个质量属性评估场景，为后续的架构分析与优化提供了明确的评审基准。
其次，我通过场景走查识别架构中的风险点和敏感点。风险点是指架构中可能导致系统在某些场景下无法满足质量需求的薄弱环节，敏感点是指系统质量对某个架构决策特别敏感的地方。在本项目中，我组织架构师、开发负责人和测试负责人对各场景逐一走查。在走查订单提交响应时间场景时，发现订单服务在调用库存服务和营销服务时采用同步 RPC 方式，库存锁定的耗时直接累加到订单提交响应时间上，当库存服务响应缓慢时会导致订单提交超时，这属于一个风险点。在走查数据库故障切换场景时，发现主从切换的耗时对读写分离中间件的感知时间非常敏感，如果健康检查间隔设置过长会拉长不可用窗口，这属于一个敏感点。在走查越权访问场景时，发现后台接口只在网关层校验角色，业务服务层未进行数据归属校验，存在水平越权风险。通过场景走查，共识别出 14 个风险点和 8 个敏感点，并逐一设计了缓解措施，例如将库存锁定从同步调用改为异步预占加消息通知，降低订单提交对库存响应速度的依赖。
最后，我针对架构中的权衡点进行了分析和优化决策。权衡点是指多个质量属性之间存在冲突的架构决策点，优化一个属性可能会牺牲另一个属性。在本项目中，最典型的权衡点出现在订单数据的存储方案上：如果采用强一致性的数据库事务，订单与库存、优惠券的状态一致性能得到保证，但响应时间会因锁等待和跨表事务而增加，降低性能；如果采用最终一致性方案，响应时间更快但可能出现短时间内订单状态与库存状态不一致的情况。另一个权衡点出现在支付回调的可靠性设计上：如果要求支付回调 100% 不丢失，需要增加消息队列持久化和回调重试机制，但这会增加系统的复杂度。经过评估讨论，我决定在订单存储上核心交易链路采用强一致性事务，非核心链路如积分发放采用最终一致性；在支付回调上配置消息持久化和至少一次投递策略，同时在下游消费方实现幂等处理。通过权衡分析，共解决 6 个架构冲突点，最终架构方案在性能和可靠性之间达到了合理的平衡，评估通过后顺利进入详细设计阶段。