mcpField
S
system-architecture

system-architecture

github.com/yennanliu开发14084 次安装今天更新
代码仓库

关于 system-architecture

System Architecture Expert 是用于设计和评审分布式系统、编写架构文档及准备系统设计面试的技能。它提供从需求与容量估算到数据设计、可靠性和权衡分析的结构化流程。

主要功能

  1. 01引导收集系统需求
  2. 02涵盖容量与存储估算
  3. 03组织高层架构设计
  4. 04讲解数据库、缓存与队列
  5. 05梳理可扩展性和可靠性模式
  6. 06提供模板与案例分析

适用场景

  1. 01规划分布式系统设计
  2. 02编写架构文档
  3. 03分析设计方案的权衡
  4. 04准备系统设计面试

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/yennanliu/cs_basics --skill system-architecture

安装后在 Claude Code 中输入/system-architecture确认已加载。

详细介绍

系统架构专家

何时使用此 Skill

在以下情况下使用此 Skill：

  • 设计分布式系统
  • 编写系统设计文档
  • 准备系统设计面试
  • 创建架构图
  • 分析不同设计方案之间的权衡
  • 审查或改进现有系统设计

系统设计框架

1. 收集需求（5-10 分钟）

功能需求：

  • 核心功能有哪些？
  • 用户可以执行哪些操作？
  • 输入和输出是什么？

非功能需求：

  • 规模：有多少用户？数据量有多大？
  • 性能：延迟要求是什么？（p50、p95、p99）
  • 可用性：需要达到什么运行时间？（99.9%、99.99%）
  • 一致性：强一致性还是最终一致性？

约束：

  • 预算限制
  • 技术栈限制
  • 团队专业能力
  • 时间安排

示例问题：

- How many daily active users?
- What's the read:write ratio?
- What's the average data size?
- What's the peak load vs average load?
- Do we need real-time updates?
- Can we have data loss?
2. 容量估算（粗略估算）

计算：

Traffic:
- DAU = 100M users
- Each user makes 10 requests/day
- QPS = 100M * 10 / 86400 ≈ 11,574 QPS
- Peak QPS = 2-3x average ≈ 30,000 QPS

Storage:
- 100M users * 1KB per user = 100GB
- With 3x replication = 300GB
- Growth: 300GB * 365 days = 109.5TB/year

Bandwidth:
- QPS * average request size
- 11,574 * 10KB = 115.74MB/s

内存/缓存：

  • 80-20 法则：20% 的数据承载 80% 的流量
  • 缓存 = 热数据总量的 20%
3. 高层设计

核心组件：

  1. 客户端层（Web、移动端、桌面端）
  2. API 网关 / 负载均衡器
  3. 应用服务器（业务逻辑）
  4. 缓存层（Redis、Memcached）
  5. 数据库（SQL、NoSQL，或两者兼用）
  6. 消息队列（Kafka、RabbitMQ）
  7. 对象存储（S3、GCS）
  8. CDN（CloudFront、Akamai）

绘制架构图：

[Clients] → [CDN]
            ↓
        [Load Balancer]
            ↓
    [Application Servers]
        ↙     ↓     ↘
   [Cache] [DB] [Queue] → [Workers]
                            ↓
                      [Object Storage]
4. 数据库设计

SQL 与 NoSQL 的选择：

适用于 SQL 的情况：

  • 需要 ACID 事务
  • 需要使用 JOIN 的复杂查询
  • 结构化且存在关联关系的数据
  • 示例：PostgreSQL、MySQL

适用于 NoSQL 的情况：

  • 超大规模（水平扩展）
  • 灵活的架构
  • 高写入吞吐量
  • 示例：Cassandra、DynamoDB、MongoDB

分片策略：

  • 基于哈希：user_id % num_shards
  • 基于范围：用户 1-100M 存储在分片 1
  • 基于地理位置：美国用户存储在美国分片
  • 一致性哈希：实现均匀分布

架构设计：

-- Example: URL Shortener
CREATE TABLE urls (
    id BIGSERIAL PRIMARY KEY,
    short_url VARCHAR(10) UNIQUE NOT NULL,
    long_url TEXT NOT NULL,
    user_id BIGINT,
    created_at TIMESTAMP DEFAULT NOW(),
    expires_at TIMESTAMP,
    click_count INT DEFAULT 0,
    INDEX (short_url),
    INDEX (user_id)
);
5. 深入分析组件

缓存策略：

  • 旁路缓存：应用从缓存读取，未命中时从数据库加载
  • 直写缓存：同时写入缓存和数据库
  • 回写缓存：先写入缓存，再异步写入数据库

淘汰策略：

  • LRU（最近最少使用）——最常见
  • LFU（最不经常使用）
  • TTL（生存时间）

负载均衡：

  • 轮询：简单、均匀分配
  • 最少连接：路由到最空闲的服务器
  • 一致性哈希：尽量减少重新分配
  • 加权：根据服务器容量分配

消息队列模式：

  • 发布/订阅：一对多（通知）
  • 工作队列：任务分发（作业处理）
  • 扇出：广播到多个队列
6. 可扩展性模式

水平扩展：

  • 增加更多服务器
  • 使用负载均衡器
  • 应用服务器保持无状态
  • 会话存储在缓存/数据库中

垂直扩展：

  • 为服务器增加更多 CPU/RAM
  • 受硬件限制
  • 更简单，但存在上限

微服务：

Monolith:
[Single App] → [DB]

Microservices:
[User Service] → [User DB]
[Post Service] → [Post DB]
[Feed Service] → [Feed DB]

优点：

  • 可独立扩展
  • 技术选择灵活
  • 故障隔离

缺点：

  • 复杂度增加
  • 网络延迟
  • 分布式事务
7. 可靠性与可用性

复制：

  • 主从：一个写入节点，多个读取节点
  • 双主：多个写入节点（需要解决冲突）
  • 多区域：地理位置冗余

故障切换：

  • 主动-被动：备用服务器接管
  • 主动-主动：两台服务器都处理流量

限流：

  • 令牌桶算法
  • 漏桶算法
  • 固定窗口计数器
  • 滑动窗口日志

熔断器：

States:
Closed → Normal operation
Open → Reject requests immediately
Half-Open → Test if service recovered
8. 常见系统设计模式

内容分发：

  • 使用 CDN 分发静态资源
  • 地理分布式边缘服务器
  • 在边缘节点缓存

数据一致性：

  • 强一致性：读取结果反映最新写入（ACID）
  • 最终一致性：读取结果最终会反映写入（BASE）
  • CAP 定理：三者取其二：一致性、可用性、分区容错性

API 设计：

RESTful:
GET    /api/users/{id}
POST   /api/users
PUT    /api/users/{id}
DELETE /api/users/{id}

GraphQL:
query {
  user(id: "123") {
    name
    posts {
      title
    }
  }
}
9. 系统设计模板

使用此结构（基于 system_design/00_template.md）：

# {System Name}

## 1. Requirements
### Functional
- [List core features]

### Non-Functional
- Scale: [Users, QPS, Data]
- Performance: [Latency requirements]
- Availability: [Uptime target]

## 2. Capacity Estimation
- Traffic: [QPS calculations]
- Storage: [Data size, growth]
- Bandwidth: [Network requirements]

## 3. API Design

[endpoint] - [description]


## 4. High-Level Architecture
[Diagram]

## 5. Database Schema
[Tables and relationships]

## 6. Detailed Design
### Component 1
[Deep dive]

### Component 2
[Deep dive]

## 7. Scalability
[How to scale each component]

## 8. Trade-offs
[Decisions and alternatives]
10. 真实案例

参考 system_design/ 中的案例研究：

  • Netflix：视频流媒体、推荐
  • Twitter：时间线、推文存储、热门趋势
  • Uber：实时匹配、位置跟踪
  • Instagram：图像存储、动态生成
  • WhatsApp：消息传递、在线状态

常见模式：

  • 新闻 Feed：写扩散与读扩散
  • 速率限制器：使用 Redis 的令牌桶
  • URL 缩短器：Base62 编码、哈希冲突
  • 聊天系统：WebSocket、消息队列
  • 通知：推送通知服务、APNs/FCM

面试技巧

时间管理：

  • 需求：10%
  • 高层设计：25%
  • 深入探讨：50%
  • 总结：15%

沟通：

  • 边思考边表达
  • 提出澄清问题
  • 讨论权衡
  • 承认局限性

面试官关注的方面：

  • 解决问题的方法
  • 技术深度
  • 权衡分析
  • 对规模的认知
  • 沟通能力

需要避免的常见错误

  • 未明确需求就直接提出解决方案
  • 对简单问题过度设计
  • 低估规模需求
  • 忽略单点故障
  • 未考虑监控/告警
  • 忘记数据一致性
  • 忽略安全注意事项

项目背景

  • 模板位于 system_design/00_template.md
  • 案例研究位于 system_design/*.md
  • 遵循既定的文档模式

评论

支持 Markdown