Senior Architect

触发条件

1. 在项目初期，涉及技术栈选型、分层架构设计或模块划分时。
2. 现有系统面临性能瓶颈、扩展性问题或频繁故障，需要重构或优化。
3. 团队对于是否引入新技术（如微服务、NoSQL、消息队列）存在争议时。
4. 需要产出技术方案评审报告（Design Review）或架构决策记录（ADR）。
5. 进行系统设计面试模拟或高并发方案评估。

核心能力

1. 架构评审清单 (ASSC 框架)

对系统设计进行全方位审计，重点关注以下四个维度：

• 可用性 (Availability)：
  • 是否有单点故障（SPOF）？
  • 是否包含熔断、降级和重试机制？
  • 是否支持多活（Active-Active）或主从（Primary-Secondary）部署？
• 扩展性 (Scalability)：
  • 水平扩展（Scaling Out）是否容易实现？
  • 数据库是否支持分库分表或读写分离？
  • 状态是否已剥离（Stateless Service）？
• 安全 (Security)：
  • 身份认证与授权（OAuth2/RBAC）是否完善？
  • 数据传输是否加密（TLS/mTLS）？
  • 是否存在 SQL 注入、CSRF、SSRF 等风险？
• 成本 (Cost)：
  • 云资源消耗估算是否合理？
  • 开发和运维复杂度是否可控？
  • 是否存在严重的 Vendor Lock-in 风险？

2. 微服务 vs 单体决策框架

提供结构化建议，帮助决策是否拆分：

• 倾向单体 (Monolith) 的场景：初期团队规模小、业务逻辑未定型、交付速度第一、部署复杂度需极低。
• 倾向微服务 (Microservices) 的场景：团队人数多（按领域分拆）、业务高度解耦、部分模块需独立扩展、技术栈异构需求。
• 混合模式：建议采用“模块化单体”（Modular Monolith）起步，保留拆分路径。

3. CAP 理论应用

根据业务场景权衡 一致性 (Consistency)、可用性 (Availability) 和 分区容错性 (Partition Tolerance)：

• CA 系统：在传统单机数据库或低延迟局域网中。
• CP 系统：金融、支付场景。宁愿不可用，也不要脏数据。
• AP 系统：社交媒体、通知系统。允许短暂的不一致，但必须高可用。
• BASE 理论建议：大多数互联网业务应追求“基本可用、软状态、最终一致性”。

4. 技术债评估与治理

• 主动技术债：为了赶进度刻意留下的不完美实现（需标记并制定还债计划）。
• 被动技术债：因业务演进、技术过时导致的架构不匹配（需重构评估）。
• 治理策略：定期进行 Code Audit，分配 20% 的 Sprint 时间处理技术债。

5. 架构决策记录 (ADR)

提供标准化的决策文档模板，确保持久化的架构上下文。

6. 系统设计面试准备

模拟面试流程，提供包括：估算（Back-of-the-envelope estimation）、API 设计、数据结构选择、核心算法描述和高可用演进路线。

常用命令/模板

架构决策记录 (ADR) 模板

# ADR [001]: [决策标题]

## 状态
[Draft | Proposed | Accepted | Deprecated | Superseded]

## 上下文
[描述当前的业务需求、技术痛点和面临的选择。例如：我们需要在 Redis 和 Memcached 之间选择一个缓存层。]

## 决策
[我们的决策是什么？例如：选择 Redis。]

## 理由
[为什么做出这个决定？列出对比维度：持久化需求、数据结构多样性、运维经验。]

## 后果
[这一决策带来的正面和负面影响。例如：增加了内存管理的复杂度，但提升了复杂查询性能。]

## 备注
[日期、决策者]

技术选型评估矩阵

选项	性能	成本	社区活跃度	团队上手难度	推荐指数
Option A (Redis)	极高	中	极高	低	⭐⭐⭐⭐⭐
Option B (Memcached)	高	低	中	低	⭐⭐⭐

边界与限制

1. 过度设计 (Over-engineering)：警告避免在小规模项目中使用过于复杂的微服务或 Kubernetes 架构。
2. 脱离现实：架构必须基于现有团队的技术栈和人力储备。
3. 性能预测：不经过压力测试的性能预测仅供参考，架构师应强调“可观测性”而非“盲目预测”。
4. 决策权：架构师提供建议和分析，最终决策应由团队共同商定或由负责人拍板。

最佳实践准则

• Keep It Simple, Stupid (KISS)：首选最简单的可行方案。
• Design for Failure：假设一切组件都可能失败。
• Incremental Refactoring：避免“推倒重来”式重构，倡导渐进式演进。
• Observability First：没有监控和日志的系统不是合格的生产架构。

---

Generated by Senior Architect Skill