架构评审的实战框架——从技术选型、容量评估到风险识别的标准化流程

一、架构评审为什么需要标准化

在不少组织中，架构评审的实际状态是：架构师提前两小时收到一份方案文档，会上花二十分钟翻完，然后给出一些"我觉得这里应该用 Redis 而不是本地缓存"之类的建议。这种评审方式既无法发现真正的架构风险，也无法帮助团队做出更好的设计决策。

本文提出的框架基于我过去数次参与的架构评审经验，将评审过程拆解为技术选型、容量评估、风险识别、决策记录四个标准环节，每个环节有明确的输入、输出和检查清单。

二、架构评审的四个核心环节

三、环节一：技术选型审查

技术选型审查的核心不是"评审师认为哪个更好"，而是检查"选型依据是否充分、备选方案是否被充分考虑、所选技术是否匹配团队能力"。

检查清单：

1. 是否有明确的选型标准？一个合格的选型方案必须列出至少 3 个候选方案及对比维度。常见的对比维度包括：性能、成熟度、社区活跃度、团队熟悉度、许可证合规性、运维复杂度。
2. 是否进行了 POC 或 Benchmark？如果选型依据是"网上说它很快"或"大厂在用"，那是不够的。至少需要在与生产环境接近的条件下进行性能测试，并记录测试数据和对比结论。
3. 是否有明确的不选理由？对于被淘汰的候选方案，必须记录"为什么不选"——这些信息在未来面对类似选型时有重要参考价值。
4. 团队能力是否匹配？选择 Rust 做高性能组件是一个合理的技术决策，但如果团队里没有人写过 Rust，这也是一个高风险的组织决策。选型评审必须同时考量技术和团队两个维度。

常见选型误区：

• 追求最新的版本：Spring Boot 4.0 刚发布就立马上生产——除非有明确的 Feature 需求，否则应该等 2~3 个小版本后再升级。
• 忽略许可证风险：使用 AGPL 协议的库可能导致商业软件被迫开源。选型时必须做许可证审查。
• 过度引入新技术：每个新引入的技术都带来学习成本、运维成本和故障风险。技术栈的多样性需要控制在团队能承受的范围内。

四、环节二：容量与性能评估

容量评估回答一个问题：系统能否支撑预期的业务量？这不是拍脑袋说"应该可以"，而是需要通过计算和压测来验证。

评估流程：

1. 估算核心接口的 QPS：基于业务预测数据（如日活用户数 × 人均请求量 / 86400 × 峰值系数）。峰值系数通常取 3~5（考虑早晚高峰和促销活动）。
2. 计算资源需求：基于单机 Benchmark（单实例能支撑的 QPS），计算需要的实例数。例如单实例支持 500 QPS，预估峰值 5000 QPS，理论上需要 10 个实例——但由于需要冗余（N-1 容灾），实际需要 12 个实例。
3. 数据存储容量估算：日增数据量 × 保留天数 × 副本数 × 索引膨胀因子。对于 MySQL，索引膨胀因子约为 1.52.0；对于 ES，约为 1.21.5。
4. 关键链路的延迟预算分配：从网关 → 应用 → 缓存 → 数据库，每一跳分配延迟预算。例如总预算 200ms，网关 5ms + 应用 50ms + 缓存 5ms + 数据库 50ms，剩余 90ms 是 Buffer。

/** * 架构评审中的容量评估计算工具 * 基于业务预估数据计算所需的资源配置 */ @Component public class CapacityEstimator { // 默认峰值系数：应对早晚高峰和促销场景 private static final double DEFAULT_PEAK_FACTOR = 4.0; // 冗余系数：N-1 容灾 + 滚动更新所需 private static final double DEFAULT_REDUNDANCY_FACTOR = 1.2; // 单实例安全水位线（不高于 70% 时触发扩容） private static final double SAFE_UTILIZATION = 0.70; /** * 根据业务预估计算所需的实例数 * * @param dailyActiveUsers 日活跃用户数 * @param requestsPerUser 人均请求数 * @param singleInstanceQps 单实例压测 QPS * @return 包含详细计算过程的容量评估报告 */ public CapacityReport estimateInstanceCount(long dailyActiveUsers, double requestsPerUser, int singleInstanceQps) { try { // 计算平均 QPS long dailyTotalRequests = (long) (dailyActiveUsers * requestsPerUser); double avgQps = dailyTotalRequests / 86400.0; // 考虑峰值系数 double peakQps = avgQps * DEFAULT_PEAK_FACTOR; // 计算所需实例数（含冗余） int requiredInstances = (int) Math.ceil( peakQps / (singleInstanceQps * SAFE_UTILIZATION)); int withRedundancy = (int) Math.ceil( requiredInstances * DEFAULT_REDUNDANCY_FACTOR); CapacityReport report = new CapacityReport(); report.setDailyTotalRequests(dailyTotalRequests); report.setAvgQps(avgQps); report.setPeakQps(peakQps); report.setSingleInstanceQps(singleInstanceQps); report.setRequiredInstances(requiredInstances); report.setWithRedundancy(withRedundancy); // 单实例利用率超过安全线时的告警 if (peakQps / withRedundancy > singleInstanceQps * SAFE_UTILIZATION) { report.addWarning("峰值 QPS 下实例利用率将超过安全水位线 " + (SAFE_UTILIZATION * 100) + "%，建议增加实例或优化性能"); } return report; } catch (Exception e) { log.error("容量评估计算失败", e); throw new EstimationException("容量评估异常", e); } } }

五、环节三与四：风险识别与 ADR 记录

风险识别矩阵：

常用方法是从四个维度进行风险盘点：

每个识别出的风险必须有对应的缓解措施和负责人。例如"数据库单点"的缓解措施是"主从 + 自动故障转移 (MHA/Orchestrator)"，负责人是 DBA 团队，完成时间是上线前 1 周。

ADR（架构决策记录）模板：

我推荐的 ADR 格式如下：

# ADR-{序号}: {标题} ## 状态 {提议中 / 已接受 / 已废弃 / 已替代} ## 背景 {为什么需要做这个决策？业务和技术上下文是什么？} ## 决策 {我们选择了什么方案？} ## 备选方案 {考虑了哪些替代方案？为什么没有选？} ## 影响 {这个决策带来哪些正面和负面影响？谁需要知道？} ## 相关 {关联的 ADR、文档或代码}

ADR 的核心理念是：记录决策的上下文和依据，而非仅仅记录结果。当未来有人质疑"为什么当初选了这个方案"时，ADR 就是最好的答案。

架构评审不是"找茬"，而是"提供另一种视角"。评审的目的是帮助团队发现盲区、降低风险、提升方案的鲁棒性——而不是展示评审师的技术能力。一个好的架构评审师应该多问"如果……会怎样"而少说"我认为……"。