湖州建设局招投标网站,深圳广告公司集中在哪里,网站后台链接怎么做,wordpress cosy主题WebFlux优缺点
【来源DeepSeek】
Spring WebFlux 是 Spring 框架提供的响应式编程模型#xff0c;旨在支持非阻塞、异步和高并发的应用场景。其优缺点如下#xff1a; 优点 高并发与低资源消耗 非阻塞 I/O#xff1a;基于事件循环模型#xff08;如 Netty#xff09;旨在支持非阻塞、异步和高并发的应用场景。其优缺点如下 优点 高并发与低资源消耗 非阻塞 I/O基于事件循环模型如 Netty使用少量线程处理大量并发请求避免传统阻塞式模型中的线程上下文切换开销。 资源高效适合处理大量长连接或延迟敏感型请求如实时通信、流处理减少内存和 CPU 的消耗。 响应式编程模型 背压Backpressure支持通过 Reactive Streams 规范如 Project Reactor实现流量控制防止生产者压垮消费者。 函数式编程风格提供声明式 API如 RouterFunction简化异步逻辑的编写。 可扩展性 适合微服务架构能够高效处理服务间的异步通信如结合 WebClient 调用其他服务。 兼容性 支持与传统的 Spring MVC 共存允许逐步迁移到响应式架构。 适配多种服务器Netty、Undertow、Servlet 3.1 容器。 缺点 复杂度高 学习曲线陡峭响应式编程需要理解 Flux、Mono、操作符链式调用等概念调试和错误处理较困难。 代码可读性差链式调用和异步逻辑可能导致代码难以维护。 生态兼容性有限 阻塞式库不兼容大多数传统库如 JDBC、JPA是阻塞的需改用响应式驱动如 R2DBC、MongoDB Reactive。 中间件支持不足部分框架或工具如 Spring Security对响应式的支持尚未完全成熟。 适用场景受限 CPU 密集型任务不适用非阻塞模型对计算密集型操作无优势甚至可能因线程竞争导致性能下降。 简单业务场景性价比低对低并发、简单 CRUD 应用传统 MVC 更易开发和维护。 调试与监控困难 异步堆栈信息不直观需依赖专业工具如 Reactor Debug Agent定位问题。 传统监控工具如 Spring Actuator可能无法直接适配响应式链路。 适用场景 高并发 I/O 密集型服务如 API 网关、实时消息推送、流处理。 微服务间异步通信需要高效处理大量并发请求的场景。 延迟敏感型应用如实时数据分析或金融交易系统。 总结 选择 WebFlux 的条件需要处理高并发、非阻塞 I/O且团队熟悉响应式编程。 避免 WebFlux 的情况业务逻辑简单、依赖传统阻塞库或团队缺乏响应式经验。 实践证明使用WebFlux开发接口能够大幅提升接口的吞吐量。
相关参数
测试机器Linux CentOS6.5 4核16GSpringBoot版本2.2.2.RELEASEJDK版本jdk1.8.0_151
本文主要内容如下
使用tomcat容器的代码演示使用netty容器的代码演示apachebench(ab)压测接口对比性能数据
文中代码较多建议大家收藏后有时间自己亲自动手开发并压测来验证结果。 tomcat容器下的代码演示
我们先基于tomcat容器来验证传统的SpringMVC以及基于Project Reactor两种方式开发接口的区别。
先来迅速搭建一个基于SpringBoot-2.2.2.RELEASE版本的demo项目pom.xml核心依赖如下 SpringBoot父级依赖 web依赖project reactor依赖
项目启动类 再定义一个传统的service为模拟真实环境请求service下的方法请求耗时100ms 模拟耗时100ms
最后我们写三个接口每个接口采用不同的方式
使用自定义调度器的方式使用缓存的弹性调度器传统的SpringMVC方式
代码如下图所示 三种接口开发方式
ab压测
我们先对上面说的三个接口进行压测为避免网络环境影响我们直接在服务器上使用ab进行压力测试。
压测分三组每组压测这三个接口每个接口发起10w请求每组用户数分别为200、500、1000从而查看不同用户数请求下的响应结果。
第一组
压测结果 10w请求数 200用户
可以看见传统的SpringMVC方式已经有阻塞了最长的一次请求1107ms但是整体性能基本一致因为200个线程刚好是tomcat的线程池最大默认数。
第二组
ab -n100000 -c500 http://127.0.0.1:8080/hello1?id1
ab -n100000 -c500 http://127.0.0.1:8080/hello2?id1
ab -n100000 -c500 http://127.0.0.1:8080/hello3?id1
压测结果 10w请求 500用户
500用户请求时候可以看到hello3接口的响应时间已经是hello1和hello2两个接口响应时间的2倍以上了但是基于project reactor响应编程开发方式的响应时间依旧和200用户一致。
我们继续将用户数加到1000。
第三组
ab -n100000 -c1000 http://127.0.0.1:8080/hello1?id1
ab -n100000 -c1000 http://127.0.0.1:8080/hello2?id1
ab -n100000 -c1000 http://127.0.0.1:8080/hello3?id1
压测结果 10w请求 1000用户
我们发现基于project reactor开发的接口响应时间依旧坚挺传统SpringMVC方式开发的接口90%响应时间已经高达500ms了。 大家可以发现hello1和hello2两个接口的实现方式其实是一致的无非是自己定义一个Scheduler还是用reactor默认的Scheduler如果大家点进去看源码其实是一个意思所以在性能上一致保持一致也是合理的本质上都是无所不在的线程池 至此我们就完成了在tomcat容器下的两种不同方式的接口开发以及得到相应的性能压测数据。
netty容器下代码演示
将pom.xml中的spring-boot-starter-web依赖换为webflux依赖即可 webflux依赖
还是刚刚那三个接口启动项目可以看到控制台有如下日志输出
代表我们这是一个基于Netty的web服务。
这里我们直接压10w请求1000用户
ab -n100000 -c1000 http://127.0.0.1:8080/hello1?id1
ab -n100000 -c1000 http://127.0.0.1:8080/hello2?id1
ab -n100000 -c1000 http://127.0.0.1:8080/hello3?id1
压测结果 netty下压测10w请求1000用户
再和tomcat下同一压测参数进行对比 tomcat下压测10w请求1000用户
是不是发现netty的性能比tomcat更加优越99%的请求在149ms即可完成。如果大家自己实操的话也会发现吞吐量也会较tomcat有大幅度的提升。
总结
我们始终都在不遗余力的追求如何开发一个高并发、低延迟的接口。
通过本文实操以及linux服务器下长时间的压测可以验证的是我们可以使用WebFlux来替代SpringMVC从而获取更好的性能更高的并发。如果你还和我一样对WebFlux还一知半解那么从今天起开始学习起来吧。
