系统设计
系统设计不是一堆时髦术语的集合。它是在约束条件下做出显式权衡的实践：延迟、吞吐量、可用性、一致性、成本、安全性和组织复杂度。
本知识库按分层心智模型组织。各层不是"必选组件"，而是一种推理职责归属和故障模式传播的方式。
层次地图
| 层 | 主要目标 | 典型职责 | 核心权衡 |
|---|---|---|---|
| 1. 入口层 | 安全、受控的流量入口 | 负载均衡、网关策略、认证、限流、边缘路由 | 治理 vs 延迟和爆炸半径 |
| 2. 服务层 | 业务能力交付 | 服务边界、通信模式、弹性行为 | 团队自治 vs 分布式复杂度 |
| 3. 存储层 | 正确性和扩展上限 | 数据建模、复制、分片、一致性模型 | 强保证 vs 可用性/吞吐量 |
| 4. 缓存层 | 低延迟和源站保护 | 缓存模式、失效策略、分布式缓存 | 速度 vs 数据过时和运维风险 |
| 5. 消息与分析 | 异步协作和洞察 | 队列/日志、事件、索引/搜索、分析 | 解耦 vs 可观测性和语义 |
| 6. 粗略估算 | 快速可行性评估 | 容量规划、瓶颈识别、成本估算 | 精确度 vs 决策速度 |
如何使用本节
对于大多数系统，按以下顺序阅读：
- 入口层和服务层：定义请求路径和职责边界。
- 存储层和缓存层：定义正确性、一致性和延迟策略。
- 消息和分析层：定义异步语义、工作流和查询/洞察需求。
- 粗略估算：在整个设计过程中使用信封背面估算法。
实用权衡框架
在设计方案之间做决策时，显式回答以下问题：
- 哪些指标优先保护（p99 延迟、错误率、可用性、成本、安全性）？
- 在峰值负载或部分故障下，什么最先崩溃，如何降级？
- 复杂度转移到哪里（产品团队、平台团队、运维/SRE、数据团队）？
- 当需求在三个月后变化时，迁移成本是多少？
- 当当前假设不再成立时，"逃生舱"是什么？
常见反模式
- 在就 SLO、规模和约束达成一致之前就设计系统。
- 过早过度优化（第一天就分片、到处微服务、"事件驱动"但语 义不清）。
- 把"最终一致性"当作免费性能提升，而不定义用户可见行为。
- 添加层但不承担运维成本（on-call、监控、事件响应）。
- 到处依赖重试而不设预算（重试风暴导致故障）。
导航
延伸阅读（精选）
- Martin Fowler：微服务和演进式架构相关文章。
- Martin Kleppmann：《Designing Data-Intensive Applications》（复制、一致性、流）。
- AWS Builders Library：可靠性、超时/重试和卓越运营模式。
- Elastic 文档：分片大小、副本和生命周期管理概念。