架构评审清单：好方案要能被验证，而不是只会画图
一、架构评审不是展示 PPT
很多架构评审会陷入两个极端：要么只展示漂亮的系统图，要么陷入具体实现细节无法讨论。真正有效的评审，应该围绕业务目标、约束条件、风险点和验证方式展开。架构方案不是为了证明设计者想得多完整，而是为了让团队在投入开发前看清取舍。
一个好方案应该回答几个问题：它解决什么业务问题，为什么现在要做，替代方案是什么，最主要的风险在哪里，如何灰度上线，失败后如何回滚，后续容量如何扩展。如果这些问题答不清楚，再精美的图也不能说明方案可靠。
二、评审结构：从目标到验证闭环
flowchart TD A[业务目标] --> B[现状问题] B --> C[约束条件] C --> D[候选方案] D --> E[取舍比较] E --> F[风险清单] F --> G[验证计划] G --> H[灰度与回滚]评审时建议先讲目标和非目标。目标说明这次要解决什么，非目标说明这次不解决什么。很多架构争论来自边界不清，例如一次缓存改造被讨论成全链路性能治理，一次服务拆分被讨论成组织架构调整。边界明确后，讨论才会聚焦。
候选方案至少要有两个。即使最终选择方案 A，也要说明为什么不选择方案 B。比如同步调用和异步消息、集中式网关和客户端 SDK、单库扩容和分库分表，都有不同成本。架构评审的价值，正是在这些取舍中形成共识。
三、清单模板：把模糊问题变成可检查项
下面是一份简化的评审清单，可以作为 Java 后端项目的起点。
review: goal: "降低订单查询 P95 延迟" scope: include: ["订单详情接口", "缓存读取链路"] exclude: ["数据仓库查询", "推荐系统"] risks: - "缓存击穿导致数据库压力升高" - "主从延迟导致短时间旧数据" validation: - "压测 3000 QPS 下 P95 小于 120ms" - "灰度 5% 流量观察 24 小时" rollback: - "关闭缓存读开关" - "恢复旧版本路由"清单不是形式主义，它能逼迫方案写清楚验证标准。比如“性能提升”太模糊，应该改成“核心接口 P95 从 300ms 降到 150ms 以下”；“稳定可靠”太模糊，应该改成“单个 Redis 节点故障时接口错误率不超过 0.5%”。能被验证的目标，才有工程意义。
四、常见盲区：容量、数据、上线和组织成本
架构评审最容易漏掉容量和数据迁移。新方案在小流量下跑通，不代表能承受高峰；新表结构设计合理，不代表历史数据迁移顺利。评审中应该明确容量估算、压测方案、数据校验、双写策略和回滚窗口。
上线计划也要具体。灰度比例、观察指标、报警阈值、负责人、回滚命令和预计耗时，都应写在方案里。不要把“上线后观察”当作计划。观察什么、谁观察、异常到什么程度回滚，这些才是工程团队真正需要的信息。
组织成本同样重要。一个方案如果要求多个团队长期维护复杂协议，或者让业务开发必须理解底层路由规则，就会增加隐性成本。架构不是只看技术优雅，也要看团队能否稳定执行。温和一点说，能被团队长期维护的方案，通常比看起来最先进的方案更值得选择。
还要补上运行期复盘。方案上线后一周或一个完整业务周期内，应回看当初设定的指标是否真正达成，包括延迟、错误率、资源成本、告警数量、开发接入成本和用户反馈。很多架构方案在评审时逻辑成立，但上线后暴露出隐性成本。如果没有复盘，团队会把这些成本默认接受下来，下一次设计仍然重复同样的问题。评审闭环不只发生在会议室，也发生在生产指标和故障记录里。
五、总结
架构评审的核心是让方案可验证、风险可讨论、上线可回滚。好的评审不止画图，还要讲清目标、约束、取舍、指标和执行计划。把模糊判断变成清单和证据，团队才能在复杂系统演进中少一些盲目，多一些确定性。
