16GB机器部署的简单GET API并发承载能力及故障表现咨询

没有绝对精准的固定数值，实际承载能力和选用的服务框架、网络模型、系统内核参数、进程配置强相关，但可以基于你说的「16GB内存机器、接口仅对GET请求返回hello」的极简场景给出通用量级参考：

• 异步非阻塞类服务（Nginx直接返回静态响应、Go原生HTTP服务、Rust的axum/actix-web、调优后的Node.js服务），在不挂载多余中间件、关闭冗余debug日志的前提下，单机QPS（每秒处理请求数）通常可以达到5万_{20万，长连接场景下支持的并发连接数可到10万}50万级别。这个场景下16GB内存完全不是瓶颈——单个请求处理仅占几KB到几十KB内存，哪怕10万并发连接总内存占用也才几百MB，瓶颈基本在网卡吞吐、CPU中断处理、TCP内核参数配置上。
• 同步阻塞类服务（默认配置的Flask、未调优的Spring Boot Tomcat模式），默认参数下QPS大概在数千到2万区间，并发承载能力从数百到数千不等；调大工作进程/线程数、优化参数后QPS也能摸到几万的水平，内存依然不会成为核心限制。

并发过载后的典型故障现象 #

服务过载故障是随负载升高逐步出现的，不会直接跳转到宕机状态：

• 负载刚超过处理阈值时，多余请求会先在TCP半连接/全连接队列、服务框架的内置请求队列中排队，排队时长超过客户端或网关设置的超时阈值后，就会触发请求超时，此时服务进程仍在正常运行，仅表现为CPU使用率打满、系统负载升高，内存占用无明显异常。
• 负载持续升高且未配置限流保护时，排队请求不断堆积，服务进程内存占用随队列长度上涨持续升高，带垃圾回收的语言会出现频繁GC、系统swap空间被占满，此时接口响应延迟会从毫秒级涨到秒级甚至数十秒，除了大量请求超时外，连SSH登录机器操作都会出现明显卡顿。
• 极端过载且无任何过载保护时，系统会触发OOM Killer强占内存杀掉服务进程，严重时会触发内核资源耗尽panic，最终出现机器宕机、所有请求完全无法响应的情况。

注：生产环境部署的服务一般都会配置限流、熔断、过载保护逻辑，几乎不会出现负载高到机器宕机的情况，上述宕机场景仅在无任何保护、极限压测的前提下才会出现。

内容的提问来源于stack exchange，提问作者stk1234