容量估算器

你到底需要多少台服务器？用算术而不是感觉来回答：把你的请求速率、每个请求消耗的 CPU 时间和用户看到的响应时间告诉估算器，它会返回流量占用的核心数、应配置的整台服务器数——已应用你的冗余策略——你的连接池必须扛住的并发数，以及同一服务在两倍、五倍和十倍流量下的样子。

公式，用直白的话讲

核心数。把请求速率乘以每个请求消耗的 CPU 秒数：那就是流量在 100% 时占用的核心数。然后除以你的目标利用率——在 70% 时，你配置的每个核心在计划中只算 0.7 个核心，另外 0.3 是在流量波动时让队列保持短的余量。所需核心数 = 请求/秒 × 每个请求的 CPU 秒数 ÷ 目标利用率。

服务器数。把核心数除以每台服务器的核心数并向上取整——不存在 0.4 台服务器这回事，向下取整正是“平均能跑”的计划在峰值时失败的原因。冗余在取整之后应用：N+1 在取整后的数量上加一台备用；2N 把整个机群翻倍。并发数是另一个来自 Little's law 的数字：在途请求数 = 请求/秒 × 以秒计的响应时间。它决定线程池、数据库连接和文件描述符的规模——这些才是服务在 CPU 还在闲逛时真正撞上的上限。给出响应大小时，出口流量 = 请求/秒 × 大小 × 8，那就是你网络账单的构成。配套文章你到底需要多少台服务器解释了每个输入的来源，以及为什么厂商基准测试与这一切都对不上。

规划姊妹工具：SLA 错误预算计算器把这份容量所守护的可用性目标换算成分钟数，备份保留计算器则计算同一系统的存储一侧。

常见问题

为什么按 70% 利用率规划，而不是 100%？

因为队列在饱和之前就爆炸了，而不是在饱和那一刻。平均忙碌 95% 的 CPU，是一个每次流量波动队列都会无界增长的 CPU——而流量总会波动。利用率目标就是吸收峰值、发布、重试和一个慢依赖的余量。70% 是延迟敏感型服务的行业默认值；能容忍延迟的批处理工作进程可以跑得更热，而任何面向用户且尖峰明显的服务都应该跑得更凉。

核心数和在途请求数有什么区别？

它们回答的是不同的问题。核心数来自 CPU 服务时间：每个请求消耗多少处理器。在途请求数来自 Little's law：速率乘以响应时间，它们度量的是并发——连接、线程、保持打开的内存——而不是处理器负载。一个下游调用很慢的服务可以同时持有 500 个在途请求，却只用两个核心，它会先耗尽连接池，远在耗尽 CPU 之前。两者都要算，否则你忽略的那个就会变成事故。

我的负载测试说一台服务器能处理每秒 2,000 个请求。这个估算器为什么不同意？

负载测试通常测的是一个已预热、稳定、缓存全热的服务，它从一个大方的客户端回答一种请求形状。生产环境会加上冷启动、TLS 握手、重试、长尾的慢请求、吵闹的邻居，以及让容量减半十分钟的那次发布。这个估算器是故意保守的——平均 CPU 时间、利用率上限、整台服务器、再加上冗余。把负载测试当作可能性的上限，把这个数字当作应配置的下限；对规划而言，真相是下限。

N+1 实际上防的是什么？

一次故障：一台死掉的主机、一次被撤出轮换的坏发布、一个让单个实例下线的可用区事件。有了 N+1，剩下的 N 台服务器仍然能达到目标——这正是先按流量算出 N、再加上备用的意义。2N 是另一种承诺：两份完整副本，通常跨区域部署，为那些必须在失去整份副本后仍存活的服务而设。它让账单翻倍，所以只为那些缺席要用头条新闻来衡量的服务购买。

我怎么得到每个请求的 CPU 服务时间？

测出来，不要猜。在运行中的服务上：一个时间窗内消耗的 CPU 总秒数，除以同一时间窗内服务的请求数。应用性能监控工具会直接以每个请求的 CPU 形式报告；在 Linux 上，你可以从 /proc 中的进程 CPU 时间或容器指标推导。使用你最繁忙的真实一小时的数字，而不是全天平均值——用平均值规划的容量，恰恰会在它为之购买的那个峰值上失败。