Nginx\Tomcat\Jetty\Netty

Nginx高性能 HTTP 服务器 / 代理大门接收请求、转发、负载均衡、静态资源、高并发纯异步非阻塞 多进程1 个 master 多个 worker一个线程能扛几万并发整体能抗~10WQps只负责接收请求 → 转发 → 返回结果TomcatJava Web 容器运行 Spring Boot、Java Web、Servlet、接口服务。支持 BIO / NIO / APR默认 NIO异步非阻塞专门执行Servlet / Spring MVC业务逻辑既要处理网络又要跑业务代码扛几百几千并发受业务影响和jetty都是一个请求绑定一个工作线程servlet threadJetty轻量级 Java Web 容器微服务、嵌入式、云原生、小内存环境架构比 Tomcat 简单默认 NIO 异步非阻塞嵌入式友好Spring Boot 默认可切换Netty网络通信编程框架自己写网关、MQ、游戏服务器、RPC、自定义协议基于 Java NIO 封装的高性能网络框架主从 Reactor 多线程模型只处理网络连接、读写、编解码不提供 Web 容器功能不能直接跑 Spring MVCRPC 框架Dubbo、gRPC 都用 NettyTomcat NIO 和 Jetty NIO 底层模型完全相同Selector 轮询IO 多路复用Accept 线程 → 接收连接Worker 线程组 → 处理读写请求进入线程池 → 分配一个 servlet 线程业务执行完毕 → 归还线程重点只要是运行 Spring MVC同步 Servlet不管 Tomcat 还是 Jetty都会一个请求占一个线程所以线程模型一样 → 最大并发由线程池大小决定 → 性能接近内存占用Jetty 完胜Jetty 内核极小Jar 只有几百 KB启动内存Jetty 2040MTomcat 启动80150MNetty Spring WebFlux 五大黄金应用场景高并发网关 / API 网关最适合场景 接入层、网关、路由、鉴权、限流、日志、请求转发 每秒几千几万 QPS 大部分时间在等待下游服务响应IO 密集型长连接、高在线量服务IM、推送、聊天室场景WebSocket 长连接在线人数 1 万、10 万、100 万消息推送、实时通知、IM 即时通讯为什么适合Tomcat 一个连接占一个线程1 万连接 1 万线程直接炸Netty 只需 4~8 个线程就能扛 10 万 长连接WebFlux 完美支持 WebSocket 响应式模型IO 密集型微服务大量调用第三方 / DB/HTTP场景服务内部大量远程调用调用第三方接口HTTP、Dubbo、gRPC频繁读写数据库、Redis、MQCPU 空闲线程全在等待为什么适合Spring MVC同步一个请求占一个线程等待时线程闲置WebFlux等待时线程立刻去处理别的请求同样机器配置并发能力提升 310 倍4.高并发、低延迟的核心接口场景秒杀、商品列表、订单查询、用户中心要求低延迟、高并发流量波动大平时低峰值高为什么适合Netty 性能极高异步非阻塞无线程阻塞浪费抗尖峰能力极强5. 流式数据、实时数据处理场景服务端推送SSE日志流、数据流分批返回大量数据WebFlux 天然支持 Flux 流式返回Netty 采用三层架构主 ReactorBoss 线程只负责接收客户端连接从 ReactorWorker 线程只负责读写数据、编解码业务线程池只负责执行业务逻辑Spring MVC tomcat NIO 网络层用NIO 多路复用非阻塞、高效接收连接业务层Worker / Tomcat 线程池处理 Spring MVC 业务同步、阻塞、一个请求一个线程Netty WebFlux 网络层异步非阻塞Netty 业务层异步非阻塞响应式编程 真正的全链路异步非阻塞响应式编程基于数据流 通知回调Reactive Streams 规范响应式流是一套为JVM/JavaScript 平台设计的异步流处理标准核心解决非阻塞 背压Backpressure问题是 Spring WebFlux、Project Reactor、RxJava 等框架的底层基石。数据流Mono / FluxMono0 或 1 个数据单个结果Flux0 ~ N 个数据列表 / 流异步回调订阅才执行链式操作流水线MonoUser userMono reactiveUserDao.getUserById(1L);WebFlux调用 → 注册回调 → 线程离开 → 结果回来再通知1. 响应式 Repository数据库异步非阻塞不能用 JDBC / MyBatis阻塞必须用R2DBC / ReactiveMongo等异步驱动响应式 HTTP 调用WebClient不能用 RestTemplate阻塞必须用WebClient异步非阻塞