平均每秒请求数看起来稳定，不代表 API 在流量突增或部分资源故障时仍能正常响应。专属资源部署高并发API服务的容量规划，应从请求峰值、延迟目标和完整调用链入手，再用压测验证估算值。
误区一：用日均或小时均值代表峰值
平均值会掩盖短时尖峰。促销开售、定时任务集中执行、客户端重试，都可能让几分钟内的请求量明显高于日均水平。规划时至少区分日常流量、繁忙时段和突发流量，并查看分钟级或更细粒度的历史指标。没有历史数据时，可先根据业务调用计划设定待验证的峰值假设，不能把假设当成事实。
误区二：只看 RPS，不看并发与响应时间
相同的每秒请求数，若请求耗时不同，占用的工作线程、连接和内存也不同。可用 Little 定律作初步估算：并发请求数约等于每秒请求数乘以平均响应时间（秒）。例如，800 RPS、平均耗时 0.2 秒，对应约 160 个在途请求；若耗时升至 0.5 秒，则约为 400 个。这个估算不包含排队和长尾，应同时观察 p95、p99 延迟与错误率。
误区三：把单机压测最高值当作稳定容量
压测中短时间达到的最高吞吐，不等于可长期承载的吞吐。CPU 接近饱和、垃圾回收频繁或连接池排队时，延迟往往先恶化。应在与生产相近的请求比例、数据大小和依赖条件下测出单实例稳定吞吐，并以延迟和错误率是否满足目标作为判据。专属资源部署高并发API服务的容量规划，应采用稳定值而非极限值。
误区四：按实例数量估算，漏掉下游瓶颈
增加 API 实例不一定增加端到端容量。数据库连接数、缓存吞吐、消息队列消费速度，以及外部服务的限流，都可能成为瓶颈。逐项记录每个依赖的连接上限、可接受并发和超时设置；压测时观察连接池等待、查询耗时、缓存命中率及队列积压。若瓶颈在数据库，单纯扩容应用实例还可能增加连接竞争。
误区五：不预留突发和故障余量
所有实例满载运行，遇到单实例下线、滚动发布或流量突增时，就缺少接管空间。可先按目标峰值估算，再为维护和故障保留容量；余量比例需根据流量波动、恢复时间和服务等级确定，没有适用于所有 API 的固定值。部署时还要确认负载均衡健康检查、实例摘除和重试策略，避免故障请求反复压向剩余实例。
误区六：算完资源就结束，不做持续验证
代码版本、请求结构、缓存策略和数据规模都会改变资源消耗。容量不是一次性结论，应把压测、监控和扩容条件串起来。使用 k6 等工具模拟不同并发与请求比例，用 Prometheus 等监控记录吞吐、延迟、CPU、内存和依赖指标；发布后对照实际峰值修正模型。专属资源部署高并发API服务的容量规划，只有经过复测才具备可执行性。
按数据估算，再用场景压测校准
- 明确目标峰值 RPS、p95 延迟上限、错误率目标，以及需要承受的故障场景。
- 用生产代表性请求压测单实例，找出满足延迟和错误率要求的稳定吞吐。
- 初步计算实例数：目标 RPS ÷（单实例稳定吞吐 × 目标利用率），再向上取整。利用率应结合流量波动和扩容速度设定。
- 以结果测试依赖瓶颈，并模拟实例退出、滚动发布和突发流量，检查剩余容量与恢复过程。
- 上线后持续比较预测与实测，设置基于延迟、错误率或资源利用率的告警和扩容条件。
例如，若某 API 的假设峰值为 800 RPS，压测得到单实例稳定承载 200 RPS，并暂按 60% 利用率规划，则初步需要 7 个实例（800 ÷ 120 向上取整）。这是计算示例，不是通用配置；实际结果还要受请求复杂度、依赖能力和故障余量影响。专属资源部署高并发API服务的容量规划，关键是把假设逐项变成可测指标。
常见问题
压测必须使用生产流量吗？
不必直接复制敏感生产数据，但应尽量匹配请求比例、数据大小和依赖耗时，并做好脱敏与隔离。
应该优先扩 CPU 还是内存？
先看监控和压测证据：CPU 持续饱和可能需要更多计算资源；内存压力、频繁回收或缓存需求则要检查内存配置。不能只凭 RPS 判断。
专属资源是否能消除容量风险？
不能。它有助于减少共享资源竞争，但应用自身、依赖服务、网络和故障切换仍需纳入容量验证。
多久复核一次容量？
没有统一周期。流量结构、版本或依赖发生明显变化时应复测；平稳服务也应定期回顾峰值和告警记录。