系统设计容量估算与可观测性

🏗️ 容量估算让你在设计时就发现瓶颈，可观测性让你在出错时能快速定位。

容量估算模板

基础数据小抄

常用数据量级：
  DAU 100万：每秒 QPS ≈ 100 万 / 86400 ≈ 116 QPS
  请求带宽：100 QPS × 1KB = 100 KB/s = 0.1 MB/s
  存储：1TB = 1 万亿字节 = ~10亿张图片（各大约 1MB）

估算过程（以短视频平台为例）

1. 用户规模：1亿 DAU
2. 每人每天看 10 个视频
3. 视频请求：100亿次/天 = 1.1M QPS
4. 假设小时内平均，峰値 3×平均 ≈ 3.3M QPS
5. 需要的应用服务器（假设单机 5K QPS）：≈ 660 台
6. 存储：每个视频平均 100MB
   每天新增 100万个视频 = 100TB/天

---

系统设计核心组件

客户端 → CDN → 负载均衡 → API 网关
           ↓              ↓
     静态资源     应用服务层（水平扩展）
                        ↓
             缓存层（Redis） + 数据库层（分库分表）
                        ↓
              消息队列（异步解耦）

---

可观测性三支柱

1. 日志（Logging）

// 结构化日志（JSON 格式方便查询）
logger.info('Payment processed', {
  traceId: req.traceId,
  userId: user.id,
  amount: payment.amount,
  durationMs: Date.now() - startTime,
  status: 'success',
})

// 日志级别：
// ERROR: 需要立即处理
// WARN: 可能有问题
// INFO: 关键业务事件
// DEBUG: 调试信息（不应在生产开启）

2. 指标（Metrics）

// Prometheus 指标示例
const httpRequestDuration = new Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request duration in seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5],
})

// 业务指标示例
// SLI：请求成功率、P99 延迟、错误率
// SLO：成功率 > 99.9%、P99 < 500ms
// SLA：违诺后的赔偿方案

3. 调用链路踪（Tracing）

// OpenTelemetry 标准
import { trace } from '@opentelemetry/api'

const tracer = trace.getTracer('order-service')

async function processOrder(orderId: string) {
  const span = tracer.startSpan('processOrder')
  span.setAttribute('order.id', orderId)
  
  try {
    await paymentService.charge(orderId)  // 自动传播上下文
    span.setStatus({ code: SpanStatusCode.OK })
  } catch (e) {
    span.recordException(e)
    span.setStatus({ code: SpanStatusCode.ERROR })
    throw e
  } finally {
    span.end()
  }
}

---

常见误区

• 容量估算不考虑峰値流量，导致大促进时系统崩溃
• 日志没有 traceId，分布式系统中无法关联问题链路
• 只监控基础设施指标，没有业务指标 SLI/SLO