【软考-系统架构设计师】软件架构分析方法（SAAM）
真实场景：评估一个电商平台的“订单处理系统”架构
假设你是一个架构师，设计了一个处理用户下单、支付、库存扣减的微服务系统。在编码之前，你组织了一次SAAM评估会议，参会者有产品经理、开发工程师、测试工程师和运维工程师。
SAAM 评估过程分为 6个步骤（也有说5步，但核心内容一致）。
SAAM评估六步走：
第1步：形成场景（收集未来的各种需求变更）
大家开始头脑风暴，提出未来可能的需求：
- 场景A（促销活动）：双十一时，要支持“下单后30分钟内不支付，订单自动取消”的功能。
- 场景B（支付方式）：下个季度要接入刷脸支付。
- 场景C（风控）：如果用户下单地址突然变更，需要触发人工审核。
- 场景D（数据分析）：运营希望实时看到每秒的下单成功数。
- 场景E（容灾）：如果数据库挂了，能否快速切换到备用库？
这些就是“场景”，它们代表了未来对系统的“折腾”。
第2步：描述架构（展示你的设计蓝图）
你打开设计图，向大家解释：
- 系统由订单服务、支付服务、库存服务和消息队列组成。
- 用户下单后，订单服务同步调用库存服务扣减库存，然后通过消息队列异步通知支付服务发起支付。
- 数据库用的是 MySQL 主从架构。
第3步：场景分类与排序（区分难易度，投票选重点）
大家对场景进行分类和投票：
-
直接场景（现有架构直接支持）：
- 场景D（实时数据）：运维工程师说：“这个简单，直接消费消息队列里的下单成功消息，推到实时计算引擎就行，不用改业务代码。”
-
间接场景（需要修改架构才能支持）：
- 场景A（超时关单）：需要新增一个“定时任务服务”来扫描超时订单。
- 场景B（刷脸支付）：需要在支付服务里新增一个支付渠道接口。
- 场景C（风控审核）：需要在下单流程中插入一个同步调用风控服务的步骤。
- 场景E（数据库容灾）：需要引入更高级别的数据库中间件来实现透明切换。
经过投票，大家最关心的是场景A（超时关单）和场景E（数据库容灾），因为它们直接影响核心交易流程的稳定性和用户体验。
第4步：单个场景评估（分析每个重要变更的代价）
评估场景A（超时关单）：
- 需要做的修改：
- 新建一个定时任务服务。
- 在订单服务的数据库里新增一个“订单状态”字段，用于标记“待支付”。
- 定时任务服务定期扫描“待支付”超时的订单，然后调用订单服务和库存服务的接口进行取消和库存释放。
- 评估代价：改动较大，涉及一个新服务和多个现有服务的接口变更，预计需要 15 人/天。
- 风险点：定时扫描可能给数据库带来压力。
评估场景E（数据库容灾）：
- 需要做的修改：
- 引入数据库中间件（如 MyCat 或 ProxySQL）。
- 修改所有服务的数据库连接配置，指向中间件地址。
- 配置中间件的故障检测和切换策略。
- 评估代价：改动巨大，涉及基础设施层变更，需要停机，预计需要 30 人/天。
- 风险点：中间件本身可能成为新的单点故障。
第5步：场景交互评估（看看改动之间是否冲突）
- 场景A的方案严重依赖数据库（扫描订单表）。
- 场景E要引入的数据库中间件，可能会影响场景A的定时扫描性能（例如，中间件的查询转换效率较低）。
结论：这两个场景的修改方案存在潜在冲突。SAAM 帮我们提前发现了这个架构设计上的权衡点（Trade-off）。也许我们需要为“定时扫描”这种批处理作业设计一个单独的数据库只读从库，而不是直接扫描主库。
第6步：总体评估（得出最终结论和建议）
评估会议结束，你生成报告：
- 架构优点：当前基于微服务和消息队列的异步架构，解耦性好，像“接入刷脸支付”（场景B）这种需求，只需要修改支付服务，很容易实现。
- 架构风险与敏感点：
- 数据库是最大的敏感点：多个场景（A、E）的修改都围绕着它，它的设计和稳定性直接影响全局。
- 性能瓶颈点：未来要插入风控审核（场景C）等同步操作，会增加延迟，可能影响性能。
- 建议：
- 提前为数据库设计更优的容灾方案和读写分离策略。
- 考虑将一些同步调用（如扣库存）改为异步化，提升流程的灵活性和抗压能力。
总结
通过这个真实的例子，你可以看到 SAAM 的本质：
- 它不是测试系统现在能不能用，而是评估未来好不好改。
- 方法：通过收集未来的“需求故事”（场景），看现在的设计图（架构）能不能经得住这些“折腾”。
- 结果：找出现有架构中哪些地方很灵活（优点），哪些地方一碰就碎（风险点和敏感点），从而在编码之前就优化设计，降低未来的修改成本。
SAAM 是一种非常实用且成本较低的架构评审方法，特别适合在开发前期识别潜在问题。