mcpField
S
scalability-playbook

scalability-playbook

github.com/patricio0312rev开发63344 次安装41 周前更新
代码仓库

关于 scalability-playbook

为工程团队提供识别和解决系统扩展瓶颈的分阶段指南，涵盖测量、优化策略、扩容触发条件和负载测试。

主要功能

  1. 01瓶颈测量与影响评估
  2. 02按投入排序的扩展策略
  3. 03指标阈值与行动触发器
  4. 04分阶段扩容计划
  5. 05负载测试与成本分析

适用场景

  1. 01定位数据库查询延迟
  2. 02规划从单机到横向扩容
  3. 03根据指标设定扩容告警

安装

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

$npx skills add https://github.com/patricio0312rev/skills --skill scalability-playbook

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

详细介绍

可扩展性手册

识别和解决可扩展性瓶颈的系统化方法。

瓶颈分析

当前系统概况
Traffic: 1,000 req/min
Users: 10,000 active
Data: 100GB database
Response time: p95 = 500ms
已识别的瓶颈
1. 数据库查询

症状： 页面加载缓慢（2-3 秒） 测量结果： 查询时间 p95 = 800 毫秒 影响： 高——影响所有读取操作 触发条件： p95 >500 毫秒时

2. 单台服务器

症状： CPU 使用率高（>80%） 测量结果： 平均负载 >4 影响： 中——间歇性变慢 触发条件： CPU >70% 时

3. 没有缓存

症状： 重复的数据库查询 测量结果： 缓存命中率 = 0% 影响： 中——造成不必要的负载 触发条件： 查询量 >10k/分钟时

扩展策略（按顺序）

第 1 级：快速见效（数天）
1.1 添加数据库索引

问题： 查询缓慢 解决方案：

CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);

预期影响： 查询速度提升 80% 成本： $0 工作量： 1 天

1.2 启用查询缓存

问题： 查询重复 解决方案： Redis 缓存层

const cached = await redis.get(`user:${userId}`);
if (cached) return JSON.parse(cached);

const user = await db.users.findById(userId);
await redis.setex(`user:${userId}`, 3600, JSON.stringify(user));

预期影响： 数据库负载降低 60% 成本： $50/月 工作量： 2 天

第 2 级：水平扩展（数周）
2.1 添加只读副本

问题： 读取密集型工作负载 解决方案： 将读取请求路由到副本

Write Load: Primary DB
Read Load: 3x Read Replicas

预期影响： 读取容量提升 3 倍 成本： $300/月 工作量： 1 周

2.2 负载均衡器 + 多台服务器

问题： 单点故障 解决方案：

ALB
 ├── Server 1
 ├── Server 2
 └── Server 3

预期影响： 吞吐量提升 3 倍 成本： $400/月 工作量： 1 周

第 3 级：架构变更（数月）
3.1 静态资源使用 CDN

问题： 资源交付缓慢 解决方案： CloudFront CDN 预期影响： 资源加载速度提升 90% 成本： $100/月 工作量： 1 周

3.2 异步处理

问题： 同步操作缓慢 解决方案： 后台任务队列

// Before: Sync
await sendEmail(user);
await processPayment(order);
await updateAnalytics(event);
return response; // Waits 5+ seconds

// After: Async
await queue.add("send-email", { userId });
await queue.add("process-payment", { orderId });
await queue.add("update-analytics", { event });
return response; // Returns immediately

预期影响： 响应速度提升 80% 成本： $50/月（SQS） 工作量： 2 周

第 4 级：数据层优化（数月）
4.1 数据库分片

问题： 单个数据库过大 解决方案： 按 user_id 分片

Shard 1: user_id 0-24999
Shard 2: user_id 25000-49999
Shard 3: user_id 50000-74999
Shard 4: user_id 75000-99999

预期影响： 容量提升 4 倍 成本： $1,200/月 工作量： 2 个月

4.2 事件驱动架构

问题： 耦合紧密、故障级联 解决方案： 消息代理（Kafka）

Service A → Kafka → Service B
          ↘        ↗ Service C

预期影响： 隔离性和弹性更佳 成本： $500/月 工作量： 3 个月

扩展触发条件

| Metric           | Current | Warning | Critical | Action                  |
| ---------------- | ------- | ------- | -------- | ----------------------- |
| CPU              | 40%     | 70%     | 85%      | Add servers             |
| Memory           | 50%     | 75%     | 90%      | Upgrade instances       |
| DB Connections   | 20      | 40      | 50       | Add read replicas       |
| Query Time (p95) | 200ms   | 500ms   | 1000ms   | Add indexes             |
| Queue Depth      | 100     | 1000    | 5000     | Add workers             |
| Error Rate       | 0.1%    | 1%      | 5%       | Investigate immediately |

分阶段扩展计划

阶段 1：当前规模 → 10 倍（0-3 个月）

目标： 10,000 req/min、100K 用户

行动：

  1. 添加数据库索引（第 1 周）
  2. 实施 Redis 缓存（第 2 周）
  3. 添加 3 倍只读副本（第 4 周）
  4. 对应用服务器进行水平扩展（第 6 周）
  5. 为静态资源使用 CDN（第 8 周）

成本： $500 → $1,000/月

阶段 2：10 倍 → 100 倍（3-12 个月）

目标： 100,000 req/min、1M 用户

行动：

  1. 数据库分片（第 4-6 个月）
  2. 多区域部署（第 6-8 个月）
  3. 拆分微服务（第 8-12 个月）
  4. 事件驱动架构（第 10-12 个月）

成本： $1,000 → $10,000/月

阶段 3：100 倍 → 1000 倍（12-24 个月）

目标： 1M req/min、10M 用户

行动：

  1. 全球 CDN（第 13 个月）
  2. 高级缓存（L1/L2）（第 14-15 个月）
  3. 定制数据库解决方案（第 16-18 个月）
  4. 边缘计算（第 18-20 个月）

成本： $10,000 → $100,000/月

负载测试计划

# Current baseline
hey -n 10000 -c 100 https://api.example.com/users

# Target 10x
hey -n 100000 -c 1000 https://api.example.com/users

# Measure:
# - Requests/sec
# - p50, p95, p99 latency
# - Error rate
# - Resource utilization

成本效益分析

| Strategy      | Cost/Month | Expected Impact    | ROI | Priority |
| ------------- | ---------- | ------------------ | --- | -------- |
| DB Indexes    | $0         | 80% faster queries | ∞   | HIGH     |
| Redis Cache   | $50        | 60% less DB load   | 12x | HIGH     |
| Read Replicas | $300       | 3x capacity        | 10x | MEDIUM   |
| Load Balancer | $400       | 3x throughput      | 7x  | MEDIUM   |
| DB Sharding   | $1,200     | 4x capacity        | 3x  | LOW      |

最佳实践

  1. 先测量： 不要盲目优化
  2. 从容易见效的地方入手： 优先采取简单有效的措施
  3. 进行负载测试： 在投入生产前验证
  4. 持续监控： 设置告警
  5. 提前规划： 在达到限制前扩展
  6. 关注成本： 根据投资回报率做决策
  7. 循序渐进： 进行小幅、安全的变更

输出检查清单

  • 当前系统配置
  • 已识别并测量瓶颈
  • 按所需工作量排列扩展策略
  • 为每项操作定义触发条件
  • 分阶段计划（1x → 10x → 100x）
  • 各阶段的成本估算
  • 负载测试计划
  • 监控仪表板
  • 回滚流程

评论

支持 Markdown