graphql 出来这么久了我还是没搞懂这是什么，看起来就像一个 API 网关？

Java 上 vertx 试试，或者看这里现成的结果。
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db

不是公认码农门槛低么，既然是电子商务应该直接学量化交易之类的吧？

已经是后端了，就选 py 啦。不过我也推荐 rust 就是了。

具体场景具体做吧，把多种数据分开多个接口，一般是复用性高的接口吧。
单次请求一个聚合数据往往是那些小数据其他地方用不上的时候吧。
不过其实聚合数据接口和分散的数据接口都提供问题也行呀。

只允许内网访问可以在 Nginx 限制一下仅内网 IP 吧。

与其说复杂，不如说为这个库做得这么简单，

某种意义上还真是有生之年，公司万年不升级的 jdk

如果还是万年不升级 JDK 的话，会！
面对如此情况，人们还是更愿意选择没包袱的语言，久而久之国内的 Java 环境就越来越惨淡。
如果是紧跟着新的 Java 走的话，Java 还是很有活力的，已经把开始吸收其他语言的优点了。

tomcat 那种一个请求一条线程而且还是 BIO 弄高并发就是无限堆机器(当然也有 nio 模式)。
真正要搞高并发必须要考虑 io 多路复用了，用 event-loop 异步模型代替。

我猜你指的是 spring-web(springMVC)。spring boot 本质一堆 auto configuration，其实你用的还是 spring，使用 spring boot 只不过是简化你整合 spring 全家桶的过程。

既然会 golang 了何必折腾 Java，混的 spring 群不少人说要去转 go 呢，真的是围城。

vertx+3

@liuzhiyong 其实 Java 的 aot 已经在搞了，迟点就有机会用上了。 关键词：graalVM

@notreami 还有更前沿的把 servlet 容器都丢了，基于 netty 做开发。
例如 vert.x

@murmur 算役还好，写算符才蛋疼，当你写好算符的时候差不多就是写了半个游戏逻辑了。

@aoscici2000
这是 tomcat 只开一个线程，另外一个 worker 线程是 10 个的情况，
由日志可以看出，同时提交 5 个请求，异步的操作是 5 秒后才返回 response。
并不存在你描述的问题，所以你确认你的测试是正确的吗？

@aoscici2000 看起来你的 35 和 42 就相差了 5 秒，确定你的测试用例正确么。

@aoscici2000 max-threads=1 意味着只有一个线程处理请求，那么同时来 2 个请求的时候，如果使用你之前用的 future 就会阻塞了这唯一一条线程，结果就是 2 个请求合计使用了 10 秒。但使用 CompletableFuture + DeferredResult 时，2 个请求进来了，第一个请求直接返回了 defer 随意该线程已经完成了第一个请求了，接下来就会直接处理第二个请求。而 CompletableFuture 则是在另外一个线程池执行，当他完成时就返回给用户，于是这时的结果是两个请求合计使用 5 秒多一点时间（取决于你 CompletableFuture 的线程池大小，默认是 CPU-1，如果=1 时，也是需要 10 秒了）