架构评审的目的不是证明方案“足够高级”，而是在投入大量研发和运维成本之前，尽早发现需求遗漏、单点故障、容量不足、安全风险、数据问题和不可运维设计。一套有效的评审流程必须有明确入口、固定材料、可追踪结论和整改闭环。
一、评审适用范围
出现以下情况时，应发起架构评审：
新系统、新平台或重要基础设施建设；
核心系统的大版本升级或架构重构；
引入新的数据库、中间件、云服务或技术栈；
跨机房、跨地域、上云或容灾方案调整；
预计流量、数据量或用户规模显著增长；
涉及核心数据、互联网暴露、合规或高风险变更；
已发生重大故障，需要通过架构整改避免再次发生。
普通功能迭代可以走轻量评审；涉及核心链路、资金、身份、权限和数据安全的方案，应执行完整评审。
二、评审角色与职责
架构师负责组织和把关，但不应代替方案负责人完成设计。
三、完整流程
发起申请
↓
材料准备
↓
架构预审
↓
正式评审会议
↓
形成评审结论
↓
问题整改与复核
↓
上线前检查
↓
上线后验证与复盘1. 发起申请
方案负责人提交评审申请，写明业务背景、计划上线时间、影响范围、参与团队和期望评审时间。建议在开发工作大规模展开前完成评审，为方案调整预留时间。
2. 材料准备
评审材料至少包含：
业务目标、范围以及不在本次建设范围内的内容；
功能需求与非功能需求；
系统上下文图、组件图、部署图和关键数据流图；
外部系统、第三方服务和基础设施依赖；
容量模型、性能目标和成本估算；
高可用、容灾、备份与恢复方案；
身份权限、网络安全、数据保护和审计方案；
监控、日志、告警、发布、回滚和应急预案；
候选方案、最终选择、已知风险和演进路线。
材料应在正式会议前至少一个工作日发给评审人员。
3. 架构预审
预审由架构师与方案负责人完成，重点检查材料是否齐全、需求是否清楚、图和文字是否一致，以及是否存在明显阻断项。材料不完整时应退回补充，不把正式会议变成临时需求澄清会。
4. 正式评审会议
建议控制在 60 至 90 分钟，按照以下顺序进行：
业务负责人说明目标、范围和成功标准；
方案负责人讲解架构、关键链路和核心决策；
评审人员围绕可靠性、性能、安全、数据、运维和成本提问；
对高风险问题明确责任人、整改要求和完成时间；
主持人总结结论，不在会上无限争论实现细节。
所有问题都应记录，不能只依赖会议录音或口头承诺。
四、评审重点
需求与边界
目标是否可衡量，系统边界是否清晰；
是否区分当前需求和未来设想；
上下游依赖失败时系统如何处理。
可靠性与容灾
是否存在单点故障；
超时、重试、限流、熔断和降级是否合理；
RTO、RPO 和可用性目标是否明确；
备份能否恢复，切换后能否正常回切。
性能与容量
峰值并发、吞吐量、响应时间和数据增长量是否明确；
容量估算是否有依据；
是否安排压测，并定义扩容阈值。
数据与一致性
数据所有权、生命周期和一致性要求是否明确；
缓存、消息队列和数据库之间如何处理重复、乱序和丢失；
数据迁移是否支持校验、回滚和审计。
安全与合规
身份认证、最小权限和敏感操作审批是否落实；
传输与存储是否加密；
互联网入口、网络边界、密钥管理和审计日志是否完整。
可运维性与成本
是否有指标、日志、链路追踪和业务告警；
发布、回滚、扩容、故障定位是否可以标准化执行；
云资源、许可证、带宽、存储和人员成本是否可接受。
五、评审结论分级
评审结束后只能给出以下三类结论之一：
“原则通过”如果没有问题清单、责任人和截止时间，实际上等于没有结论。
六、问题分级与整改闭环
阻断项：可能造成重大故障、数据丢失、安全事件或合规问题，上线前必须关闭；
高优先级：显著影响可靠性、性能或运维效率，应在上线前完成；
一般项：不阻断上线，但必须进入技术债清单并约定完成时间；
建议项：用于后续优化，不作为当前版本强制要求。
每个问题都要记录问题描述、风险影响、整改要求、责任人、计划时间、验证证据和最终状态。关闭问题时应提供配置、测试报告、演练记录或监控截图等证据。
七、上线前与上线后检查
上线前确认阻断项已经关闭，性能测试、备份恢复、故障切换、安全扫描、监控告警和回滚预案已经验证。上线后观察实际容量、错误率、延迟和资源成本，验证架构假设是否成立。
重大系统建议在上线后 2 至 4 周进行一次架构回顾，把实际数据、事故和用户反馈写回架构决策记录。
八、推荐保留的评审产物
架构设计文档与各类架构图；
非功能需求清单；
架构决策记录（ADR）；
评审问题与整改跟踪表；
容量、性能、安全和容灾验证报告；
最终评审结论；
上线后的验证与复盘记录。
总结
成熟的架构评审不是一次会议，而是一条从申请、材料、评审、整改到验证的质量控制链。流程既要能够阻止高风险方案上线，也要避免为了形式增加无效审批。最好的评审结果，是让团队理解关键取舍、提前消除风险，并留下可以追踪和复用的工程依据。