在当今技术驱动的时代，分布式系统已成为支撑大规模互联网服务和应用的基石。然而，在围绕系统设计和优化的话题中，扩展性（Scalability）和性能（Performance）常常被混为一谈。实际上，扩展性与性能虽然关联紧密，但它们指向的核心概念和衡量方式截然不同，理解这两者的区别至关重要，有助于设计出既高效又灵活的系统。性能通常是指系统处理单个任务的速度，具体体现在延迟（Latency）和吞吐量（Throughput）两个核心指标上。延迟代表完成一项任务所需的时间，而吞吐量指单位时间内系统能够处理的任务数量。二者虽有关联，延迟降低往往会提升吞吐量，但在实际工程中，降低延迟极其困难，且收益递减明显，因此大多数分布式系统更倾向于通过提升吞吐量来提高整体性能，即使这有时会导致延迟的提升。
相比之下，扩展性关心的是系统处理能力的可调整性，具体表现为系统能否根据负载变化灵活地增减资源，从而保证持续达到目标负载水平。扩展性强调系统的容量（Capacity）能否动态扩展，以应对不确定且波动较大的任务输入速率。为了阐明二者的区别，可以构建一个简化模型，只有两个核心要素：计算单元（Boxes）和任务（Jobs）。这里的计算单元可以代表虚拟机、容器或者单一进程，任务则是服务器需要处理的具体操作，例如HTTP请求处理、数据库查询或者支付交易等。模型中假设每个任务所需处理时间固定，也就是固定的延迟，每个计算单元同时只能处理一个任务，且所有计算单元处理任务的速率相同。这虽然是简化版的假设，但足以帮助理解核心概念。
在仅有单个计算单元的情况下，吞吐率等于反向延迟。举例来说，如果任务延迟为1秒，则吞吐率为每秒1个任务。随着计算单元数量的增加，总吞吐率等于单个计算单元吞吐率乘以计算单元数量。换句话说，增加计算单元数量能线性提升系统吞吐率，这就是系统扩展的基础。扩展性体现在能够快速创建和销毁计算单元，系统吞吐量随业务需求剧烈波动而动态调整。需要注意的是，扩展并非“免费午餐”。
每新增一个计算单元，都代表着更高的成本，无论是硬件、云服务费用，还是运维成本，都会随之增长。通过模型的计算，成本与吞吐率和延迟成正比，这意味着想要处理更多任务就必须相应地支付更多费用。面临的挑战是，任务输入速率（JobRate）并非恒定不变，往往随时间波动。系统设计者需要确保系统的吞吐率能够匹配任务速率，否则当任务速率超出系统吞吐限度时，会出现“丢失任务”现象，系统无法完成所有请求，带来严重的负面影响。反之，如果系统吞吐率远高于任务速率，则意味着资源浪费，系统利用率（Utilization）下降，产生额外的成本支出。因此，合理的系统设计目标是保持较高但不过载的利用率，通常建议在0.8左右，以保证系统既有一定余量应对突发峰值，又不会因过度闲置造成资源浪费。
而这就要求系统必须根据任务输入动态调整容量，以实现扩展性。系统扩展的真正意义，不是单纯追求单个计算单元的性能提升，而是以需求为驱动，灵活调整计算单元数量，确保利用率稳定不变。如此，尽管单个计算单元性能固定，整个系统的吞吐率可以随任务的波动实现弹性伸缩。不同组件的扩展能力可能各不相同，整个系统的可扩展性取决于整体架构的设计，这使得构建真正可弹性扩展的分布式系统复杂且重要。由于构建高效且灵活的扩展能力难度大，许多企业更愿意依赖大型云服务提供商，借助其弹性的基础设施实现扩展性。尽管成本可能远高于传统虚拟机方案，但通过租用服务器无服务模式（Serverless）等方案，企业可以获得极高的扩展弹性，保证峰值时的可用性。
相关研究显示，Serverless在相同吞吐率下的成本可能是虚拟机的百倍，但对于任务量在一天中可有可能变化十万倍的场景，这种弹性付出是合理且必要的。总结来看，扩展性和性能代表了系统设计中截然不同的关注点。性能强调任务执行速度，优化单个计算单元的效率，而扩展性关注能否动态匹配整体容量与任务负载，从而保证系统稳定运行。混淆两者概念可能导致投入重点偏差，浪费资源。现代分布式系统更多地倾向于追求扩展性，以应对业务的不确定性和波动性。理解它们的根本区别，有助于做出更合理的架构设计与资源投入决策，最终成就高效且可靠的系统。
未来随着技术不断进步，我们可以期待更深入的模型和实践，帮助工程师在性能与扩展性之间寻找到更佳的平衡方案。
