# 14. 可扩展性

如何区分 vertical 与 horizontal scaling，partitioning、queues、read models 和 capacity planning 在哪些场景下真正有价值。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-14-scalability

---

## 1. 核心思想

你要扩展的是具体的负载：用户、写入、读取、数据量、团队，或者地区。

### 增长有不同的形态

> 餐厅可以靠加桌子增长，可以靠外卖增长，可以靠在不同城区开分店增长，也可以靠提升服务速度增长。每一种都是不同的架构。

Vertical scaling 是给单个节点增加资源。Horizontal scaling 是增加节点。Read replicas 改善读取，但帮不了写入。Sharding 解决数据量与写入压力，但会让查询、事务和运维都更复杂。

架构师必须明确 axis of scale。一个在读取上扩展得很好的系统，可能在写入上表现糟糕；一个能扛住流量的服务，如果所有变更都得经过同一个团队，组织维度上反而扩展不开。

### Capacity planning 胜过英雄主义

> 提前知道场馆容量，比敞开大门后指望墙会自己扩张容易得多。

Capacity planning 要回答这些问题：当前承载多少负载，预期增长多少，上限在哪里，扩容的 lead time 是多少，哪些 alarms 会在接近上限时触发。

没有这些，团队只能从用户那里得知系统的上限。这种代价永远更贵。

## 2. 例子与反例

可扩展性应该从真实的负载画像中生长出来——而不是出于对未来的抽象恐惧。

### 例子：read-heavy 产品

> 图书馆里成千上万人读书，但编辑书目的只是一支小团队。

文档服务读多写少。架构依赖 CDN、static generation、edge caching 和一个 read-optimized 的搜索索引。Source of truth 保持简单。

这是一个不错的 trade-off：读取廉价地扩展，写入保持可控。

### 反例：第一个客户都没有就 sharding

> 给只停着一辆车的车库修一条八车道立交桥，既昂贵又不便利。

团队从第一天就设计 sharded database、routing layer 和 distributed transactions，而产品还在寻找 market fit。开发变慢、迁移变难，真实负载到底是多少还不知道。

Scalability 要留出增长的路径，但不必今天就把未来的每一层都实现出来。

#### 自检

- 系统应该最先沿哪条轴增长？- 当前的 capacity limit 在哪里？- 哪个信号会告诉我们架构必须改变？- 能否在保留迁移路径的前提下推迟这部分复杂度？

下一模块：[可靠性](./software-architect-15-reliability)。