架构评审怎么做：一份可落地的检查清单

很多团队的架构评审有两个极端：一种是走形式，方案讲完二十分钟没人提问，上线后集体救火；另一种是挑刺会，资深工程师围着命名和框架选型争论，会议结束没人记得决定了什么。两者源于同一个问题——没说清评审要产出什么。

什么时候做评审

评审应该在方案定稿前，而不是上线前，这个差别决定了能改动的上限。

代码写完之后评审，能提的意见只剩”这里重构一下比较好”，而重构排期通常永远排不上。评审对象是设计：依赖假设是否成立、容量怎么估算、失败路径是什么。这些在写码之前是几张图和一份决策记录，写完就变成几万行已通过测试的代码。

合适的节点有三类：新建服务或引入新组件；对已有系统做结构性改动（分库分表、中间件替换、跨地域部署）；业务规模量级变化之前（大促峰值、海外扩展）。

不需要评审的是局部重构、单表加字段、某个接口的实现方式。把它们放进议程会稀释重要议题，也让团队养成”反正是走过场”的习惯。参与人数控制在五到八人，需要的是能提问的人（熟悉上下游、负责运维、了解业务目标），而不是各岗位的全体代表。

六个必查维度

评审要覆盖的维度是固定的，这样才不会出现”这次想到了那次漏了”。

容量与增长。当前峰值多少、一年后预计多少、瓶颈资源是什么（CPU、连接数、磁盘 IO、下游配额）、扩容是加实例还是要改结构。常见漏洞是只估算平均值忽略尖峰，以及默认下游容量无限。

失败路径。最重要也最常被略过的维度，下面单独展开。

数据一致性。跨服务或跨库的操作哪些必须同时成功；能接受最终一致的部分延迟上限多少；是否存在不可回滚的写操作（发券、扣款、发货）；不一致时靠什么发现（对账任务、校验 job）与修复（人工还是自动补偿）。

可观测性。上线后怎么知道它在正常运行：关键指标有哪些、告警阈值怎么定、能否从单次投诉单号反查完整链路。这项常被推迟到”稳定运行后再补”，结果第一次故障就两眼一抹黑。
成本。资源成本（实例、存储、带宽、跨机房流量）与人力成本（运维复杂度、值班负担、新语言或新中间件的团队学习成本）。一个需要三人专职维护的方案，即使技术先进也要写清这笔账。

运维与回滚。部署步骤、回滚步骤与耗时、回滚是否丢数据；配置是否支持热更新；依赖的下游服务是否有降级方案；谁在上线期间值守。

失败路径要问的具体问题

“失败路径”容易停留在口号层面，评审时应该是一串具体的、要求当场给出数字的问题：

依赖挂了会怎样。列出全部外部依赖（数据库、缓存、消息队列、第三方接口），逐个问：不可用时整体不可用还是部分降级？哪些能力受影响？降级开关在哪。

超时设置是多少。每个远程调用的超时值多少毫秒，为什么是这个数。常见问题是沿用框架默认值没人审视、所有调用统一设 30 秒、下游超时大于上游超时导致线程长期被占用。

重试会不会放大。有没有重试、重试几次、间隔多少、是否带抖动。连串重试是经典的故障放大器：三层嵌套重试能把一次抖动放大成几十倍流量，直接打垮正在恢复的下游。

有没有兜底。返回缓存旧值、走备用链路、返回空列表——哪些接口允许兜底，允许的话用户看到什么。核心链路通常不允许兜底，那它的扩容方案是什么。

并发下的边界。同一操作被两个请求同时触发会怎样（重复提交、并发扣同一份库存）；幂等键是什么；数据库层有没有唯一约束兜住。

发布与回滚期间的状态。滚动发布中新旧版本同时在跑，数据结构是否双向兼容。

实用的做法是要求作者写一张失败模式表，把”应该考虑了”变成可逐项检查的产物：

| 失败模式           | 触发条件           | 表现             | 当前处理   | 待办               |
|-------------------|-------------------|-----------------|-----------|------------------|
| 缓存整体不可用     | 集群故障/网络分区  | 请求全部打到 DB  | 无         | 加本地缓存 + 熔断  |
| 消息积压超过阈值   | 消费端故障         | 业务延迟上升     | 告警       | 补自动扩容策略    |
| 第三方接口超时     | 供应商抖动         | 下单页卡住       | 无         | 设超时 + 降级开关 |

怎么不变成挑刺会

评审失控通常有三个原因，对应三条对策。

没有明确的决策人。每个人都提意见但没人拍板，作者不知道听谁的。对策是会前指定决策人（该系统技术负责人），他可以不采纳某条意见，但要说明理由并承担责任。评审的产出是决策，不是共识投票。

讨论停留在风格层面。命名、日志格式、某个库的用法有代码评审兜底，在架构评审上讨论会挤掉重要议题。对策是把问题分成”设计缺陷”和”实现偏好”，后者移出会议室。

没有留痕。会议结束大家记的版本各不相同，两周后有人拿出当时的约定才发现理解有偏差。对策是产出 ADR（Architecture Decision Record），一次评审一份，篇幅控制在一页：

# ADR-014：订单服务引入本地消息表

## 背景
订单创建后需要可靠通知履约、结算两个下游。当前为同步调用，任一下游故障会导致下单失败且无补偿。

## 候选方案
1. 分布式事务（TCC）：强一致，需改造三个服务业务代码，成本高
2. 本地消息表 + 投递任务：最终一致，改造集中在订单服务

## 决策
采用方案 2。接受毫秒级到秒级的投递延迟；由消费端幂等保证重复投递无害。

## 后果
- 新增 outbox 表与投递任务，增加一项运维依赖
- 下游需提供幂等键，由本 ADR 推动其改造
- 不解决强一致场景，后续如有该需求另行评审

ADR 里”后果”部分价值最高：它把决策代价显性记录下来，半年后有人质疑当初为何这么设计时答案能在文档里找到，而不是变成新的一轮争论。

还有一条容易忽略的规矩：材料要提前发出（例如会前一天），并要求与会者带着问题来，而不是现场听讲解。二十分钟的现场阅读读不懂一个复杂方案。

可复用的检查清单