副标题 / 摘要

性能关注“当前快不快”，可扩展性关注“增长后还能否保持”。本文拆解两者关系与常见误区。

目标读者

  • 负责性能与扩展性决策的工程师
  • 做容量规划与架构设计的团队
  • 经常被“性能优化”困扰的开发者

背景 / 动机

很多系统在小规模很快，但规模一上来就崩。
因为性能优化和可扩展性是不同维度，需要不同策略。

核心概念

  • 性能：单点/单实例的响应与吞吐
  • 可扩展性：负载增加后系统维持服务能力
  • 瓶颈：CPU / IO / 网络 / 数据库
  • 规模曲线：负载增加时性能曲线是否线性

实践指南 / 步骤

  1. 先测基线性能（单机极限）
  2. 观察扩展曲线（1x -> 2x -> 4x）
  3. 定位瓶颈组件
  4. 区分纵向与横向扩展策略
  5. 用容量规划指导架构

可运行示例

# 伪负载模型：用简单函数模拟扩展曲线

def capacity(instances, single_qps, overhead=0.1):
    return instances * single_qps * (1 - overhead)


if __name__ == "__main__":
    for n in [1, 2, 4, 8]:
        print(n, capacity(n, 1000))

解释与原理

性能是“单位资源的效率”，可扩展性是“资源增加后效率是否保持”。
如果瓶颈在共享组件（如数据库），扩容应用实例并不会线性提升整体性能。

常见问题与注意事项

  1. 性能好就代表可扩展吗？
    不一定，可能只是单点强。

  2. 扩展性差就需要重构吗？
    不一定，先定位瓶颈。

  3. 缓存能解决扩展性问题吗？
    只能缓解部分读压力。

最佳实践与建议

  • 用压测画出扩展曲线
  • 关注共享瓶颈（DB、锁、网络）
  • 设计可扩展性优先的系统边界

小结 / 结论

性能解决“当前快”，可扩展性解决“增长后还能快”。
两者相关但不等价，必须分别优化。

参考与延伸阅读

  • Designing Data-Intensive Applications
  • Capacity Planning 指南

元信息

  • 阅读时长：7~9 分钟
  • 标签：性能、可扩展性、容量规划
  • SEO 关键词：Performance, Scalability
  • 元描述：解释性能与可扩展性的关系与差异。

行动号召（CTA）

给你的系统画一条“实例数 vs QPS”曲线，你会更清楚扩展瓶颈。