架构评审会议模板：把讨论收束到决策
会议要服务决策
我做架构评审这些年，见过太多这样的场景：八个人坐在会议室里，讨论了一个半小时，最后谁也没说清楚到底决定了什么。有人说「我觉得应该用 Kafka」，另一个人说「RabbitMQ 在上一家公司用得挺好」，然后两个人围绕消息队列选型吵了四十分钟，其他人在旁边刷手机。
这不是评审，这是聊天。
架构评审会议的核心问题是——它需要产出一个明确的决策，而不是一堆散落的意见。会议模板的作用，就是把这个决策过程结构化，让每个参会者知道该准备什么、该讨论什么、该带走什么。
Michael Nygard 在 2011 年提出 Architecture Decision Record（ADR）时说过一句话：「架构是其决策的积累」。如果评审会议不能把这些决策清晰地记录下来，那这个会议就只是噪音。
这篇文章会给出一套可以直接用的会议模板，覆盖会前材料、会中流程、会后输出三个阶段，并配上案例、检查清单和常见问题对照。
理论根基：从 ATAM 到 ADR
架构评审不是某个团队的发明。它背后有几十年的方法论积累。
ATAM：架构权衡分析法
卡内基梅隆大学软件工程研究所（SEI）的 Rick Kazman 等人在 2000 年提出了 Architecture Tradeoff Analysis Method（ATAM）。这套方法的核心思路是：不直接评价架构好不好，而是先定义质量属性场景（比如「在 1000 并发下响应时间不超过 200ms」），再逐一检查架构是否能满足这些场景，最后识别出敏感点、权衡点和风险点。
ATAM 的意义在于——它把架构评审从「我觉得这个方案不行」变成了「这个方案在 X 场景下有 Y 风险」。讨论的锚点从个人偏好转移到了可验证的约束条件。
ADR：轻量级决策记录
ADR 是 ATAM 在工程实践中的轻量延伸。Michael Nygard 的原始模板包含五个部分：Title、Status、Context、Decision、Consequences。后来社区扩展出了 Considered Options、Rationale 等字段，但核心思想没变——把「为什么选了这个方案」和「放弃了什么」写清楚。
Martin Fowler 在 2026 年 3 月更新的文章中强调，ADR 不只是文档，它本身就是一种思考工具：写 ADR 的过程会迫使决策者把自己的逻辑理顺，尤其是在有多个利益相关方参与的情况下。
TOGAF 架构评审清单
The Open Group 的 TOGAF 框架提供了一份架构评审清单，覆盖系统工程的多个维度：供应商稳定性、源码可获取性、企业配置管理、标准合规性等。这份清单适合大型企业做架构治理时使用，对于中小团队来说偏重，但其中「先检查约束条件，再讨论方案」的思路值得借鉴。
三种方法论交汇在一起，指向同一个结论：架构评审的重点不是选最优方案，而是识别风险和约束，让决策有据可循。
三个真实案例：没有模板的评审是怎么翻车的
案例一：消息队列选型——讨论了 90 分钟，没有结论
场景：电商平台需要引入异步消息队列处理订单，团队在 Kafka、RabbitMQ、RocketMQ 之间犹豫。架构评审会议上，三个人各执一词。
翻车过程：
// ❌ 坏做法：没有预读材料，评审会变成头脑风暴
// 会议记录（原始版）
// 张三：我觉得 Kafka 吞吐量大，适合订单场景
// 李四：RabbitMQ 路由灵活，我们团队熟悉
// 王五：RocketMQ 支持事务消息，订单需要这个
// 张三：Kafka 也能做，只是配置复杂一点
// 李四：但我们团队对 RabbitMQ 更熟，出问题能排查
// ...（循环了 40 分钟）
// 会议结束，没有结论，下周再议
问题诊断：没有人在会前明确「我们到底在权衡什么」。三个人其实在讨论不同的维度——吞吐量、团队熟悉度、事务消息能力——但没有一张表把这些维度拉齐。
修复方案：引入结构化的方案对比模板。
<!-- ✅ 好做法：会前提交方案对比表 -->
## 方案对比：订单异步消息队列选型
| 维度 | Kafka | RabbitMQ | RocketMQ |
|------|-------|----------|----------|
| 吞吐量 | 百万级/秒 ✅ | 万级/秒 | 十万级/秒 |
| 事务消息 | 不支持原生事务 ❌ | 不支持 ❌ | 原生支持 ✅ |
| 团队熟悉度 | 低 ⚠️ | 高 ✅ | 中 |
| 运维复杂度 | 高（依赖 ZK/KRaft） | 低 ✅ | 中 |
| 消息回溯 | 支持 ✅ | 不支持 ❌ | 支持 ✅ |
| 社区生态 | 最活跃 ✅ | 活跃 | 活跃（国内为主） |
**推荐方案**：RocketMQ
**推荐理由**：订单场景需要事务消息保证一致性，这是硬性约束。
Kafka 吞吐量大但不支持事务消息，RabbitMQ 吞吐量和事务都不满足。有了这张表，会议从 90 分钟缩短到 25 分钟。讨论集中在「事务消息是不是硬性约束」和「团队能否在两周内上手 RocketMQ」两个具体问题上，最终当场决策。
案例二：微服务拆分——每个人都在画自己的架构图
场景：一个单体应用准备拆分成微服务，技术负责人发起架构评审。会上六个参会者带了六张不同的架构图，每张图的边界划分、服务粒度、数据流都不一样。
翻车过程：
// ❌ 坏做法：没有统一的架构描述模板，每个人用自己的表达方式
// 架构图 A（张三画的）：
// [用户服务] --> [订单服务] --> [库存服务]
//
// 架构图 B（李四画的）：
// [前端网关] --> [用户中心] --> [交易中心] --> [仓储中心]
// [交易中心] --> [支付中心]
//
// 架构图 C（王五画的）：
// 按领域模型画了 12 个限界上下文，每个限界上下文又分了子域
问题诊断：不是谁画错了，而是三个人在讨论不同层次的问题。张三在说调用链路，李四在说服务边界，王五在说领域模型。没有统一的描述框架，评审变成了鸡同鸭讲。
修复方案：使用 arc42 模板的「上下文视图 + 容器视图」两层结构，要求所有方案用同一套模板描述。
统一的描述框架解决了「各说各话」的问题。评审会议的讨论从「你的图对不对」变成了「在这个约束下，哪种拆分更合理」。
案例三：数据库选型——评审通过了，上线后踩坑
场景：一个内部工具项目，评审会上选了 MongoDB 作为主数据库。理由是「文档模型灵活，适合快速迭代」。上线三个月后，需要做复杂的关联查询和报表统计，MongoDB 的聚合管道写不动了，团队被迫引入 PostgreSQL 做数据同步，维护成本翻倍。
翻车过程：
// ❌ 坏做法：评审只讨论了当前需求，没有考虑演进约束
// ADR-0012（原始版）
// 标题：内部工具使用 MongoDB
// 背景：项目需要快速上线，数据结构不固定
// 决策：选择 MongoDB 作为主数据库
// 后果：开发速度快，文档模型灵活
//
// 缺失的字段：
// - 没有列出「考虑过的选项」（PostgreSQL、MySQL）
// - 没有分析「非功能需求」（报表、关联查询）
// - 没有设定「 reassess 条件」（什么时候需要重新评估）
问题诊断：ADR 只记录了「为什么选」，没有记录「放弃了什么」和「什么情况下需要改」。这种 ADR 在三个月后回头看，根本不知道当初有没有考虑过关系型数据库。
修复方案：扩展 ADR 模板，强制要求填写 Considered Options、Non-functional Requirements 和 Reassess Conditions。
<!-- ✅ 好做法：完整的 ADR 模板 -->
## ADR-0012：内部工具数据库选型
**状态**：Superseded by ADR-0031
**背景**：内部工具项目，需要 4 周内上线 MVP。数据结构不固定，
字段可能频繁增减。初期用户量 < 500，无复杂报表需求。
**非功能需求**：
- 查询模式：以单文档 CRUD 为主（初期）
- 关联查询：初期不需要，3 个月后可能需要统计报表
- 运维：团队无专职 DBA，需要托管服务
**考虑的选项**：
1. MongoDB Atlas（文档模型，托管服务）
2. PostgreSQL on RDS（关系模型，托管服务）
3. MySQL on RDS（关系模型，托管服务）
**决策**：选择 MongoDB Atlas 作为 MVP 阶段数据库。
**理由**：
- MVP 阶段数据结构变化频繁，文档模型减少 migration 成本
- MongoDB Atlas 免费层足够 MVP 使用
- 3 个月后如果出现复杂查询需求，通过 MongoDB Connector for BI
桥接到分析层，或迁移到 PostgreSQL
**后果**：
- ✅ 开发速度：MVP 2 周完成数据层
- ⚠️ 风险：如果报表需求提前出现，需要提前迁移
- 🔄 重新评估条件：当出现 3 个以上多表关联查询需求时
**后续**：该 ADR 在第 11 周因报表需求触发重新评估，
被 ADR-0031（PostgreSQL + Redis 缓存方案）替代。这份完整的 ADR 让后来接手的人能清楚知道：当初为什么选 MongoDB、什么时候发现不合适、怎么做的迁移决策。
会议模板：三个阶段的完整清单
把上面的案例经验抽象出来，形成一套可复用的模板。
阶段一：会前材料（决定会议是否需要开）
会前材料的核心目标是让提案人把问题想清楚，而不是让评审人在会上帮他想。
| 材料项 | 必须/可选 | 说明 |
|---|---|---|
| 问题背景与目标 | 必须 | 要解决什么问题？不解决会怎样？ |
| 非目标 | 必须 | 这次不解决什么？避免讨论范围膨胀 |
| 约束条件 | 必须 | 时间、预算、团队能力、技术栈限制 |
| 推荐方案及理由 | 必须 | 你推荐什么？为什么？ |
| 备选方案（至少 2 个） | 必须 | 考虑过什么？为什么放弃？ |
| 架构图或数据流图 | 必须 | 用统一模板，至少包含上下文视图 |
| 风险与待决问题 | 必须 | 你识别到的风险，以及需要会议讨论的问题 |
| 性能/成本估算 | 可选 | 涉及资源投入时必须提供 |
| ADR 草稿 | 可选 | 如果决策明确，提前写好 ADR 节省时间 |
硬性规则：如果「推荐方案」和「备选方案」两项为空，会议取消。这不是评审，这是让评审委员会帮你做方案。
阶段二：会中流程（30-45 分钟）
| 时间段 | 内容 | 负责人 | 规则 |
|---|---|---|---|
| 0-5 分钟 | 提案人概述背景和推荐方案 | 提案人 | 只复述材料重点，不展开讨论 |
| 5-20 分钟 | 澄清性问题 | 全体 | 只问「什么意思」「为什么」，不提「我建议」 |
| 20-35 分钟 | 讨论权衡与风险 | 全体 | 围绕方案对比表和风险清单，不跳话题 |
| 35-40 分钟 | 确认决策 | 决策人 | 明确结论：通过/有条件通过/退回修改 |
| 40-45 分钟 | 分配行动项 | 决策人 | 每条行动项指定 Owner + 截止时间 |
角色分工：
// 评审会议的四个角色
//
// 1. 提案人（Author）
// - 负责准备材料和捍卫方案
// - 有权在讨论中修改方案
//
// 2. 决策人（Decider）
// - 只有一人，拥有最终拍板权
// - 通常是 Tech Lead 或架构师
// - 不是投票制，是「一人决策」
//
// 3. 评审人（Reviewer）
// - 提供专业意见，没有否决权
// - 从各自领域（安全、性能、运维）提问
//
// 4. 主持人（Facilitator）
// - 控制时间和讨论范围
// - 打断偏离主题的讨论
// - 记录决策和行动项
阶段三：会后输出（24 小时内）
| 输出项 | 内容 | 格式 |
|---|---|---|
| 决策结果 | 通过/有条件通过/退回 + 关键理由 | 会议纪要文档 |
| ADR | 完整的决策记录 | Markdown，存入 docs/adr/ |
| 行动项列表 | 每条有 Owner + Deadline | 项目管理工具 |
| 待补充材料 | 需要在下次评审前补充的内容 | 清单，指定 Owner |
关键原则：会议纪要不是逐字稿。只记录影响决策的信息——关键问题、不同意见、确认结论和行动项。
方案对比表：四种常见评审模式
不同规模和类型的架构决策适合不同的评审模式。
| 维度 | 轻量 ADR 评审 | 正式架构评审会 | ATAM 评估 | 异步评审 |
|---|---|---|---|---|
| 适用场景 | 单个技术选型 | 系统级架构变更 | 大型系统质量属性评估 | 小决策、跨时区团队 |
| 参与人数 | 2-4 人 | 5-8 人 | 5-15 人 | 不限 |
| 时间投入 | 1-2 小时（含写 ADR） | 30-45 分钟会议 | 1-3 天 | 异步 2-3 天 |
| 材料要求 | ADR 草稿 | 完整方案文档 + 架构图 | 质量属性场景 + 架构模型 | ADR 或 RFC 草稿 |
| 产出 | 批准的 ADR | 决策 + 行动项 | 风险评估报告 + 建议 | 评论汇总 + 决策 |
| 优点 | 轻量、可追溯 | 面对面沟通充分 | 系统化、覆盖全 | 无需协调时间 |
| 缺点 | 不适合复杂权衡 | 容易超时、需要强主持 | 成本高、需要培训 | 反馈质量参差 |
| 典型使用 | 数据库选型、框架选择 | 微服务拆分、技术栈迁移 | 金融系统、安全合规场景 | 配置变更、小功能设计 |
ADR 模板对比：三种主流格式
ADR 的格式选择取决于团队规模和工具链。
| 维度 | Nygard 原始模板 | MADR（Markdown ADR） | Y-Statements |
|---|---|---|---|
| 字段数 | 5 个 | 9 个 | 1 句话 |
| 核心字段 | Title, Status, Context, Decision, Consequences | + Considered Options, Rationale, Pros/Cons | 「We decided to X, in the context of Y, for the sake of Z」 |
| 文档长度 | 半页到一页 | 一到两页 | 一句话 |
| 适合团队 | 中小团队，刚引入 ADR | 中大型团队，需要完整追溯 | 敏捷团队，极简文档 |
| 工具支持 | adr-tools | adr-tools + VS Code 插件 | 无特定工具 |
| 优点 | 简单、学习成本低 | 信息完整、支持自动化 | 极度轻量 |
| 缺点 | 缺少选项对比 | 字段多，写起来慢 | 无法承载复杂决策 |
| 推荐场景 | 大多数团队的首选 | 需要审计追溯的场景 | 小决策的快速记录 |
好/坏做法对比：从材料到决策
<!-- ❌ 坏做法 A：背景描述模糊 -->
## 背景
现在的系统性能不太好，需要优化。
我们考虑引入缓存来改善。
<!-- ✅ 好做法 A：背景描述有数据支撑 -->
## 背景
商品详情页 P99 响应时间从 120ms 退化到 850ms（过去 30 天），
主要原因是每次请求都查询 MySQL。
QPS 约 2000，其中 85% 是重复商品的重复查询。
目标：将 P99 降到 200ms 以内。<!-- ❌ 坏做法 B：没有非目标 -->
## 方案
引入 Redis 集群作为全系统统一缓存层。
<!-- ✅ 好做法 B：明确非目标，防止范围膨胀 -->
## 方案
引入 Redis 缓存商品详情页查询结果。
## 非目标
- 不缓存搜索结果（由 Elasticsearch 负责）
- 不缓存用户会话数据（后续单独评审）
- 不做缓存预热（MVP 阶段流量可接受冷启动）<!-- ❌ 坏做法 C：风险描述空泛 -->
## 风险
- 缓存可能不一致
- 运维复杂度增加
<!-- ✅ 好做法 C：风险有场景、有应对方案 -->
## 风险
1. 缓存一致性：商品价格变更后缓存可能延迟更新
- 应对：商品变更时主动删除缓存 key（Cache-Aside 模式）
- 残余风险：极端情况下 3 秒内可能读到旧价格（TTL=3s）
2. 缓存穿透：恶意请求不存在的商品 ID
- 应对：对空结果缓存 30 秒 + 布隆过滤器
3. Redis 单点故障：当前计划使用单节点
- 应对：启用 Redis Sentinel 自动故障转移
- 接受风险：MVP 阶段允许 5 分钟缓存不可用<!-- ❌ 坏做法 D：行动项模糊 -->
## 行动项
- 张三：调研 Redis 集群方案
- 李四：看看有没有现成的缓存框架
<!-- ✅ 好做法 D：行动项有 Owner、截止时间和交付物 -->
## 行动项
| # | 行动项 | Owner | 截止时间 | 交付物 |
|---|--------|-------|---------|--------|
| 1 | 完成 Redis Sentinel 部署方案 | 张三 | 06/30 | 架构文档 + 成本估算 |
| 2 | 评估 Spring Cache vs Lettuce 客户端 | 李四 | 06/28 | 对比文档（含 benchmark） |
| 3 | 制定缓存 key 命名规范 | 王五 | 06/27 | 规范文档，提交 PR |评审常见问题速查表
| 常见问题 | 症状 | 解法 |
|---|---|---|
| 评审变聊天 | 讨论了 30 分钟还在发散 | 主持人打断，拉回议程 |
| 没有结论 | 会议结束没人知道决定了什么 | 最后 5 分钟强制确认决策 |
| 材料缺失 | 提案人只带了一页 PPT | 取消会议，要求补充材料 |
| 范围膨胀 | 从数据库选型聊到公司战略 | 明确非目标，超出范围的记为「后续议题」 |
| 过度设计 | 评审要求在 MVP 阶段考虑百万并发 | 回到约束条件，用数据说话 |
| ADR 写不出 | 决策理由写不清楚 | 说明决策本身可能没想清楚，退回重新思考 |
| 评审太晚 | 代码已经写完才来评审 | 前置评审节点到方案设计阶段 |
| 反复评审 | 同一个议题评审了三次还没结论 | 检查是否有信息缺失，指定 Owner 限期补充 |
架构评审检查清单
会前准备阶段
- 问题背景和目标描述清晰，有数据支撑
- 非目标已明确列出，防止讨论范围膨胀
- 约束条件（时间、预算、团队能力、技术栈）已列出
- 推荐方案有明确的理由，不是「因为流行」
- 至少列出 2 个备选方案，说明放弃原因
- 架构图使用团队统一的模板和符号
- 风险已识别并附有应对方案
- 需要会议讨论的问题已明确列出
会议进行阶段
- 提案人在 5 分钟内完成概述，不展开细节
- 澄清性问题阶段不混入方案建议
- 讨论围绕方案对比表和风险清单展开
- 偏离主题的讨论被主持人及时打断
- 决策人在最后 5 分钟给出明确结论
- 每条行动项指定了 Owner 和截止时间
会后跟进阶段
- 会议纪要在 24 小时内发布
- ADR 已写入
docs/adr/目录并编号 - 行动项已录入项目管理工具
- 需要补充的材料已指定 Owner 和截止日期
- 上次评审的遗留行动项已跟踪
落地建议
如果你的团队从来没有做过结构化的架构评审，不要一步到位引入 ATAM。从以下三步开始：
-
先写 ADR。不管多小的决策，用 Nygard 的五字段模板写下来。重点不是模板，而是养成「把理由写清楚」的习惯。
-
用方案对比表代替口头讨论。任何涉及技术选型的评审，要求提案人在会前提交一张对比表。这张表本身就是思考过程的外化。
-
从 30 分钟会议开始。按照本文的会中流程模板，严格控制时间。前几次可能会有些生硬，但坚持三轮之后，团队会形成节奏。
当团队习惯了这套流程，再根据需要引入更重的评估方法。大多数团队需要的不是更复杂的评审框架，而是把基础动作做到位。
参考资料
- Martin Fowler - Architecture Decision Record：ADR 概念的系统性介绍，含模板示例和工具推荐
- Ruchit Suthar - 30-Minute Architecture Review Meetings：30 分钟架构评审会议实操指南，含角色分工和反模式
- EA Transformation - Best Practices for Useful Architecture Reviews：架构评审最佳实践，涵盖评审范围、时机和焦点
- Kazman et al. - The Architecture Tradeoff Analysis Method (IEEE)：ATAM 方法论原始论文
- The Open Group - TOGAF Architecture Review Checklist：TOGAF 框架的架构评审清单
- Hava.io - Architecture Review Board Checklist：云架构评审清单，覆盖 8 个评估维度
- Microsoft Learn - Maintain an ADR：微软 Well-Architected 框架中的 ADR 实践指南
- adr.github.io - Architectural Decision Records：ADR GitHub 组织，含模板和工具集