架构评审的 checklist

一句话速记

架构评审不是”证明方案好”，而是在方案被代码实现之前，用 checklist 扫一遍最可能出问题的 10 个维度。评审围绕四个核心问题：① 这方案在正常流量下工作吗？（正确性）；② 在异常情况下怎么表现？（韧性）；③ 6 个月后这个方案会被骂吗？（演进性）；④ 团队能安全地实现和运维它吗？（可落地性）。一次评审最多讨论 3 个重大问题——超过 3 个，方案退回重做，不开马拉松评审会。

通俗解释（5 分钟版）

架构评审就像一个飞前检查清单：
飞行员不是"感觉飞机能飞"，而是按 checklist 一项一项过：
发动机？✓ 襟翼？✓ 燃油？✓ 通讯？✓

你的架构方案也需要一个 checklist，否则你只会按"感觉"来判断：
"感觉应该可以吧" → 上线 → "感觉错了" → 事故

关键细节

评审 checklist

□ 1. 需求对齐
   方案解决了正确的需求吗？
   有没有过度设计（设计了一个能承载 100 倍流量的系统，
   但业务只需要 1 倍）？
   有没有"设计了一个更优雅的方案，但它解决的是
   未来可能有的需求而不是现在确实有的"？

□ 2. 核心数据流
   数据从入口到出口，经过了哪些系统？
   每个跳转点：
     - 失败时怎么处理？（重试？降级？直接报错？）
     - 有没有 timeout？timeout 设了多少？
     - 同步还是异步？如果改成异步会怎样？

□ 3. 数据库设计
   新表/新字段有没有索引？
   有没有可能会全表扫描的查询？
   有没有在循环里查 DB？能不能合并成一次查询？
   数据量大到什么量级会需要分库分表？（现在多少？半年后多少？）

□ 4. 接口设计
   是向后兼容的吗？（现有调用方不需要改）
   如果不是，有多少个调用方需要改？谁负责通知和跟踪？
   有没有限流？（不设限流 = 假设下游永远不会被打爆）
   超时和重试策略是什么？

□ 5. 异步与消息
   如果用了消息队列：
     - 消息丢失了怎么办？（业务影响是什么）
     - 消息重复了怎么办？（要不要幂等？怎么幂等？）
     - 消息积压了怎么办？（消费速度 < 生产速度时）

□ 6. 失败模式
   每个外部依赖（DB/Redis/下游服务/MQ）如果不可用，
   系统会怎么样？
   有没有降级方案？降级到什么程度？
   "依赖挂了，服务就挂" → 这个依赖的可用性 ≤ 你的可用性

□ 7. 安全
   有用户输入的地方有没有参数校验？
   有没有 SQL 拼接（必须参数化查询）？
   有没有可能让用户 A 看到用户 B 的数据？（越权）
   有没有敏感数据（密码/手机号/身份证号）被打印到日志里？

□ 8. 可观测性
   新功能有没有埋点（P99 耗时、错误率）？
   有没有关键路径的日志（带 TraceID）？
   如果这个方案上线后出了问题，你要看什么指标、查什么日志？

□ 9. 部署与迁移
   上线有灰度吗？灰度多久放完？
   上线需要和其他团队的改动配合吗？依赖顺序是什么？
   有回滚方案吗？回滚后数据兼容吗？

□ 10. 运维
   这个方案引入的新组件，团队 oncall 的人能处理吗？
   有没有 runbook？（"半夜 3 点这个组件挂了，怎么做"）

评审结果分级

Approved（通过）：
  ✓ 所有 checklist 项都合理回答
  ✓ 没有已知的"会导致事故"的漏洞
  → 可以开始写代码

Approved with Comments（有条件通过）：
  ✓ 核心设计没问题
  ✓ 有 1-3 个非致命的待改进项
  → 改进项记录下来，用 TODO/JIRA 跟踪，但不阻塞开发

Revise & Resubmit（退回修改）：
  ✗ 有 3 个以上的重大问题
  ✗ 或者有 1 个致命问题（比如"消息丢失会导致
     用户付了钱但没收到订单"）
  → 退回修改，下次再评。不要在原评审会上
     临时 brainstorm 怎么修——那是浪费时间

评审会怎么开

前（至少 1 天）：
  方案文档发出来，参与人 async 读过再上会

中（45-60 分钟）：
  1. 作者用 10 分钟讲方案核心 + 最大的风险点
     （不要从头念文档——大家都看过了）
  2. 15 分钟澄清问题（只问"是什么"不讨论"好不好"）
  3. 30 分钟讨论——聚焦最可能出问题的地方
  4. 5 分钟总结：通过 / 有条件通过 / 退回修改 +
     记录决定和待办项

后（24 小时内）：
  发一个决定总结到群里：
  - 结论：Approved / Approved with Comments / R&R
  - 关键讨论点（3 行以内）
  - 待办项（如果有）+ Owner + 截止日

延伸追问

• Q：架构评审和 RFC 有什么区别？ → 高度重叠。RFC 偏向”方案本身的设计合理性”（为什么这么设计、备选有哪些），架构评审偏向”方案的系统性风险”（数据一致性、可用性、安全、运维）。实践中可以合二为一——一次会议做两件事。
• Q：小改动也需要架构评审吗？ → 不需要。架构评审的门槛：新增一个服务、改核心数据模型、引入新中间件、跨服务接口变更。CRUD 功能、bug fix、UI 调整不需要。
• Q：评审时争论不下怎么办？ → 设时间上限。如果在 15 分钟内无法达成共识，TL 做决定。不是谁的方案更好——是在有限信息下有人做决定然后往前走、以后再调整，比永远争论不下要好。

我的记法

• 10 项 checklist：需求、数据流、DB、接口、异步、失败、安全、可观测、部署、运维
• 最多 3 个问题：超过 3 个 = 退回重做，不开马拉松评审
• 评审结论：Approved / Approved with Comments / Revise & Resubmit
• 一句话：「架构评审不是证明好，是用 checklist 找漏洞——找到了是评审的成功，不是方案的失败」

状态

• 已背速记
• 能讲通俗版
• 能答追问