架构评审清单

用途：架构评审会前自查 + 会上评审要点。评审前把每一项过一遍，能通过再开会。 用法：逐项勾选；「不适用」需写出理由，而不是留空。

0. 评审会信息

• 项目 / 系统：
• 评审人：
• 评审日期：
• 方案版本 / 链接：

1. 业务与目标

• 业务目标明确（要解决什么问题、服务谁、多大体量）
• 非功能目标明确（QPS / 延迟 / 可用性 / 成本预算）
• 与现有系统边界清晰（谁负责什么，接口归属）
• 明确「本期不做」的范围（防蔓延）

2. 架构与设计

• 分层与模块划分清晰，职责单一
• 数据流 / 状态流画清楚了（关键时序图）
• 关键路径与旁路（异步、降级）区分清楚
• 无过度设计：架构复杂度和业务复杂度匹配
• 依赖方向合理，无循环依赖
• 技术选型有 POC / 数据支撑，而非「听说很好用」

3. 容量与性能

• 预估峰值流量与 2 倍以上冗余说明
• 关键链路延迟预算（P99）可达成
• 数据库 / 缓存 / 消息的容量测算完成
• 存在明显的热点 / 单点？如何缓解

4. 可用性与稳定性

• 单点识别与高可用方案（多副本 / 故障转移）
• 降级预案：依赖挂了怎么办（熔断、降级、兜底）
• 限流与保护策略（防止雪崩）
• 可观测性：指标、日志、链路追踪全覆盖
• 告警规则与值班 Oncall 明确
• 发布 / 回滚方案明确（灰度、快速回滚）

5. 数据一致性

• 数据一致性级别定义清楚（强一致 / 最终一致）
• 对账与补偿机制（失败重试、幂等）
• 数据迁移 / 双写方案评审过

6. 安全与合规

• 鉴权、越权防护（水平 / 垂直）
• 敏感数据加密与脱敏
• 合规要求（数据留存、隐私）已确认

7. 成本

• 资源成本估算（机器 / 存储 / 流量 / AI token）
• 成本随规模增长的趋势可控

8. 演进与可维护性

• 文档与架构图会沉淀在哪里
• 团队是否有能力维护该技术栈
• 半年后回头看，这套方案还成立吗

结论

• 通过
• 有条件通过（条件：__________________）
• 打回重做（原因：____________________）