Tomcat 挂了。间件

凌晨两点，间件运维群里蹦出这条消息。间件我爬起来连上 VPN，间件看到日志里一片 502。间件Nginx 还在，间件但后面的间件 Tomcat 实例全部无响应。重启之后恢复，间件第二天查原因——某个接口的间件慢查询把线程池打满了。这就是间件 WEB 中间件最真实的一面：平时你感觉不到它存在，出问题的间件时候，整个系统跟着一起躺。间件

很多人把 WEB 中间件等同于 Nginx 或者 Tomcat，间件其实它是间件一整条链路。从用户敲下 URL 那一刻起，间件请求先到负载均衡层（可能是 LVS 或 F5），再到反向代理层（Nginx、HAProxy），然后进入应用服务器（Tomcat、Jetty、Undertow），最后才碰到你的业务代码。每一层都有自己的脾气。

拿 Nginx 来说，它的 worker 进程模型决定了它特别能扛并发。我见过一台 4 核 8G 的机器跑 Nginx，静态文件 QPS 冲到 3 万还没什么压力。但如果你拿它做动态代理，配置不当就会出事。有个项目图省事，把 proxy_pass 的超时时间设成了 60 秒，结果后端某个接口卡住，Nginx 的 worker 连接数被占满，整个站点跟着不可用。后来改成 3 秒，加上重试机制，才算稳住。

Tomcat 的坑更隐蔽。默认配置下，maxThreads 是 200。听起来不少，但如果你的接口平均响应 500ms，那理论吞吐量也就 400 QPS。一旦流量涨上来，请求排队，线程池满了之后新请求直接被拒绝。更麻烦的是，Tomcat 的 acceptCount 默认是 100，队列满了之后操作系统层面还会拒绝连接。用户看到的就是连接超时，连 502 都拿不到。

Jetty 和 Undertow 这几年在 Spring Boot 项目里越来越常见。Undertow 的性能确实好，内存占用也低，但它的配置方式和 Tomcat 差别不小。有一次我把一个项目从 Tomcat 切到 Undertow，压测时发现吞吐量反而下降了。查了半天，是 Undertow 的 io-threads 和 worker-threads 没调对。默认值在低配机器上够用，在高并发场景下就是瓶颈。

中间件的选型没有绝对的对错。Nginx 做反向代理几乎是标配，但如果你需要更复杂的流量治理，比如灰度发布、熔断限流，可能得上 APISIX 或者 Envoy。Tomcat 稳定、生态好，但启动慢、内存占用高。Undertow 轻量，但文档和社区案例少一些。关键看你的团队能不能 hold 住。

我自己的习惯是：任何中间件上线前，先做一轮基准测试。用 wrk 或者 JMeter 打一遍，看看默认配置下的极限在哪里。然后根据业务的实际 QPS 和响应时间，留出至少 50% 的余量。别等到线上出事了再调参数，那时候每一秒都是钱。

还有一点容易被忽略：中间件的日志。Nginx 的 access log 和 error log 分开配，Tomcat 的 catalina.out 要定期切割。我见过一个项目，catalina.out 涨到 20 多个 G，磁盘满了导致整个服务挂掉。这种问题不复杂，但就是没人管。

WEB 中间件不像业务代码那样天天改，但它决定了系统的下限。下限守不住，上限再高也没用。

(责任编辑：休闲)