开发者眼睁睁看着他们刚刚发布的应用在几千名用户点击“开始”的那一刻陷入停滞，而这种减速很少是因为代码中的 Bug——它通常是服务器的 CPU 和 RAM 在争夺资源。瓶颈表现为页面加载变慢、超时或直接崩溃，这会损害用户体验、收入和品牌信任。

为什么在实验室运行良好的服务器在生产环境中会陷入停滞

在开发过程中，单个开发者只会发送少量请求，因此服务器资源大部分时间处于空闲状态。当应用上线后，每一位访问者都会产生一个请求，而每个请求都需要两个核心要素：

  • CPU (中央处理器) – 运行每个循环、函数和计算的处理器。可以把它想象成一位厨师，一次只能准备有限数量的菜肴。一个订单可以立即完成；但如果有上百个订单，厨师的工作速度虽然没变，食客却需要等待更长时间。
  • RAM (随机存取存储器) – CPU 在处理请求时所需数据的临时存储空间。它就像是厨师放置每道菜所需食材的工作台。如果工作台满了，厨师必须停止接收新订单，直到腾出空间。

当数千名用户同时登录时，每个请求都会占用一定的 CPU 时间和一部分 RAM。服务器有限的两种资源池会被分配给各个请求，导致队列不断增长。服务器本身并没有变慢，而是每个请求的等待时间增加了。

“直接买台更大的机器”这种诱惑

第一反应通常是升级机器——这种做法被称为垂直扩展 (vertical scaling)。增加更多的 CPU 核心或更多的 RAM 确实可以提高容量：从 4 核升级到 16 核，或从 8 GB 升级到 64 GB，可以在不更改任何代码的情况下吸收更大的流量峰值。

然而，垂直扩展会遇到硬天花板：

  • 物理限制 – 每块主板只能承载一定数量的核心和有限的内存。
  • 边际收益递减 – 每增加一个核心或 GB 内存的成本都比前一个更高，而性能增益却在缩小。
  • 单点故障 – 如果这台超大规格的服务器宕机，整个服务就会消失。

由于这些限制，行业巨头——流媒体平台、搜索引擎、电子商务网站——都已经不再依赖单台“怪兽级”机器。

另一种选择：将负载分摊到许多较小的机器上

与其建造一座更高的塔，不如增加更多中等规模的服务器并让它们共同分担流量。这种水平扩展 (horizontal scaling) 的方法让每台机器都保持在舒适的性能区间内，并避免了垂直升级带来的指数级成本曲线。

协调多台机器需要一个负载均衡器 (load balancer) —— 这是一种软件或硬件，它接收每个传入请求并将其转发给可用容量最大的服务器。负载均衡器向客户端隐藏了复杂性；从用户的角度来看，网站仍然像是一个单一的端点。

水平扩展还带来了韧性。如果一个节点崩溃，负载均衡器只需将流量路由到其他健康的节点，从而保持服务运行。

开始增加机器时需要注意什么

  • 无状态设计 (Stateless design) – 请求不应依赖于仅存储在特定服务器内存中的数据；否则，用户可能会被分配到一个缺乏所需上下文信息的节点。使用共享缓存或数据库可以解决这个问题。
  • 健康检查 (Health checks) – 负载均衡器必须能够快速检测到故障服务器并停止向其发送流量。
  • 自动扩缩容策略 (Auto-scaling policies) – 许多云平台允许你定义阈值（CPU 使用率、请求延迟），从而自动启动或关闭实例，使成本与需求保持一致。

反方观点：垂直扩展并未过时

对于小型团队或低流量应用，一台配置强劲的单台服务器可能是最简单、最便宜的解决方案。如果流量峰值是可预测的（例如预定的产品发布），那么临时的垂直升级可能比部署一整套新实例更实际。

关键在于要意识到“大机器”策略何时不再能提供成比例的价值，并开始规划分布式架构。

总结

发布后的服务器变慢通常是资源争用问题，而非代码缺陷。CPU 周期和 RAM 资源是有限的，当大量请求同时到达时，它们会排队，从而延长响应时间。垂直扩展可以为你争取到一些缓冲空间，但很快就会遇到物理和经济上的限制。水平扩展——即在负载均衡器后添加更多配置适中的服务器——随着流量的增长，提供了一条更廉价、更具韧性的路径。一旦你注意到队列开始变长，就该评估是增加几个核心就足够了，还是应该开始将负载分散到多台机器上。

来源：dev.to 文章 “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”