PlayFramework高并发REST API调用场景下服务崩溃排查

Play默认负载处理机制的认知偏差 #

• Play 2.x 版本默认基于Akka HTTP（旧版为Netty）实现异步请求处理，开箱状态不具备自动的过载排队保护：默认使用无界邮箱队列存储待处理请求，没有硬队列长度限制，请求处理线程池默认和CPU核数绑定。当请求量超过处理阈值时，超额请求不会被框架主动阻塞或快速拒绝，会持续堆积在无界队列中，最终占满所有处理线程、耗尽内存，此时包括K8s liveness、readiness探针在内的所有请求都抢不到处理线程，直接超时，和你观察到的停掉上游就恢复、无业务异常日志的现象完全匹配——这类故障发生时请求根本没走到业务处理逻辑，自然不会产生业务层面的报错。
• 你预期的"超额请求自动阻塞/拒绝"是Spring MVC+Tomcat这类同步阻塞框架的默认行为，Play作为异步框架默认没有该逻辑，属于非常常见的生产踩坑点。
• 上游配置的重试逻辑会在该场景下放大故障：请求卡在服务端队列中超时后，上游重试会继续向已经堆满的队列追加新请求，形成雪崩效应。

必做的高负载配置补全 #

在服务的application.conf中添加以下配置，即可实现你预期的过载快速失败、不堆积请求的效果：

# 基础请求超时配置
play.server.akka.requestTimeout = 10s
# 服务端最大连接数限制，根据自身服务压测结果调整
play.server.akka.max-connections = 200
play.server.akka.pipelining-limit = 32
# 将默认 dispatcher 的无界邮箱改为有界队列，队列满直接快速失败
akka.actor.default-dispatcher {
  mailbox-requirements = "akka.dispatch.BoundedMailbox"
  mailbox-capacity = 100 # 单线程队列长度，根据压测结果调优
  mailbox-push-timeout-time = 0ms # 队列满时不等待，直接拒绝请求
}

• 额外注意：如果业务逻辑中存在阻塞操作（JDBC调用、同步第三方HTTP调用、本地文件IO等），必须将这类操作调度到独立的专用阻塞线程池执行，绝对不能占用Play默认的核心异步处理线程池，否则即使请求量不高，核心线程被阻塞后一样会出现服务假死、探针超时的问题，这是Play微服务最高发的生产故障诱因。

K8s环境配套排查点 #

• 健康检查端点配置：优先使用Play 2.8+ 自带的/status轻量健康端点做探针，不要在健康检查接口中添加数据库、下游服务依赖检查这类重逻辑，避免探针请求和业务请求争抢线程资源，高负载下被堵在队列中导致误判。
• 资源节流排查：检查Pod的CPU limits配置，高负载下重点观测container_cpu_cfs_throttled_seconds_total指标，如果该值持续升高，说明CPU被CFS节流，会直接导致Akka线程调度延迟飙升，触发探针超时，可临时调大CPU limits或移除CPU limits验证。
• 连接资源排查：高负载触发故障时，进Pod查看/proc/sys/fs/file-nr确认文件句柄占用是否接近上限，排查是否存在短连接未复用导致的连接数耗尽问题。

验证方法 #

• 直接使用压测工具（wrk、hey等）对服务A施压，压到历史故障触发的QPS阈值，确认是否复现无报错、探针超时的现象；配置完上述参数后再次压测，验证过载时是否直接返回503快速失败，服务本身保持稳定不崩溃。
• 故障复现后不要立即重启Pod，先执行jstack <服务进程PID>导出线程栈，可直接确认是核心线程被阻塞操作占满，还是请求队列堆积导致的资源耗尽。

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