架构评审不是让几位专家对着架构图“挑问题”，而是在投入大量建设成本之前，系统性识别需求遗漏、单点风险、容量不足、安全缺陷和不可运维设计。好的评审结论应当能够转化为明确行动。
一、评审前需要哪些材料
业务背景、范围与关键用户流程；
功能需求和非功能需求；
系统上下文图、组件图、部署图与数据流图；
容量估算和流量模型；
数据模型及一致性要求；
高可用、容灾、安全和监控方案；
技术选型与 ADR；
实施计划、风险清单和成本估算。
材料不需要追求形式复杂，但必须让评审人员理解系统边界和关键假设。
二、业务与需求检查
核心业务目标是否明确；
系统范围与外部依赖是否清楚；
关键流程、异常流程和补偿流程是否覆盖；
SLA、合规和数据保留要求是否明确；
哪些指标用于判断项目成功；
当前设计是否存在明显过度建设。
如果需求无法量化，评审很容易退化成技术偏好争论。
三、系统边界与组件检查
组件职责是否单一且边界清晰；
数据所有权是否明确；
是否存在跨服务直接访问数据库；
同步调用链是否过长；
外部系统失败是否会拖垮核心流程；
引入的中间件是否真正解决了问题；
团队是否具备维护这些组件的能力。
四、可靠性检查
是否存在进程、主机、可用区或网络单点；
健康检查能否反映真实业务状态；
超时、重试、熔断、隔离和限流是否合理；
重试是否可能形成请求风暴；
状态组件如何切换和恢复；
是否定义 RPO、RTO 和恢复责任；
备份是否经过恢复验证；
是否有降级和人工接管方案。
可靠性设计应优先降低故障爆炸半径，而不是假设故障不会发生。
五、性能与容量检查
峰值流量和数据增长依据是什么；
关键接口的 P95、P99 和错误率目标；
应用、缓存、数据库、消息队列和网络瓶颈在哪里；
是否考虑连接池、队列堆积和第三方配额；
扩容需要多长时间；
压测是否接近真实数据量和调用链；
是否定义容量告警和扩容阈值。
六、数据与一致性检查
核心数据的唯一事实来源在哪里；
哪些流程要求强一致，哪些允许最终一致；
重复、乱序、延迟消息如何处理；
接口和消费端是否幂等；
跨服务失败如何补偿；
数据迁移、回滚、归档和删除如何执行；
敏感数据是否正确分类和保护。
七、安全检查
用户和服务身份如何认证；
权限是否遵循最小权限；
网络入口、出口和管理面是否受控；
传输与静态数据是否加密；
Secret、证书和密钥如何轮换；
镜像、依赖和构建制品是否可信；
日志是否可能泄露敏感信息；
是否具备审计、漏洞修复和事件响应流程。
八、可运维性检查
部署、配置和基础设施是否代码化；
是否支持灰度、回滚和兼容性发布；
指标、日志、链路追踪是否覆盖关键路径；
告警是否对应用户影响；
是否有服务目录、负责人和 Runbook；
日常操作是否可以自动化和审计；
升级、扩容和证书续期是否有计划。
九、成本检查
建设成本和月度运行成本是多少；
哪些资源为了高可用而冗余；
网络流量、日志、备份和许可证是否计入；
是否存在闲置容量或工具重复建设；
成本增长是否与业务增长成比例；
是否有预算告警和资源回收机制。
十、评审结论怎么写
评审结果建议分为：
必须整改：上线前必须解决；
风险接受：明确责任人和接受原因；
后续优化：不阻塞上线，但设定触发条件；
待验证假设：通过原型、压测、演练或安全测试验证。
每个问题都应包含风险描述、影响范围、整改建议、负责人和完成时间。避免只写“建议优化”而没有后续动作。
总结
架构评审的价值不是证明设计完美，而是让风险被提前看见、被正确取舍并被持续跟踪。围绕业务、可靠性、性能、数据、安全、可运维性和成本建立固定清单，可以让评审从个人经验变成组织能力。