扩展性不是简单增加机器

扩展性描述的是负载增长时，系统能否通过增加资源或调整结构维持目标服务水平。它不同于某一时刻的高性能：一次请求很快，不代表并发增长后仍然稳定；能够增加实例，也不代表数据库、队列和运维能力会同步扩展。

先说明哪一种负载增长

负载可能来自用户并发、数据规模、写入速率、查询复杂度、租户数量或后台任务。不同增长维度会触发不同瓶颈。静态内容访问适合缓存和边缘分发，大量空间相交查询可能受计算与索引限制，批量导入则更关注写放大和队列积压。

扩展目标应包含基线、增长范围和服务水平，例如在请求量增长四倍时保持指定延迟分位数和错误率。只写“支持高并发”无法用于容量规划，也无法判断一次扩容是否成功。

无状态只是水平扩展的一部分

应用实例不保存会话状态，通常更容易复制和分配流量。但状态并没有消失，而是转移到数据库、缓存、对象存储或消息系统。新的集中依赖可能成为更明显的容量上限，并带来一致性与故障恢复问题。

水平扩展还依赖任务是否可以分割。若所有请求竞争同一把锁、同一热点记录或单一顺序队列，增加实例只会增加竞争。分区键选择、热点分散和幂等处理，往往比实例数量更决定实际吞吐。

排队会放大尾部延迟

资源利用率接近上限时，少量负载增长就可能造成等待时间急剧上升。平均延迟会掩盖最慢的一批请求，因此容量评估要关注高分位延迟、队列长度、饱和度和超时率。

超时、限流和背压用于阻止过载继续向下游传播。无限重试会在故障时制造更多流量，批处理若没有并发上限也会挤占在线请求。扩展设计必须包含过载时的退化方式，而不是假定资源总能及时增加。

数据层决定长期上限

读副本、缓存和分区可以分担不同类型的压力，但它们都会改变一致性和维护成本。缓存需要失效策略，读副本存在延迟，分区会使跨分区事务和查询更复杂。只有明确访问模式后，才能选择合适手段。

数据规模还影响备份、恢复、索引维护和迁移时间。在线查询能维持低延迟，并不表示系统仍能在目标恢复时间内重建。扩展性评估应把这些运维路径纳入，而不是只压测首页接口。

用测量和预算驱动扩容

Google SRE 将容量、负载和可靠性目标联系起来。实际工作中需要记录每类请求的资源成本，建立关键依赖的容量余量，并通过接近真实数据分布的压测验证。自动扩缩容依赖可靠指标，同时要考虑启动时间、冷缓存和扩容速度。

扩展性不是无限增长承诺，而是一组可解释的边界：在哪个负载范围内满足什么目标，哪项资源先饱和，如何增加容量，过载时如何保护核心功能。这样的描述才可用于架构决策和生产运行。

资料依据

• Carnegie Mellon University Software Engineering Institute：Reasoning About Software Quality Attributes，https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/
• Google：Site Reliability Engineering Books，https://sre.google/books/