【架构实战】架构评审方法论：让每个决策经得起考验

一、一次没有评审的架构决策让我后悔3年

2019年，我决定用MongoDB做订单存储。

理由很简单：

• 订单结构复杂，MySQL要设计很多表
• MongoDB文档模型灵活，直接存JSON
• 网上说MongoDB性能好

没有评审，我自己拍板了。

3年后，问题来了：

如果当时做了架构评审，这个问题5分钟内就会被发现：

• 运维同事：“我们团队没人会MongoDB”
• DBA：“MongoDB的事务性能不行，订单场景不合适”
• 架构师：“你考虑过数据一致性吗？”

二、架构评审流程

2.1 完整流程图

┌─────────────────────────────────────────────────────────────────┐
│ 架构评审完整流程 │
│ │
│ 阶段1：准备阶段（评审前3天） │
│ ├── 编写架构设计文档（ADR） │
│ ├── 准备技术选型对比表 │
│ ├── 性能评估报告 │
│ ├── 风险分析文档 │
│ └── 发送评审材料给评审团 │
│ │
│ 阶段2：评审会议（1-2小时） │
│ ├── 架构师讲解方案（20分钟） │
│ ├── 评审团提问质疑（30分钟） │
│ ├── 讨论替代方案（20分钟） │
│ └── 总结和投票（10分钟） │
│ │
│ 阶段3：结论阶段 │
│ ├── 通过 → 进入开发阶段 │
│ ├── 有条件通过 → 修改后复审 │
│ └── 不通过 → 重新设计方案 │
│ │
│ 阶段4：跟进阶段 │
│ ├── 记录评审结论 │
│ ├── 跟进Action Item │
│ └── 项目结束后复盘 │
│ │
└──────────────────────────────────────────────────────────────────┘

2.2 架构设计文档模板

# 架构设计文档 – 订单系统重构

## 1. 背景与目标

### 1.1 背景
– 当前订单系统单表已超过5000万条记录
– 查询性能下降，P99延迟超过3秒
– 需要支持未来3年10倍增长

### 1.2 目标
– 查询P99延迟 < 200ms
– 支持日均1000万订单
– 系统可用性 99.99%

### 1.3 非目标
– 不涉及支付系统改造
– 不涉及物流系统改造

## 2. 整体架构

### 2.1 架构图
[插入架构图]

### 2.2 核心设计
– 分库分表：按user_id分库，按order_id分表
– 读写分离：主库写，从库读
– 缓存策略：Redis缓存热点数据

## 3. 技术选型

| 组件 | 方案 | 备选方案 | 选择理由 |
|——|——|———-|———-|
| 分库分表中间件 | ShardingSphere | MyCat | 社区活跃，功能完善 |
| 数据库 | MySQL 8.0 | PostgreSQL | 团队经验丰富 |
| 缓存 | Redis Cluster | 本地缓存 | 支持分布式 |

## 4. 详细设计

### 4.1 数据模型
[插入ER图]

### 4.2 接口设计
[插入API文档链接]

### 4.3 部署架构
[插入部署图]

## 5. 性能评估

### 5.1 容量规划
– 预计QPS：5000
– 单库QPS：3000
– 需要2个分库

### 5.2 压测结果
[插入压测报告链接]

## 6. 风险分析

| 风险 | 影响 | 概率 | 应对方案 |
|——|——|——|———-|
| 分片键选择错误 | 高 | 中 | 提前做数据分布分析 |
| 从库延迟 | 中 | 高 | 关键业务读主库 |
| 扩容困难 | 高 | 低 | 预留2倍容量 |

## 7. 实施计划

| 阶段 | 内容 | 时间 | 负责人 |
|——|——|——|——–|
| 阶段1 | 表结构设计 | 1周 | 张三 |
| 阶段2 | 分库分表开发 | 2周 | 李四 |
| 阶段3 | 数据迁移 | 1周 | 王五 |
| 阶段4 | 灰度上线 | 1周 | 赵六 |

## 8. 附录

– [需求文档链接]
– [参考架构链接]
– [相关技术文档链接]

三、评审清单详解

3.1 业务层面

业务层面评审清单：

□ 业务场景理解
□ 核心业务流程是什么？
□ 用户是谁？使用场景是什么？
□ 业务痛点在哪里？

□ 业务增长预估
□ 预计用户增长？
□ 预计数据增长？
□ 预计流量增长？

□ 业务对齐
□ 是否和产品经理确认过需求？
□ 是否和运营确认过场景？
□ 是否和业务方确认过验收标准？

□ 业务风险
□ 方案是否影响现有业务？
□ 迁移方案是否可行？
□ 回滚方案是否完善？

3.2 技术层面

技术层面评审清单：

□ 技术选型
□ 选型理由是否充分？
□ 是否有备选方案对比？
□ 是否有POC验证？
□ 社区活跃度如何？
□ 是否有生产案例？

□ 性能
□ 是否有性能瓶颈？
□ 是否做了压测？
□ 是否有缓存策略？
□ 数据库索引是否合理？

□ 可靠性
□ 是否有单点故障？
□ 是否有容灾方案？
□ 是否有降级熔断？
□ 数据一致性如何保证？

□ 安全
□ 是否有安全风险？
□ 是否有鉴权机制？
□ 敏感数据是否加密？
□ 是否有防攻击措施？

□ 扩展性
□ 是否支持水平扩展？
□ 是否预留了容量？
□ 是否考虑了未来需求？

3.3 运维层面

运维层面评审清单：

□ 部署
□ 部署方案是否可行？
□ 是否需要新增资源？
□ 是否有部署文档？

□ 监控
□ 是否有监控指标？
□ 是否有告警规则？
□ 是否有日志收集？

□ 应急
□ 是否有应急预案？
□ 是否有回滚方案？
□ 是否有值班机制？

□ 成本
□ 运维成本是否可控？
□ 是否需要新增人力？
□ 许可证费用如何？

3.4 团队层面

团队层面评审清单：

□ 能力匹配
□ 团队是否有相关经验？
□ 是否需要培训？
□ 学习曲线如何？

□ 人力资源
□ 是否有足够人力？
□ 是否有backup？
□ 是否依赖外部资源？

□ 知识传承
□ 是否有文档？
□ 是否有培训计划？
□ 是否有代码Review机制？

四、踩坑实录

坑1：评审走过场

问题：评审会变成走过场，大家都不认真提意见。

踩坑场景：
每次评审会，大家都说"没问题"，结果上线后问题一堆。因为大家觉得"反正是架构师定的，出了问题也是他的责任"。

解决方案：

# 评审机制改进：

1. 评审前提前3天发材料
– 让评审团有时间阅读
– 要求每人至少提3个问题

2. 设置"魔鬼代言人"
– 每次评审指定一人专门找茬
– 轮流担任，避免针对个人

3. 匿名投票
– 避免从众心理
– 确保真实意见

4. 评审结果考核
– 评审团对决策质量负责
– 出了问题复盘时追究

坑2：只评审不跟进

问题：评审提了很多意见，但没有跟进落实。

踩坑场景：
评审会上提了10条意见，会后没人跟进，项目上线后发现问题还在。

解决方案：

# 跟进机制：

1. 记录Action Item
– 每条意见对应一个Action Item
– 明确负责人和截止日期

2. 定期跟进
– 每周周会汇报进展
– 项目经理负责跟进

3. 复审机制
– 重要修改需要复审
– 确保意见落实到位

4. 项目复盘
– 项目结束后回顾评审意见
– 总结经验教训

坑3：评审太晚

问题：方案已经开发完了才评审，改不动了。

踩坑场景：
开发团队闷头做了2个月，写完代码才提交评审。评审发现设计有问题，但代码都写完了，改不动。

解决方案：

# 评审时机：

1. 概念验证阶段
– 技术选型评审
– 确定技术方向

2. 设计阶段
– 架构设计评审
– 确定整体方案

3. 详细设计阶段
– 详细设计评审
– 确定实现细节

4. 开发阶段
– 代码Review
– 确保实现质量

⚠️ 开发前必须完成设计评审！

坑4：评审人不对

问题：参加评审的人都不了解业务，提不出有价值的意见。

踩坑场景：
评审团都是技术背景，没人懂业务。结果技术方案没问题，但业务逻辑有漏洞。

解决方案：

# 评审团组成：

必须参加：
– 架构师（技术决策）
– 技术负责人（实现可行性）
– 产品经理（业务对齐）
– 运维代表（运维可行性）
– 安全代表（安全评估）

可选参加：
– 测试代表（测试可行性）
– DBA（数据库评估）
– 业务专家（业务场景）

坑5：没有记录

问题：评审讨论了很多，但没有记录，后来忘了。

踩坑场景：
评审会上讨论热烈，但没有会议纪要。过了几个月，大家忘了当时的决策理由，出了问题不知道为什么这样设计。

解决方案：

# 评审记录模板：

## 评审会议纪要

**时间**：2024-01-15 14:00-16:00
**地点**：会议室A
**参与人**：张三、李四、王五、赵六
**记录人**：张三

### 评审议题
订单系统分库分表方案

### 讨论要点
1. 分片键选择
– 方案A：order_id
– 方案B：user_id
– 最终选择：user_id分库，order_id分表
– 理由：大部分查询带user_id，可避免跨库查询

2. 数据迁移方案
– 讨论了双写方案和停机迁移方案
– 最终选择：双写迁移，风险更低

### 决策结论
– 状态：有条件通过
– 条件：
1. 补充数据迁移详细方案
2. 完善回滚预案

### Action Item
| 编号 | 内容 | 负责人 | 截止日期 |
|——|——|——–|———-|
| 1 | 编写数据迁移方案 | 李四 | 2024-01-20 |
| 2 | 编写回滚预案 | 王五 | 2024-01-20 |
| 3 | 复审 | 张三 | 2024-01-22 |

五、最佳实践

5.1 评审原则

架构评审五大原则：

1. 尽早评审
– 设计阶段就评审
– 不要等开发完了再评

2. 充分准备
– 提前发材料
– 评审团认真阅读

3. 多方参与
– 技术、业务、运维、安全
– 多角度发现问题

4. 记录决策
– 会议纪要
– ADR文档

5. 跟进落实
– Action Item跟进
– 项目复盘

5.2 评审检查表

评审前检查：
□ 评审材料已发送
□ 评审团已确认参加
□ 会议室已预订
□ 投影设备已测试

评审中检查：
□ 架构师讲解清晰
□ 所有问题已记录
□ 决策理由已说明
□ 结论已达成共识

评审后检查：
□ 会议纪要已发送
□ Action Item已分配
□ 后续安排已确认

六、血的教训

没有评审的架构决策就是赌博。你赌赢10次，输1次就够你喝一壶。

我那次MongoDB的决策，输得很惨：

• 迁移花了3个月
• 团队加班加点
• 业务受影响
• 个人信誉受损

如果当时做了评审，这些问题在5分钟内就会被发现。

七、思考题

个人观点，仅供参考