API服务部署VPS怎么选：并发与延迟

一、API接口的流量画像和普通网页完全不是一回事

API服务器最容易踩的坑，是拿建站选型的思路去挑机器。博客的静态页面被反复读取，源站处理的是同一份内容，命中缓存之后几乎不消耗算力；API请求恰好相反，每一次调用都要走完整链路：参数校验、鉴权、查库、计算、序列化、返回，多数接口连一次静态资源缓存的机会都没有。所以衡量一台 API服务器 的第一指标不是配置表上的核数，而是单请求真实消耗了多少 CPU 毫秒。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

第二个差别在响应体积。网页首屏通常是几十到几百 KB 的 HTML 加静态资源，API 的一次响应往往只有几百字节到几 KB。带宽压力小，但请求频次高，连接数、文件描述符、进程数会先于带宽触顶。第三个差别在可预测性：网页有明显的日高峰和低谷，API 的调用方往往是另一台机器上的程序，它会按自己的节奏重试，失败一次可能立刻打三轮，把本来轻微的抖动放大成雪崩。

这张表给出的判断是：接口越轻，横向扩展越划算；接口越重，单机性能越值钱；一旦涉及持续大流量传输，任何配置优化都会被带宽成本盖过，选型逻辑要换一套。

还有一层容易被忽略的差别是幂等性。幂等接口允许客户端放心重试，重试风暴的破坏力被限制在可控范围；非幂等的写接口一旦重试，就可能产生重复订单、重复扣款这类业务损失。为非幂等接口设计重试策略时，必须要求客户端带唯一请求标识，服务端做去重，这本身又是一笔额外的实现成本。

另外要区分同步接口和异步回调接口。同步接口把全部耗时压在一个 TCP 连接里，任何一段抖动都会体现在用户等待上；异步接口把耗时甩给后台队列，用户只等到一个受理回执，感知延迟接近零。两者的服务器选型逻辑因此完全不同，前者要抠毫秒，后者更看重吞吐和队列可靠性。

二、并发到底怎么估：别问 QPS，先问单请求成本

估算并发最常用的公式是利特尔法则：平均并发数等于 QPS 乘以平均处理时间。注意这里的时间要用秒，而不是毫秒。一个处理耗时 50 毫秒的接口，在 100 QPS 下平均并发只有 5；同样的 100 QPS，如果单请求要 500 毫秒，平均并发就是 50，两者对机器的要求差了一个数量级。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

平均并发只是起点，规划时要按峰值乘以余量。经验做法是取平均值的 2 到 3 倍作为需要承载的并发目标，因为流量不是均匀到达的，突发会叠加在均值上。再往下推一步：单实例安全并发约等于 CPU 核数乘以 1000 再除以单请求 CPU 毫秒数，这是按每秒每个核能消化一千毫秒 CPU 时间估算的保守口径，真实值取决于语言运行时、序列化开销和缓存命中率，必须实测校准。

假设一台 2 核机器，单请求实测 CPU 时间为 8 毫秒，估算安全并发是 250；按六成利用率取 150。而单请求 CPU 时间是 40 毫秒的接口，同样的 2 核机器安全并发只有 50。这就是为什么两种业务在同一台机器上的表现天差地别。

# 用 hey 做一次固定并发压测，观察 P99 与错误率
hey -n 20000 -c 50 -m POST \
  -H "Content-Type: application/json" \
  -d '{"page":1,"size":20}' \
  https://api.example.com/v1/items

# 用 ab 测单请求 CPU 消耗（-k 保持连接，避免握手噪声）
ab -k -n 5000 -c 20 \
  -H "Content-Type: application/json" \
  -p payload.json \
  https://api.example.com/v1/items

判读方式：hey 输出末尾的 50%、90%、95%、99% 分位延迟和 RPS。如果 99% 分位延迟是 P50 的十倍以上，说明存在排队或者连接池瓶颈，而不是算力不够；这时先看是不是数据库慢查询，再看工作进程数是否远大于 CPU 核数。ab 的 Time per request 在高并发下会显著上升，这个上升幅度就是排队成本的直接证据。

压测还有一个常被忽略的变量是数据规模。同一个查询，在只有一千条记录的表上和在有几百万条记录的表上，返回时间可能差两个数量级。所以压测数据必须是接近生产真实量的数据，用生产数据的脱敏副本或者按比例生成的分级数据都可以，用空库跑出来的漂亮数字没有任何意义。

并发估算最终要落到一台具体的机器上。假设业务方给出的目标是峰值 800 QPS、平均并发按三倍峰值预留、单请求实测 CPU 时间 12 毫秒，那么平均并发是 800 乘以 0.012 等于 9.6，按三倍预留是 29；单实例安全并发按 2000 除以 12 约等于 166，取六成利用率是 100。这样一台 2 核机器绰绰有余，还有余量做滚动发布。反过来如果单请求是 120 毫秒，平均并发变成 96，按三倍是 288，单实例安全并发只有 16，需要十八台。这就是为什么同一个 QPS 目标在不同业务上对应着天差地别的采购单。

三、延迟到底由哪几段构成：别只盯着服务器那 30 毫秒

一次 API 请求的端到端延迟可以拆成七段：DNS 解析、TCP 握手、TLS 握手、请求排队、服务端业务处理、数据库往返、响应传输与客户端读取。很多人在服务器上测出 30 毫秒的响应时间，就以为用户感受到的也是 30 毫秒，这个推断只在连接始终复用的情况下成立。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

跨境访问的物理下界是光速往返。常见骨干链路往返时间大致在 150 到 250 毫秒量级，跨太平洋方向更高。如果客户端每次调用都新建连接并重新握手，光握手就要吃掉两到三个往返，加上 DNS 解析，客户端实际等待往往在 400 毫秒以上，比服务端处理时间高一个数量级。

# 拆开看每一段耗时，DNS/TCP/TLS/首字节/总时长
curl -s -o /dev/null -w \
  "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
  https://api.example.com/v1/health

# 复用连接再测一次，差值就是握手成本
curl -s -o /dev/null -w "ttfb=%{time_starttransfer} total=%{time_total}\n" \
  https://api.example.com/v1/health \
  --next https://api.example.com/v1/health

结论很直接：能用连接复用就用。开启 HTTP/1.1 keep-alive 或 HTTP/2 多路复用，让一次 TLS 握手覆盖大量请求；即便如此也要做会话级重连策略，因为长连接在中途被网络设备掐断是常态，客户端必须能无感重连而不是把错误直接抛给用户。

延迟预算是一种很实用的拆解方式。先给整条链路定一个用户可接受的总时长，比如三百毫秒，然后从前往后逐段分配：DNS 解析不超过二十毫秒，握手不超过一百毫秒，服务端处理不超过一百五十毫秒，响应传输和客户端解析不超过三十毫秒。分完之后每段都有明确的上限，监控也就能对号入座定位是哪一段越界。没有预算的延迟监控只能看到一个笼统的总数字，出问题时无从下手。

还要区分冷启动和热路径。服务刚启动时，第一次请求要加载模型、初始化连接池、预热 JIT，耗时可能是热路径的十倍甚至更多。对于偶发的低频接口，冷启动是常态而非异常，缓解办法是保持最小数量的常驻实例加定期预热请求，或者把初始化过程做成开机自启的脚本在流量到达前跑完。

四、线路和机房怎么选：延迟、抖动、丢包是三件事

选机房时用延迟作为唯一标准是最常见的错误。真正影响接口体验的是三个独立维度：平均延迟决定快不快，抖动决定稳不稳，丢包决定会不会偶发卡死。跨洲链路的平均延迟可以接受，但抖动到几百毫秒或者出现百分之几的丢包时，重传会让实际耗时成倍放大，接口看起来时快时慢。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

对国内用户为主的接口，线路类型的影响远大于同机房内的配置差异。常见做法是先按地理位置选机房，再对比回程路由质量，最后才比较价格。可提供 CN2 GIA、CU VIP、9929 等优质回程线路的商家在具体机房的实际开通情况差别很大，必须向商家确认到具体套餐，不能凭品牌默认。

# 看路由和丢包，跑满 100 个包
mtr -r -c 100 -n api.example.com

# 测抖动：连续 30 次握手耗时，看离散程度
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{time_connect}\n" https://api.example.com/v1/health
done

# 测丢包与吞吐，双向各跑 10 秒
iperf3 -c speedtest.example.com -t 10 -P 4

判断标准建议这样定：接口是幂等的读操作、客户端能自动重试，容忍 200 毫秒级别延迟，选地理最近的机房即可，稳定性靠重试和超时兜底；接口是写操作、要等用户点确认，延迟必须压到 100 毫秒以内，就要在用户所在区域就近部署；调用方在境外而用户在境内，两地都要部署，让请求在最近的节点终结。

机房选择还要看一个容易漏掉的点：同一台物理服务器上，别的租户干了什么你控制不了。共享资源的争抢在超售严重的机器上会表现为磁盘 IO 的延迟尖刺，而且完全没有规律可循。这也是为什么同样配置的两台机器实测结果可能差很多，以及为什么要在业务高峰时段再测一轮。

五、数据库要不要分离：先回答三个问题

判断 API服务器 的数据库是否该独立，看三个问题而不是看感觉。第一个问题：单次查询的返回行数是不是经常超过千行，超过的话结果集本身就在消耗网络和内存，同机部署的意义不大。第二个问题：数据库的磁盘 IO 是不是已经打满，用 iostat 看 await 值，如果读等待长期超过 20 毫秒，API 进程的响应延迟会被直接拖住。第三个问题：业务有没有独立的备份和恢复窗口要求，因为数据库和应用共机时，一次整机故障会同时打掉接口和存量数据。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

共机部署的优势是省掉一次跨网往返。数据库在同机同回环网卡上，往返时间在零点几毫秒量级；一旦挪到另一台机器甚至另一个机房，往返时间变成 0.5 到 200 毫秒，而一次需要五到十次查询的业务链路，会把这个差距乘以上述次数。这就是很多接口在把数据库挪走后反而变慢的原因。

# 看当前连接与等待情况
psql -c "select state, count(*) from pg_stat_activity group by state;"
psql -c "select query, calls, mean_exec_time from pg_stat_statements order by mean_exec_time desc limit 10;"

# 看磁盘 IO 等待
iostat -x 1 5

# 确认连接池规模与进程数是否匹配
ss -s
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -15

有三条实操建议。第一，连接数上限要和进程数匹配，PostgreSQL 默认 max_connections 是一百，每来一个应用进程就占一个连接，机器上跑十几个 worker 很快就会顶到上限。第二，超过三十个以上进程的场景下，前面挂一层连接池做事务级复用，能把连接数从数百降到几十。第三，数据库迁移到独立机器时，把应用侧的超时和重试策略一起改掉，否则原先 5 毫秒的调用突然变成 200 毫秒而没有超时保护，线程会被拖垮。

分离之后的架构还需要处理数据同步问题。主库写入、从库读取的读写分离方案里，最难的不是配置而是延迟窗口：用户刚提交完表单立刻刷新，看到的可能还是从库里的旧数据。对展示型数据这可以接受，对刚提交就要看到结果的场景则必须强制读主库。常见的做法是把一致性要求高的查询标记出来，走主库连接，其余的走从库池。

另一个容易被忽略的点是连接池放在哪一侧。如果接口服务和数据库在同一机房，连接池可以放在应用侧；如果跨机房，连接池放在应用侧会让每次建立连接的握手时间叠加在每一次查询上，连接池越大越慢，这时反而应该让应用直连或者在数据库前面加一层本地代理。

六、限流、缓存与异步：把峰值削平的三板斧

并发估算再准也挡不住调用方的意外行为，所以真正的防线是限流。令牌桶是最常用的模型：按固定速率往桶里放令牌，请求进来先取一个，取不到就拒绝或排队。拒绝比排队更适合接口场景，因为排队会把上游的超时传导成雪崩，而快速失败让客户端自己决定降级还是重试。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

缓存解决的是重复计算，不是并发。Redis 缓存一个热门列表接口，可以把数据库压力砍掉八成以上，前提是缓存键设计合理并且有失效策略。缓存最常见的两个坑是击穿和雪崩：击穿是某个热点键突然过期，大量请求同时打到数据库；雪崩是一批键在同一时刻集体过期。两种情况的解法一样，给过期时间加随机抖动，并且在热点键失效时用互斥锁只放一个请求去回源。

# Nginx 层按接口限速：每秒 100 个请求，超过的排队等待
limit_req_zone $binary_remote_addr zone=api_zone:10m rate=100r/s;
server {
    location /v1/ {
        limit_req zone=api_zone burst=200 nodelay;
        proxy_pass http://127.0.0.1:8080;
    }
}

# 给缓存键加随机过期时间，避免同一刻集体失效
python3 - <<'PY'
import random, time
base = 300
ttl = base + random.randint(0, 120)
print(f"ttl={ttl}")
PY

# 用 redis-cli 看缓存命中与未命中
redis-cli --hotkeys
redis-cli info stats | grep keyspace

异步是最后一道防线。把耗时的写操作、通知、报表从同步链路里摘出去，改成写入队列后立刻返回受理成功，接口 P99 就能压到几毫秒。代价是业务上要接受最终一致，以及一个必须有人维护的队列组件。如果你的接口是同步写入且不能容忍延迟，异步这条路就堵死，那只能在数据库和机器规格上找答案。

限流还有一个维度是按什么维度限。最简单的是按来源 IP 限，适合防刷；按调用方应用标识限，适合做多租户的配额；按用户限，适合保护单用户的后台操作。真正实用的做法是分层：入口层按 IP 做粗粒度防刷，服务层按调用方做配额，接口层按具体路由设更严格的阈值，这样既不会误伤正常的大客户，也不会让单个来源打满全站。

限流的拒绝方式也要选好。直接返回 429 加一个 Retry-After 头是最标准的做法，客户端读到之后会自己退避；返回 503 会被很多客户端当成服务端故障从而立刻重试，反而加剧拥塞。

七、监控盯哪些指标：不监控就是在猜

接口监控的骨架是四个黄金信号加一层业务指标。四个黄金信号是延迟、流量、错误、饱和度，任何一个异常都能从这四个维度找到线索。延迟一定要分位数，单独看平均值会掩盖长尾；流量看请求速率和响应体大小；错误要按状态码和异常类型分类统计，5xx 和 4xx 的处理逻辑完全不同；饱和度盯 CPU、内存、连接数、队列长度和文件描述符。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

业务指标是接口和网页最大的区别。网页的监控是看 PV 和 UV，接口的监控是看成功率、调用方分布、单调用方错误率突增和鉴权失败次数。有一次真实事故就是某个调用方升级了 SDK，参数格式从驼峰改成下划线，接口返回 400，但成功率和总体流量曲线几乎没变化，只有按调用方维度拆开才看出来。这类问题在通用监控里是隐形的。

# 导出接口耗时分布，自己算分位数
awk '{print $1, $NF}' access.log | sort -n | awk '
{a[NR]=$1}
END{
  print "p50="a[int(NR*0.5)];
  print "p90="a[int(NR*0.9)];
  print "p99="a[int(NR*0.99)];
}'

# 看连接与文件描述符是否接近上限
ss -s
ls /proc/$(pgrep -f "gunicorn|uvicorn" | head -1)/fd | wc -l
ulimit -n

告警阈值不要挂在 CPU 上。CPU 到百分之九十可能只是业务正常变忙，接口真正出问题的信号是 P99 延迟越过了服务目标、错误率超过了约定值、以及队列长度持续增长。用服务目标驱动告警，比用资源阈值驱动告警更接近用户实际感受。

监控数据本身也要控制成本。接口每秒几千条日志，日志量很快就会把磁盘吃满，进而影响服务本身。常见的做法是采样加聚合：常规请求按比例采样，错误请求全量保留，另外把耗时、状态码、调用方这些字段聚合成按分钟的时间桶存进时序库，需要的时候再回查原始日志。原始日志保留期通常设在一到两周，聚合数据保留一年以上。

采集代理本身也是单点。很多团队在采集端丢数据却毫无察觉，直到出事回溯时才发现关键时段根本没有指标。监控链路的可靠性需要单独验证：故意触发一次已知错误，确认告警真的能到达值班人的手机，而不是只出现在仪表盘上。

八、成本模型：并发涨十倍，账单涨几倍

接口的成本可以拆成三块：机器固定成本、出口流量成本、以及超出套餐后的附加费或者突发计费。机器成本随并发近似线性增长，但会随着优化而摊薄；流量成本由调用方总次数乘以平均响应体积决定，和并发无关；超额的计费方式往往才是账单失控的主因。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

估算方法是这样的：先统计月度总调用次数和平均响应体大小，两者相乘得到出口流量估算值，再对照套餐包含的流量包算出超出部分。举例，一个月一千万次调用、平均响应体四 KB，出口流量约四十 GB，这个量级在多数套餐里都还在包含范围内。反过来，如果单次响应体是一百 KB，同样的调用次数就是接近一千 GB，成本结构完全不同。

具体的套餐报价各家差异很大且变动频繁，一律以官网当日报价为准。可供对比的公开商家定位大致是这样：DigitalOcean 面向开发者与中小企业，页面可自选配置、按小时计费且带快照与防火墙等附加组件；RackNerd 主打 KVM VPS 与 AI VPS，覆盖二十个数据中心，常年有一批特价促销机型；CloudCone 同时做云实例与独立服务器，管理面板可直接按 CPU 内存磁盘下单；Interserver 做云与裸机，另有托管、GPU 与硬件托管业务；ITLDC 提供多个全球机房的 NVMe 与 HDD 虚拟服务器；Hostwinds 覆盖虚拟主机、VPS、云服务器与独立服务器；iWebFusion 做共享主机、VPS、主机商与独立服务器并提供全年支持；SpinServers 面向美国市场的即时与独立服务器；Zenlayer 侧重分布式云与全球网络加速；JUSTG 提供东京、首尔、莫斯科等地的云服务器与原生 IPv4。

注意这些是商家的公开定位，不是对你的场景的推荐。真正的选择要在同一张表上比较四项：同样预算下的可用内存与磁盘、目标用户所在区域的机房覆盖、出口流量单价与超额规则、以及工单响应速度。工单响应速度在接口场景里权重很高，出故障时没人回工单等于停机。

买机器时的三条实操技巧。第一，优先选可以按小时调整或者随时升级套餐的产品，因为接口业务的量在早期很难预测，买了超配的机器闲置是纯浪费。第二，确认商家是否支持快照或者自定义镜像，接口发布需要灰度和回滚，快照加自定义镜像是最快的回滚手段，比重新装环境可靠得多。第三，注意续费价和首购价的关系，有些商家的首购折扣很大而续费原价，采购时就要按续费价做长期预算。

还要考虑一个隐形成本：自己运维一台机器的时间成本。从系统加固、内核参数调优、监控接入到故障排查，一个人的时间摊进去，每台机器每月可能花掉几小时。如果接口只有一两个、规模也不大，找有代运维服务的商家反而更划算；机器超过十台之后，自建加自动化的成本优势才会真正体现出来。

九、常见误区与踩坑复盘

第一个误区是按 QPS 买机器。业务方报来一个峰值一千 QPS，运维直接照着配，结果上线才发现单请求要六十毫秒 CPU，平均并发其实是六十而不是想象中的一千。规格要按 CPU 时间算，不是按请求条数算。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

第二个误区是只测平均延迟。压测时平均 25 毫秒就宣布验收通过，上线后用户体验到的是偶尔三秒。必须看 P95 和 P99，而且要在真实数据量下测，空库跑出来的数字没有参考价值。

第三个误区是缓存没有失效策略。上线时 TTL 设成一小时，看起来一切正常；一小时后某个瞬间数据库被打满，连接池耗尽，整个接口全线不可用。缓存必须有过期抖动和热点保护。

第四个误区是忽略上游重试。客户端超时设成三秒，服务端 P99 是两秒，客户端判定失败后立刻重试，重试又制造新的拥塞，最终把一个轻微的抖动放大成持续故障。服务端应该比客户端更早放弃。

典型事故还原：
  19:42  某调用方 SDK 升级，参数格式变更，接口开始返回 400
  19:45  成功率从 99.9% 降到 91%，但总量曲线无明显波动，通用告警未触发
  20:10  调用方重试策略触发，错误请求放大五倍，数据库连接池被打满
  20:35  运维按调用方维度查日志才发现参数问题，回滚后恢复
  复盘结论：接口监控必须按调用方维度拆分成功率，且错误率告警要按错误类型分类

第五个误区是把备份和数据库分离当成两件事。数据库分到独立机器上，但备份任务还跑在应用机上，应用机故障时备份也跟着没了。分离要分离到独立的失败域，备份要有异地副本并定期演练恢复。

第六个误区是全部业务共用一套配置。一个面向外部客户的公开接口和一个内部管理接口跑在同一批进程上，公开接口的流量高峰会把内部接口一起拖垮，鉴权日志还会把真正的攻击淹没在噪声里。这两类流量应该拆开，甚至放到不同的机器上。

第七个误区是假设一次迁移是终点。接口上线后每加一个字段、每加一个依赖，都会让原本的估算失效。真正管用的做法是把并发估算和压测变成每次发版的标准动作，尤其是压测要用生产数据量级跑一次，哪怕只跑十分钟。

十、常见问题

API服务器选几核几G才够用？ 先测单请求 CPU 毫秒数，再按平均并发等于 QPS 乘以单请求秒数的公式算并发，然后除以单实例安全并发得到实例数。内存方面，无状态接口每进程预留一百五十到三百 MB 即可，进程数乘以这个数字再加三成余量就是内存需求。有状态会话、连接池或者本地缓存占用的地方要单独加出来。

接口延迟高，到底该升配还是该优化？ 先看延迟构成。用 curl 拆出 DNS、握手、TTFB 和总时长，如果 TTFB 占总时长的大头，说明问题在服务端，再去查慢查询和连接池；如果握手占了大头，那是连接复用的问题，升配没用；如果跨机房的数据库往返是大头，把数据库挪回同机房或者加缓存收益远大于升配。

峰值几秒就挂掉，正常时很流畅，这是什么问题？ 这是资源在峰值被瞬间打满的典型表现，几乎每次都是队列或连接池在峰值时排队。短期靠限流加队列长度告警兜住，长期要按峰值并发乘以二到三倍来规划余量。

要不要用无服务器架构代替 VPS？ 无服务器适合调用量波动极大、每次执行时间短、且能接受冷启动的场景。它的成本模型按调用次数和执行时长计费，接口量巨大时反而比常驻机器贵，而且冷启动在高频调用下会持续增加尾延迟。常驻接口用 VPS 反而更省也更可控，具体单价以各家官网当日报价为准。

数据库独立部署后接口变慢了怎么办？ 几乎一定是网络往返增加了。原来同机的查询是零点几毫秒，挪到独立机器后变成几毫秒甚至几十毫秒，一次业务链路有十次查询就被放大十倍。处理方式是减少查询次数、把热点数据缓存到 Redis、给数据库和接口同机房部署、必要时在应用侧做批量查询合并。

怎么确认商家给的配置是真的？ 用 fio 测磁盘、用 hey 或 wrk 测并发承载、用 mtr 看路由丢包、用 curl 看分段耗时。页面上的标称值只能当起点，而且要在业务高峰和低谷各测一轮，两轮结果常常相反。