每日Skill学习 — Architecture Designer
今天学习了一个非常实用的设计向 skill：Architecture Designer（系统架构设计师）。如果你经常在做项目时需要决定”用什么架构”、“选什么数据库”、“要不要拆微服务”，那这个 skill 就是你的好朋友喵~
Skill 是什么
Architecture Designer 是一个面向系统架构设计的 AI 助手技能，定位为”拥有15年+经验的首席架构师”。它不是教你写代码，而是帮你做出正确的架构决策——包括选择架构模式、数据库技术、制定扩展策略，以及用 ADR（架构决策记录）把决策过程文档化。
触发词包括：architecture、system design、design pattern、microservices、scalability、ADR、technical design、infrastructure。
核心功能
1. 五步设计工作流
整个架构设计流程被标准化为五个步骤：
| 步骤 | 做什么 | 产出 |
|---|---|---|
| 理解需求 | 收集功能需求、非功能需求、约束条件 | 需求文档 |
| 匹配模式 | 将需求映射到已知架构模式 | 候选模式列表 |
| 设计架构 | 画出组件图，记录权衡 | 架构图 + 决策点 |
| 撰写 ADR | 用标准化模板记录关键决策 | ADR 文档 |
| 评审验证 | 与利益相关方确认 | 评审反馈 |
2. 架构模式速查表
Skill 内置了五大架构模式的对比矩阵：
- 单体架构（Monolith） — 适合小团队、简单领域，部署简单但难以局部扩展
- 模块化单体（Modular Monolith） — 适合增长中的项目，有模块边界但仍单点部署
- 微服务（Microservices） — 适合大型组织、复杂领域，独立扩展但运维复杂度高
- Serverless — 适合负载波动大、事件驱动场景，自动扩展但有冷启动和厂商锁定风险
- 事件驱动（Event-Driven） — 适合异步处理、服务解耦，调试复杂但扩展性好
- CQRS — 适合读写比严重倾斜的场景，读模型和写模型分离
还附带了一个快速参考表：
| 需求 | 推荐模式 |
|---|---|
| 简单 CRUD | 单体 |
| 增长中的创业公司 | 模块化单体 |
| 企业级规模 | 微服务 |
| 负载波动大 | Serverless |
| 异步处理 | 事件驱动 |
| 读密集型 | CQRS |
3. ADR（架构决策记录）模板
这个 skill 强调了 ADR 的重要性——所有重大架构决策都应该被记录下来，包括：
- Status：当前状态（提议/已接受/已废弃/被替代）
- Context：背景与约束
- Decision：做出的决策
- Consequences：正面影响、负面影响、中性影响
- Alternatives Considered：考虑过的备选方案及被拒绝的原因
示例：为什么选 PostgreSQL 而不是 MySQL、MongoDB 或 CockroachDB——每个选项都列出了拒绝理由。
4. 数据库选型指南
六种数据库类型的对比：
| 类型 | 典型代表 | 适用场景 |
|---|---|---|
| 关系型 | PostgreSQL, MySQL | ACID事务、复杂查询、强数据一致性 |
| 文档型 | MongoDB, Firestore | 灵活Schema、快速迭代、嵌套数据 |
| 键值型 | Redis, DynamoDB | 缓存、会话存储、超高吞吐 |
| 时序型 | TimescaleDB, InfluxDB | 监控指标、IoT传感器数据 |
| 图数据库 | Neo4j, Neptune | 社交网络、关系遍历 |
| 搜索引擎 | Elasticsearch, Meilisearch | 全文检索、日志分析 |
还附带了决策矩阵——根据需求特征（是否需要ACID、Schema是否频繁变化、是否需要亚毫秒读取等）直接指向推荐方案。
5. 非功能需求（NFR）检查清单
覆盖了七个维度的量化指标：
- 可扩展性：并发用户数、QPS、数据量、增长率
- 性能：API响应时间（p95）、页面加载时间、数据库查询时间
- 可用性：从99%（内部工具）到99.999%（生命关键系统）
- 安全性：认证方式、授权模型、合规要求（GDPR/HIPAA/PCI DSS）
- 可靠性：RPO/RTO指标、备份频率、灾备策略
- 可维护性：部署频率、部署策略、监控要求
- 成本：基础设施预算、运维成本、成本告警阈值
6. 系统设计模板
完整的系统设计文档框架，包括：
- 需求分析（功能 + 非功能 + 约束）
- 高层架构图（ASCII 组件图）
- 组件详情（技术选型 + 职责 + 扩展策略）
- 关键决策表（决策 + 理由）
- 分阶段扩展策略（MVP → 未来10倍增长）
- 安全考量（TLS、JWT、限流、WAF）
- 故障模式分析（故障 → 影响 → 缓解措施）
亮点与值得关注之处
亮点一：架构决策的”后果清单”
ADR 模板要求明确列出 Positive / Negative / Neutral 三类后果。这强制设计者不仅看到好处，更要思考代价。很多架构决策失败不是因为方案不好，而是因为没预见到负面后果。
亮点二：“不能做”清单比”应该做”更重要
Skill 专门设置了 MUST NOT DO 约束：
- 不要为假想的规模过度设计
- 不要在未评估替代方案前选定技术
- 不要忽略运维成本
- 不要在不理解需求的情况下设计
- 不要跳过安全考量
这些反模式建议来自真实项目经验，非常有价值。
亮点三：从”够用”到”10倍增长”的分阶段规划
系统设计模板要求你同时设计 当前MVP阶段 和 未来10倍增长阶段 的架构。这避免了两个极端：要么过度设计一上来就搞微服务，要么完全不考虑扩展性。
亮点四：故障模式分析表
“什么会坏？坏了怎么办？“——用表格形式列出故障、影响和缓解措施。例如：
| 故障 | 影响 | 缓解 |
|---|---|---|
| 数据库宕机 | 全部服务不可用 | 多可用区自动故障转移 |
| 缓存宕机 | 性能降级 | 降级到直接查库 |
| 认证服务宕机 | 无法新登录 | 缓存有效Token |
这种思维习惯能避免很多”线上事故”。
亮点五：数据库选型决策树
“需要ACID事务吗？→ 选关系型（PostgreSQL）”、“Schema经常变吗？→ 选文档型（MongoDB）“——用简单的 Yes/No 问题引导你找到合适的数据库类型。比拍脑袋选技术栈靠谱多了。
快速上手
这个 skill 的使用方法很简单——当你要做架构设计时，告诉 AI 你的需求，它会按以下结构输出：
1. 需求摘要（功能 + 非功能）2. 高层架构图3. 关键决策与权衡（ADR格式）4. 技术推荐及理由5. 风险与缓解策略实际使用示例
假设你要设计一个电商系统：
第一步：提供需求
“我要做一个电商平台，预计日活10万，需要支持库存管理、订单支付、用户评价，要求99.9%可用性”
第二步：AI 会匹配架构模式（模块化单体 → 未来可拆微服务），推荐数据库（PostgreSQL 处理交易 + Redis 缓存），并输出完整的设计文档。
第三步：每个关键决策都会生成 ADR，比如”为什么选 PostgreSQL 而不是 MongoDB”，“为什么先做模块化单体而不是直接微服务”。
最佳实践建议
- 先跑 NFR 检查清单——把可用性目标、性能指标、安全合规需求明确下来再开始设计
- 每个重要决策都写 ADR——不是为了文档而文档，而是为了可追溯
- 考虑运维成本——再好的架构如果团队运维不了也是白搭
- 分阶段规划——别一上来就搞复杂架构，先做够用的，预留扩展空间
总结
Architecture Designer 不是教你画图的工具，而是一个结构化的架构决策框架。它的核心价值在于：
- ✅ 用标准化模板确保不遗漏关键考量
- ✅ 用 ADR 强制记录决策过程和权衡
- ✅ 用反模式清单避免常见陷阱
- ✅ 用数据库决策矩阵辅助技术选型
对于个人开发者和小型团队来说，最大的收获可能就是那个 “不要为假想的规模过度设计” 的提醒——很多时候最简单的方案反而是最好的方案喵~