尧图精选

Servlet 栈 vs WebFlux 栈:请求穿过哪些层

🕒 发布时间:2026/10/2 20:10:30 📁 来源:尧图网络
Filter、Interceptor、AOP 谁先执行跟着请求走一遍看到这篇文章让我想到了文章里讲的Filter 属于 Servlet 规范由 Tomcat 调用跑在 DispatcherServlet 之前所以在最外层连静态资源的请求都会经过它。Interceptor 属于 Spring MVC由 DispatcherServlet 找到处理器之后调用。AOP 是 Spring 的代理机制作用在 Controller 方法的调用上贴得最近。延伸一下就到了 Servlet 栈Spring MVCWebFlux 栈Spring WebFlux。Servlet 栈Spring MVC┌─────────────────────────────────────────────────────────────┐ │ Client Request │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Web Container (Tomcat/Jetty) │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ Filter Chain (javax.servlet.Filter) │ │ │ │ Filter1 → Filter2 → ... → FilterN │ │ │ └───────────────────────────┬───────────────────────────┘ │ │ ▼ │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ DispatcherServlet │ │ │ │ ① HandlerMapping → 找到 HandlerMethod │ │ │ │ ② HandlerAdapter → 调用 Controller │ │ │ │ ③ HandlerInterceptor.preHandle() ◀── 注意这里 │ │ │ │ ④ 执行 Controller 方法 │ │ │ │ ⑤ HandlerInterceptor.postHandle() ◀── 注意这里 │ │ │ │ ⑥ 渲染视图 / 写响应 │ │ │ │ ⑦ HandlerInterceptor.afterCompletion() ◀── 注意 │ │ │ └───────────────────────────┬───────────────────────────┘ │ │ ▼ │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ HttpServletResponse (阻塞式输出) │ │ │ └───────────────────────────┬───────────────────────────┘ │ └──────────────────────────────┼──────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Client Response │ └─────────────────────────────────────────────────────────────┘关键特征Filter 是 Servlet 规范定义的Interceptor 是 Spring MVC 框架自己加的。WebFlux 栈Spring WebFlux┌─────────────────────────────────────────────────────────────┐ │ Client Request │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Reactive Server (Netty / Undertow / Servlet3.1) │ │ 没有统一容器规范各服务器私有 API │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ HttpHandler (Spring 适配层屏蔽服务器差异) │ │ ServerHttpRequest ServerHttpResponse → MonoVoid │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ WebFilter Chain (org.springframework.web.server.) │ │ WebFilter1 → WebFilter2 → ... → WebFilterN │ │ 对应 Servlet Filter但是返回 MonoVoid响应式 │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ DispatcherHandler │ │ ① HandlerMapping → 找到 handler不一定是 Method │ │ ② HandlerAdapter → 调用 handler │ │ ③ 没有 HandlerInterceptor │ │ ├── 前置逻辑 → 写在 WebFilter 里 │ │ ├── 后置逻辑 → 写在 WebFilter 里或 doOnSuccess │ │ └── 异常处理 → WebFilter 的 onErrorResume │ │ ④ Controller 返回 Mono / Flux │ │ ⑤ HandlerResultHandler → 序列化并写响应 │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ ServerHttpResponse非阻塞、背压感知、流式写入 │ └─────────────────────────────┬───────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Client Response │ └─────────────────────────────────────────────────────────────┘关键特征没有 Filter 规范、没有 Interceptor一切靠WebFilterMono操作符链。逐层对照表层次Servlet / Spring MVCWebFlux / Reactive规范层​Servlet规范 (Jakarta EE)无容器规范只有Reactive Streams服务器​Tomcat / Jetty (Servlet 模式)Netty / Undertow / Tomcat(3.1 NIO)服务器→框架适配​Servlet API 直接对接HttpHandler适配层全局前置/后置​javax.servlet.Filterorg.springframework.web.server.WebFilter中央调度器​DispatcherServletDispatcherHandler路由/映射​HandlerMapping→HandlerMethodHandlerMapping→ 任意 handler处理器前后拦截​✅HandlerInterceptor(3个回调)❌ 没有用WebFilter或Mono操作符参数解析/返回值处理​HandlerMethodArgumentResolver/HandlerMethodReturnValueHandlerHandlerAdapterHandlerResultHandler响应写入​HttpServletResponse(阻塞)ServerHttpResponse(非阻塞 背压)异常处理​ExceptionHandler/HandlerExceptionResolverExceptionHandler/WebExceptionHandler一句话总结差异本质Servlet 栈 规范定义容器 → 容器定义 Filter → 框架加 Interceptor → 阻塞 I/OWebFlux 栈 无容器规范 → 框架自己适配服务器 → 只有 WebFilter → 响应式流 背压三者Undertow / Jetty / Tomcat在 WebFlux 下的真实定位服务器WebFlux 使用方式非阻塞纯度说明Netty​Reactor Netty 直连最高EventLoop 全链路响应式WebFlux 默认Undertow​Undertow API 直连非 Servlet高XNIO 事件模型适合响应式轻量Jetty​Servlet 3.1 NIO 适配中能跑但走 Servlet 非阻塞桥Tomcat​Servlet 3.1 NIO 适配中同上线程池模型偏传统Netty是响应式最好的Undertow次之其他的servlet容器最差。Undertow 严格说不算次之而是和 Netty 同一档但生态弱一截——它走的是 XNIO 事件模型不是 Servlet 适配非阻塞纯度其实很高。只是 Reactor Netty 跟 Spring WebFlux 是同一个团队reactor 项目出的磨合最好、文档最全、踩坑最少。Tomcat/Jetty 不是差是定位不同——它们本来就是为 Servlet 同步模型设计的响应式是后来硬桥上去的。能跑但线程模型、内存占用、长连接表现都拼不过原生响应式底座。所以更准确的说法是Netty ≈ Undertow原生响应式底座 Tomcat ≈ JettyServlet 适配桥接选谁就看你场景——新项目无历史包袱直接 Netty已有 Undertow 技术栈直接上 WebFlux 完全没问题老项目想试水响应式又不想换容器Tomcat/Jetty 也能跑别指望性能飞跃就行。
上一篇/下一篇内容由系统自动关联 返回资讯列表 →