Software Architect · 模块 14
Scalability 是系统沿着关键轴增长的能力——同时不让复杂度和成本以不成比例的方式上涨。
Vertical scaling · horizontal scaling · partitioning · capacity
你要扩展的是具体的负载：用户、写入、读取、数据量、团队，或者地区。
增长有不同的形态
餐厅可以靠加桌子增长，可以靠外卖增长，可以靠在不同城区开分店增长，也可以靠提升服务速度增长。每一种都是不同的架构。
Vertical scaling 是给单个节点增加资源。Horizontal scaling 是增加节点。Read replicas 改善读取，但帮不了写入。Sharding 解决数据量与写入压力，但会让查询、事务和运维都更复杂。
架构师必须明确 axis of scale。一个在读取上扩展得很好的系统，可能在写入上表现糟糕；一个能扛住流量的服务，如果所有变更都得经过同一个团队，组织维度上反而扩展不开。
Capacity planning 胜过英雄主义
提前知道场馆容量，比敞开大门后指望墙会自己扩张容易得多。
Capacity planning 要回答这些问题：当前承载多少负载，预期增长多少，上限在哪里，扩容的 lead time 是多少，哪些 alarms 会在接近上限时触发。
没有这些，团队只能从用户那里得知系统的上限。这种代价永远更贵。
可扩展性应该从真实的负载画像中生长出来——而不是出于对未来的抽象恐惧。
例子：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 在哪里？- 哪个信号会告诉我们架构必须改变？- 能否在保留迁移路径的前提下推迟这部分复杂度？