architecture-design-review

架构设计评审

开展系统性的架构设计评审，以验证系统设计、评估质量属性、评估技术选择，并在实施前识别风险。

评审流程

按照以下结构化方法进行全面的架构评审：

1. 收集架构文档

收集所需材料：

必需文档：

• 架构图（C4：上下文、容器、组件）
• 架构决策记录（ADR），包含理由和备选方案
• 技术规范和非功能性需求（性能、可扩展性、安全性）
• 数据模型、架构和 API 规范
• 技术栈及其选择依据
• 部署和基础设施图

背景信息：

• 业务约束（预算、时间线、合规要求）
• 性能目标（量化指标：响应时间、吞吐量）
• 可扩展性目标（用户增长、数据量预测）
• 安全要求（身份验证模型、数据保护、合规性）
• 集成要求（内部／外部系统、API）

2. 评估架构风格和模式

验证架构风格是否合适：

风格与需求匹配度：

• 单体架构：小团队（<10 人）、简单领域、<1000 名用户
• 微服务：大团队（>20 人）、复杂领域、>100K 名用户
• 无服务器：事件驱动、负载变化、无状态操作
• 事件驱动：异步工作流、松耦合、高吞吐量

模式评估：

☐ Architecture style matches requirements (scale, team, complexity)
☐ Service boundaries align with business domains (DDD)
☐ Communication patterns appropriate (sync vs async)
☐ Data management strategy clear (per-service vs shared DB)
☐ Integration patterns documented (gateway, mesh, events)
☐ Deployment model specified (containers, VMs, serverless)

反模式检测：

• 泥球式架构：没有结构、紧密耦合、共享数据库
• 上帝服务：单个服务处理多个领域
• 频繁通信：服务间调用过多（每个请求 >5 次）
• 分布式单体：服务通过共享数据库耦合
• 金锤反模式：所有问题都使用同一种技术

3. 评估质量属性

可扩展性评估：

• 水平扩展：负载均衡器、无状态服务、自动扩缩容
• 数据库扩展：分片、只读副本、缓存层
• 容量规划：当前负载 → 预测负载（记录增长策略）
• 成本影响：基础设施的基准和峰值成本

性能验证：

• 为各层分配响应时间预算
• 缓存策略（CDN、Redis、应用缓存）
• 数据库优化（索引、连接池、查询分析）
• 长时间运行任务的异步处理（队列、后台作业）

安全评审：

☐ Authentication mechanism (OAuth 2.0, JWT, SAML)
☐ Authorization model (RBAC, ABAC, policy-based)
☐ API security (rate limiting, input validation, CORS)
☐ Data encryption (at-rest: AES-256, in-transit: TLS 1.3)
☐ Secret management (AWS Secrets Manager, HashiCorp Vault)
☐ Network security (VPC, security groups, WAF)
☐ Security headers (HSTS, CSP, X-Frame-Options)

可用性与可靠性：

• 部署到多个可用区／区域，以实现高可用性
• 断路器可防止故障级联
• 配置健康检查和自动恢复
• 备份／灾难恢复流程（RPO < 1 小时，RTO < 4 小时）
• 为非关键功能提供优雅降级

4. 评审技术栈

技术适用性验证：

• 后端框架适合使用场景（Spring Boot、Node.js、Django、Go）
• 数据库选择有充分依据（PostgreSQL、MongoDB、Cassandra、Redis）
• 部署平台合适（Kubernetes、ECS、Cloud Run）
• 评估是否考虑了备选方案，并将其记录在 ADR 中

技术风险评估：

• 供应商锁定：评估可移植性和迁移复杂度
• 团队技能：记录培训需求和时间安排
• 社区支持：检查生态系统成熟度和长期可行性
• 性能：验证技术能否满足需求
• 许可：确认符合商业用途的许可要求

5. 分析数据架构

数据策略验证：

• 每个服务独立使用数据库，还是共享数据库（说明选择依据）
• 选择 SQL 还是 NoSQL，并说明理由
• 数据分区和分片策略
• 数据一致性模型（强一致性还是最终一致性）
• 明确分配数据所有权
• 尽量减少跨服务查询

6. 评审监控和可观测性

可观测性检查清单：

☐ Metrics: Application, infrastructure, business metrics
☐ Logging: Centralized aggregation with correlation IDs
☐ Tracing: Distributed tracing across services
☐ Alerting: Error rate, latency, availability thresholds
☐ Dashboards: Real-time visibility into system health
☐ On-call: Rotation and escalation procedures

7. 生成评审报告

报告结构：

1. 执行摘要：架构风格、总体评估（已批准／有条件批准／未批准）、主要优势和问题

2. 发现：按严重程度（严重／高／中／低）组织，包含：

   • 描述和影响
   • 建议及工作量估算
   • 优先级（必须修复／应该修复／可考虑）

3. 风险评估：技术、资源、时间安排和运营风险及其缓解措施

发现格式：

Finding: [Clear description]
Severity: Critical | High | Medium | Low
Impact: [Specific consequences]
Recommendation: [Actionable solution]
Effort: [Time estimate]
Priority: Must Fix | Should Fix | Consider

参考文档

加载特定评审领域的详细指导：

核心评审资源：

• architecture-review-process.md - 完整的评审方法，包含逐阶段检查清单
• review-checklists.md - 涵盖所有架构方面的综合验证清单
• quality-attributes.md - 对可扩展性、性能、安全性、可靠性和可维护性的详细评估
• common-patterns-to-validate.md - 架构模式（微服务、事件驱动、无服务器）的验证标准
• anti-patterns.md - 常见设计缺陷及其检测标准和修复方法
• review-report-template.md - 报告结构、示例和严重程度分类
• review-severity-levels.md - 严重程度分类标准（严重／高／中／低）
• best-practices-for-architecture-reviews.md - 评审方法最佳实践

API 和集成：

• api-design.md - REST、GraphQL、gRPC 设计评估

数据架构：

• data-management.md - 数据策略、所有权、同步和一致性模式
• data-storage-strategy.md - 数据库选择、分区和复制
• data-consistency.md - 一致性模型及权衡
• data-scalability.md - 分片、复制和缓存策略
• database-selection.md - SQL 与 NoSQL、技术选型标准

安全性：

• application-security.md - 安全架构，包括身份验证、授权、加密和合规性
• authentication-and-authorization.md - 身份和访问管理模式

可扩展性和性能：

• horizontal-scalability.md - 水平扩展策略和自动扩缩容
• caching-strategy.md - 缓存层、失效处理和 CDN

可靠性和运维：

• high-availability-design.md - 高可用架构、冗余和故障转移
• fault-tolerance.md - 熔断器、重试、舱壁隔离和超时
• disaster-recovery.md - 备份、恢复流程以及 RPO/RTO 规划
• monitoring-and-observability.md - 指标、日志、追踪和告警

微服务：

• service-boundaries-microservices.md - 服务拆分、限界上下文和领域边界

其他主题：

• external-integrations.md - 第三方 API 集成模式
• testing-strategy.md - 测试覆盖率、集成测试、契约测试
• operational-readiness.md - 生产就绪检查清单
• cost-analysis.md - 基础设施成本估算与优化
• infrastructure-costs.md - 按组件划分的详细成本明细
• infrastructure.md - 基础设施设计与部署模式
• risk-assessment.md - 技术风险识别与缓解

注意：有关技术选型指导（框架、数据库、云平台），请参阅 architecture-design 技能。

关键评审原则

关注架构，而非实现：

• 评审设计与模式，而非代码质量
• 验证决策与权衡，而非语法
• 评估结构与边界，而非变量名称

针对发现的问题提供具体说明： ✅ “Order→Payment 调用缺少断路器（平均每秒 50 次调用）。添加 Resilience4j，并将错误阈值设为 50%。” ❌ “需要改进错误处理”

量化性能要求： ✅ “在每秒 1000 个请求时，API 响应时间的第 95 百分位必须低于 200 ms” ❌ “API 应该更快”

提供可执行的建议： ✅ “将 UserService 拆分为 Authentication（身份）和 Profile（数据）服务。预计需要 3 周。使用事件总线进行同步。” ❌ “考虑改进服务边界”

根据上下文进行评估：

• 创业公司的 MVP 与企业系统有不同的要求
• 100 用户规模的系统不需要微服务带来的复杂性
• 根据规模、团队和时间安排评估方案是否合适