容量估算与架构分层

0. 元信息

• 主题路径：docs/topics/system-design/subtopics/capacity-and-architecture/README.md
• 父主题：system-design
• 主分类：工程技术
• 辅助分类：计算机基础
• 适合对象：会写后端服务、用过 Docker、做过 SQL 调优的工程师
• 建议周期：1～2 周（每周 6～10 小时，重点是白板画图与压测）
• 前置知识：network、rest-api-design、algo-design、db-and-sql；熟悉至少一门后端语言
• 最终目标：拿到一道经典系统设计题，能在 15 分钟内完成「DAU → QPS → 存储 → 带宽 → 成本」估算，画出 DNS / GSLB / L4 / L7 / 网关 / 业务 / 缓存 / DB / MQ 完整分层

1. 学习路线

容量估算公式 → 读 / 写 QPS 拆分与峰值倍数 → 存储与带宽估算 → 成本估算
  → DNS 解析与 GSLB 调度
  → L4 负载均衡（Nginx Stream / LVS / HAProxy / 云 LB）
  → L7 负载均衡（Envoy / Nginx / APISIX / Kong）
  → API 网关（鉴权、限流、灰度、协议转换）
  → 无状态业务 + 有状态数据
  → 分库分表（水平 / 垂直 / 冷热分层 / 一致性哈希）
  → 读写分离与主从延迟
  → 压测方法学（wrk / vegeta / k6 / 影子流量 / 全链路）

每一步都要落到一道白板题：短链 / Twitter timeline / 限流 / 排行榜。

2. 阶段周数分配

精简子主题不固定周数。按 §3 顺序完成，卡住时回到 §9.3 论文与白板视频。

3. 九阶段表

4. 第一周任务

精简版省略固定日程。先完成阶段 1~3 的最小可用版本：估算表 + DNS 调度 + L4 压测。

5. 阶段通用验收

精简版省略；每个产出至少保留估算参数、组件图、压测报告、版本与日期。

6. 最终验收

精简版省略；以 §3 第 9 阶段和 §9.4 问题口述检查为准。

7. 综合项目

精简版省略；成果并入父主题百万 QPS 短链项目（容量估算 + 分层组件图 + 压测报告）。

本主题贡献

• 在父主题 system-design 的综合项目「百万 QPS 短链」中，本主题（容量估算与架构分层）负责 组件骨架与压测报告：把 §3 9 阶段跑通，给出 DAU → QPS → 存储 → 带宽 → 成本 5 步估算表、DNS / GSLB → L4 → L7 → 网关 → 业务 → 缓存 → DB → MQ 完整分层图，以及端到端压测报告。
• 工程动作：用 wrk / wrk2 / vegeta / k6 跑 5 阶段压测（单接口 → 单链路 → 全链路 → 影子流量 → 真实回放）；用 LVS / HAProxy 对 L4、Envoy / APISIX 对 L7 做对照；用 ShardingSphere JDBC 做水平分库分表并验证 Sharding key 的热点；用一致性哈希（hash(key) → 第一个 ≥ 它的节点 + 虚拟节点 ≥ 64 / 节点）测节点上下线命中率变化。
• 与 system-design 其它子主题对接：把分层图与压测基线传给 caching-and-data-layer 让其挂缓存；给 reliability-and-observability 提供 SLO 候选 SLI（请求量、错误率、P99）；给 consistency-and-messaging 预留 MQ 入口。

交付物清单：

1. capacity/estimate.md：DAU / QPS / 存储 / 带宽 / 成本 5 步表 + 短链 case：DAU 1e7、单条跳转 1.5 KB、平均读 QPS 2 万、峰值倍数 5×、存储 / 天 1.3 TB、Redis 命中率 95%；
2. arch/layers.svg + arch/layers.md：8 层组件图（DNS → GSLB → L4 → L7 → 网关 → 业务 → 缓存 → DB → MQ），每层标注职责、依赖、失败模式、降级策略；
3. bench/l4_vs_l7.md：LVS（L4）vs Envoy（L7）压测对照，含 P50 / P95 / P99、CPU、conn established、错误率四张表与瓶颈定位；
4. bench/sharding.md：ShardingSphere 4 库 8 表配置 + EXPLAIN ANALYZE + 压出 QPS ≥ 10 万的报告（含 P99 ≤ 50 ms），附分片键选择证据。

验收标准：

• 压测报告含 P50 / P95 / P99、错误率 < 0.5%、饱和度曲线，并指出瓶颈；
• 节点下线 1/4 时命中率变化 < 5%（一致性哈希 + 虚拟节点 ≥ 64 / 节点）；
• 容量估算表的所有数字都能在 §3 阶段产出里反向追溯到 §9.6 实体版本与日期。

8. 推荐资料

精简版省略；使用 §9.3 和 §9.6 Source。

9. 学习资料汇聚（v0.3 自包含）

9.1 背景与动机

容量估算与架构分层是系统设计的「地基」。没有这块，后面所有缓存、一致性、限流、观测都失去了衡量尺。Jeff Dean 2012 年的 LADIS 演讲 “Achieving Rapid Response Times in Large Online Services” 把「延迟、并行、队列、批处理、长尾」五条经验写进系统设计界。Twitter、Facebook、LinkedIn 在 2010~2015 年的工程博客几乎覆盖了所有「估算 → 分层 → 压测」的标准范式。

9.2 概念地图

flowchart TB
  Estimate[容量估算: DAU/QPS/存储/带宽/成本] --> DNS
  DNS --> GSLB[GSLB 跨地域调度]
  GSLB --> L4[L4 负载均衡]
  L4 --> L7[L7 负载均衡 / API 网关]
  L7 --> App[无状态业务]
  App --> Cache[缓存层]
  App --> DB[数据层]
  DB --> Shard[分库分表 + 一致性哈希]
  DB --> MasterSlave[读写分离]
  App --> MQ[消息层]
  Estimate -.约束.-> Cache
  Estimate -.约束.-> DB
  Estimate -.约束.-> MQ
  Estimate -.成本.-> Cost[基础设施成本]

关系说明：容量估算决定每一层的容量目标；DNS / GSLB 解决地域调度；L4 / L7 解决集群内调度；网关做协议转换与边界保护；分库分表与读写分离解决单库容量边界。

9.3 基础知识讲解

9.3.1 论文 / 规范

• Jeff Dean, Achieving Rapid Response Times in Large Online Services（2012，Google LADIS）。
• Karger et al., Consistent Hashing and Random Trees（1997，ACM STOC）。
• DeCandia et al., Dynamo: Amazon’s Highly Available Key-value Store（2007，SOSP）。
• Schurman, Brutlag, The User and Business Impact of Server Delays（2009，Strangeloop）。
• Envoy xDS 协议规范（envoyproxy.io）。
• K8s Service / Ingress 规范（kubernetes.io）。

9.3.2 书

• Brendan Gregg, Systems Performance（2nd ed., 2020）第 2、6 章。
• Martin Kleppmann, Designing Data-Intensive Applications（2017）第 1、5 章。
• Sam Newman, Building Microservices（2nd ed., 2021）第 3~5 章。
• Baron Schwartz 等, High Performance MySQL（3rd ed., 2012）第 10~12 章。
• Cloudflare Learning Center：CDN / 边缘基础。

9.3.3 博客 / 文档

• Uber Engineering: Schemaless：分库分表实战。
• Discord Engineering: Trillions of Messages：存储演进。
• Instagram Engineering: Sharding & IDs：Snowflake ID。
• AWS Architecture Blog：分层案例。
• Brendan Gregg Blog：性能方法论。
• Envoy 文档 与 APISIX 文档：网关实战。

9.3.4 人物

• Jeff Dean：Google 大型系统性能哲学。
• Brendan Gregg：性能与 eBPF 观测。
• Werner Vogels：Amazon CTO，最终一致性与大规模分层。
• Martin Kleppmann：DDIA，数据系统原理。
• Rob Pike：Go、分布式系统风格。

9.3.5 方法

• Capacity-first：先算 DAU × 读写比 × 峰值倍数 × 对象大小 × 留存期，再画图。
• Layered failure analysis：每层列职责、依赖、失败模式、降级策略。
• 99th-percentile thinking：用 P99 / P999 决策，不要被平均延迟骗。
• 容量压测 5 步法：单接口 → 单链路 → 全链路 → 影子流量 → 真实流量回放。
• Idempotent design：所有写操作考虑幂等，重试不会爆。

9.4 经典问题与经典案例

9.5 学习难点

• 概念难点：L4 与 L7 边界容易混。卡点来自把”四层透明代理”当”七层反向代理”；用 wrk 压 L4 看到 100 万 QPS，压 L7 看到 10 万 QPS，差距就是协议解析与策略开销。
• 思维难点：容量估算起步。不会起步就用 DAU × 读写比 × 对象大小 × 留存期 跑通一遍；峰值倍数取 5~10×。
• 工程难点：压测环境与生产环境差异。卡点来自：硬件、网络、依赖、配置；用影子流量把真实流量复制到新集群，逐项对账。

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• L4 解决传输层调度；L7 解决应用层协议解析、路由、灰度。
• 一致性哈希解决「节点上下线对命中率影响最小」。
• 分库分表解决单库容量与并发边界。
• 压测方法学验证容量估算的正确性。

9.6.3 Structure

• 容量估算：DAU → QPS → 存储 → 带宽 → 成本 五步。
• 一致性哈希：哈希环 + 虚拟节点；hash(key) → 第一个 ≥ 它的节点。
• 分库分表：分片键 + 路由函数 + 跨片查询合并 + 扩容再哈希。
• 读写分离：主库写、从库读；强制走主、半同步复制、读已提交隔离。
• 压测流程：环境准备 → 数据准备 → 单接口 → 单链路 → 全链路 → 报告。

9.6.4 Ecosystem

• 负载均衡：Nginx / HAProxy / LVS / Envoy / APISIX / Kong / 云 LB。
• 容器与编排：Docker / Kubernetes / Istio / Linkerd。
• 压测：wrk / wrk2 / vegeta / k6 / Locust / JMeter / gatling。
• 数据库中间件：ShardingSphere / Vitess / MyCat / ProxySQL / MaxScale。

9.6.5 Depth Tiers

本计划目标：L3。

9.6.6 Source

• Brendan Gregg: Systems Performance。
• Envoy 文档 与 APISIX 文档。
• ShardingSphere 文档。
• 引用快照：2026-07-30。

10. 常见误区

• 不做容量估算就画组件图
• 把所有请求都让 L7 网关解析
• DNS 调度假设 TTL = 0
• 一致性哈希忘记虚拟节点
• 分库分表键选错导致热点
• 读写分离不处理主从延迟
• 压测用生产数据
• 压测环境与生产环境差异不报告
• 不留容量压测报告
• 限流只靠网关，进程内裸奔。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础
4. 工程技术
5. Web 与后端
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力
9. 安全与可靠性

本计划归属：工程技术 主 + 计算机基础 辅。