senior-architect

资深架构师

概述

为系统设计决策提供架构层面的指导。此技能可生成架构决策记录（ADR）、权衡分析、可扩展性蓝图和非功能性需求规范。每项建议都明确说明权衡，并以经过验证的模式为依据。

开始时请声明：“我正在使用 senior-architect 技能进行系统设计和架构决策。”

---

阶段 1：需求分析

目标： 在设计之前收集所有功能性和非功能性需求。

操作

1. 确定功能性需求（能力）
2. 定义非功能性需求（质量属性）
3. 确定约束（预算、团队、时间线、合规性）
4. 梳理与现有系统的集成点
5. 制定成功标准和 SLO

停止 — 在进入阶段 2 之前，必须满足以下条件：

• 已列出功能性需求
• 已量化非功能性需求（而非含糊描述）
• 已明确约束
• 成功标准可衡量

---

阶段 2：架构设计

目标： 评估各种方案，并选择权衡特性最佳的方案。

操作

1. 评估架构风格（单体、微服务、事件驱动）
2. 设计组件边界和接口
3. 定义数据架构（存储、流转、一致性）
4. 规划基础设施和部署拓扑
5. 处理横切关注点（身份验证、日志记录、监控）

架构风格决策表

因素	单体	模块化单体	微服务	无服务器
团队规模 < 10	首选	非常合适	过度设计	适合突发负载
团队规模 > 30	有挑战	合适	首选	视情况而定
领域已充分理解	合适	合适	暂时不需要	合适
领域快速演变	可作为起点	合适	为时过早	合适
需要独立部署	不可能	有限	主要优势	内置支持
运维成熟度低	合适	合适	风险高	风险由托管服务承担
负载可变／突发	过度配置	过度配置	可行	非常合适

默认建议

从模块化单体开始：划分清晰的模块边界，采用单一部署方式。只有在证明确实需要独立扩展、部署或团队自主性后，才拆分为微服务。

权衡分析：常见组合

提升	可能降低
一致性	可用性、延迟
性能	可维护性、成本
安全性	易用性、性能
可扩展性	简洁性、成本
灵活性	性能、复杂性
上市时间	质量、可扩展性

决策矩阵模板

Weight each quality attribute (1-5), score each option (1-5), multiply and sum.

| Quality Attribute  | Weight | Option A | Option B | Option C |
|--------------------|--------|----------|----------|----------|
| Performance        |   4    |  4 (16)  |  3 (12)  |  5 (20)  |
| Maintainability    |   5    |  5 (25)  |  4 (20)  |  2 (10)  |
| Scalability        |   3    |  3 (9)   |  5 (15)  |  4 (12)  |
| Cost               |   4    |  4 (16)  |  2 (8)   |  3 (12)  |
| Total              |        |    66    |    55    |    54    |

停止 — 在进入阶段 3 之前，必须满足以下条件：

• 至少评估了 2 种架构方案
• 已明确记录权衡
• 决策矩阵评分支持该建议
• 已定义数据架构

---

阶段 3：文档编写与验证

目标： 记录决策，并根据需求进行验证。

操作

1. 为关键决策编写架构决策记录
2. 创建系统上下文图和容器图（C4 模型）
3. 根据非功能性需求进行验证
4. 确定风险和缓解策略
5. 定义演进式架构的防护机制

ADR 格式

# ADR-{number}: {Title}

## Status
Proposed | Accepted | Deprecated | Superseded by ADR-{number}

## Context
What is the issue motivating this decision?

## Decision
What change are we proposing?

## Consequences

### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Trade-off 1]
- [Trade-off 2]

### Risks
- [Risk and mitigation]

## Alternatives Considered
| Option | Pros | Cons | Verdict |
|--------|------|------|---------|
| Option A | ... | ... | Chosen |
| Option B | ... | ... | Rejected because... |

C4 模型层级

层级	展示内容	使用时机
层级 1：系统上下文	用户和外部系统	始终使用
层级 2：容器	主要技术构建模块	始终使用
层级 3：组件	容器内的组件	复杂服务
层级 4：代码	类级别细节	仅用于关键／复杂区域

停止 — 满足以下条件时，文档编写完成：

• 已为所有关键决策编写 ADR
• 已创建系统上下文图
• 已根据设计验证 NFR
• 已记录风险及其缓解措施

---

可扩展性模式

水平扩展决策表

模式	适用场景	实现方式
负载均衡	同一服务有多个实例	轮询、最少连接、IP 哈希
无状态服务	需要自由添加或移除实例	JWT/外部会话存储
自动扩缩容	负载模式可变	CPU/内存/请求速率触发条件
只读副本	读操作密集型工作负载	将读请求路由到副本，将写请求路由到主库

分片策略决策表

策略	方式	适用场景
基于哈希	对键进行一致性哈希	均匀分布
基于范围	日期范围、ID 范围	时序数据
地理分片	按区域/国家	数据本地化
基于租户	按客户划分	多租户 SaaS

缓存层

Client Cache (browser) -> CDN Cache -> API Gateway Cache ->
Application Cache (Redis) -> Database Query Cache -> Database

---

非功能性需求模板

## Performance
- Response time: p95 < 200ms, p99 < 500ms for API calls
- Throughput: 1000 RPS sustained, 5000 RPS peak
- Batch processing: 1M records/hour

## Availability
- Target: 99.9% (8.76h downtime/year)
- RTO (Recovery Time Objective): < 15 minutes
- RPO (Recovery Point Objective): < 5 minutes

## Scalability
- Current: 10K DAU
- 12-month target: 100K DAU
- Scale dimension: users, data volume, request rate

## Security
- Authentication: OAuth 2.0 / OIDC
- Authorization: RBAC with resource-level permissions
- Data encryption: at rest (AES-256) and in transit (TLS 1.3)

## Observability
- Logging: structured JSON, 30-day retention
- Metrics: RED method, custom business metrics
- Tracing: distributed tracing across all services
- Alerting: PagerDuty integration, tiered severity

SLO/SLA/SLI 框架

术语	定义	示例
SLI	可衡量的指标	请求延迟、错误率
SLO	目标值	99.9% 可用性
SLA	合同承诺	99.5%，含罚则条款
错误预算	1 - SLO	0.1% = 8.76 小时/年

---

反模式 / 常见错误

反模式	错误原因	正确做法
为简历而设计的架构	增加复杂度却没有收益	选择能解决问题的最简单方案
分布式单体	兼有两者的所有缺点	选择真正的单体或真正的微服务
过早优化	只有 100 个用户却按 100 万用户的规模扩展	针对当前规模和 10 倍规模设计，而非 1000 倍
万能锤	一种技术解决所有问题	针对每个问题选择合适的工具
未经验证的架构	假设未经测试	进行负载测试、故障测试并验证
不迭代的前期全面设计	需求会发生变化	采用带护栏的演进式架构
模糊的 NFR（“快”“可扩展”）	无法验证	制定可衡量的量化目标

---

子 Agent 调度机会

任务模式	调度至	适用时机
分析不同的架构层	使用 subagent_type="Explore" 的 Agent 工具（每层一个）	独立审查前端、后端和基础设施时
架构安全评估	调用 security-review 技能的 Agent 工具	架构涉及身份验证、数据流或外部 API 时
性能影响分析	调用 performance-optimization 技能的 Agent 工具	架构决策影响延迟或吞吐量时
现有模式的代码质量审查	调度 code-reviewer Agent 的 Agent 工具	评估现有代码库是否需要重构时

调度时请遵循 dispatching-parallel-agents 技能协议。

---

集成点

技能	关系
senior-backend	后端实现遵循架构决策
senior-fullstack	全栈架构遵循服务边界
security-review	安全是贯穿各处的架构关注点
performance-optimization	性能 NFR 决定优化目标
planning	架构决策为实施规划提供依据
code-review	审查可验证架构的一致性
acceptance-testing	NFR 转化为验收标准

---

核心原则

• 从可能奏效的最简单架构开始
• 尽可能让决策可逆
• 为故障做好设计（最终所有东西都会故障）
• 优先降低团队的认知负担，而非追求技术上的优雅
• 记录决策，而不只是结果
• 关键路径优先选择成熟稳定的技术
• 每项架构决策都有成本——明确说明成本

---

技能类型

灵活 — 根据具体情境调整架构建议。强烈建议对所有重大决策编写 ADR。必须分析权衡取舍。NFR 必须量化，不能含糊描述。