wordpress网站没有阅读量/短视频营销推广

WebFlux优缺点

【来源DeepSeek】

Spring WebFlux 是 Spring 框架提供的响应式编程模型，旨在支持非阻塞、异步和高并发的应用场景。其优缺点如下：

---

优点

1. 高并发与低资源消耗

   • 非阻塞 I/O：基于事件循环模型（如 Netty），使用少量线程处理大量并发请求，避免传统阻塞式模型中的线程上下文切换开销。

   • 资源高效：适合处理大量长连接或延迟敏感型请求（如实时通信、流处理），减少内存和 CPU 的消耗。

2. 响应式编程模型

   • 背压（Backpressure）支持：通过 Reactive Streams 规范（如 Project Reactor）实现流量控制，防止生产者压垮消费者。

   • 函数式编程风格：提供声明式 API（如 RouterFunction），简化异步逻辑的编写。

3. 可扩展性

   • 适合微服务架构，能够高效处理服务间的异步通信（如结合 WebClient 调用其他服务）。

4. 兼容性

   • 支持与传统的 Spring MVC 共存，允许逐步迁移到响应式架构。

   • 适配多种服务器（Netty、Undertow、Servlet 3.1+ 容器）。

---

缺点

1. 复杂度高

   • 学习曲线陡峭：响应式编程需要理解 Flux、Mono、操作符链式调用等概念，调试和错误处理较困难。

   • 代码可读性差：链式调用和异步逻辑可能导致代码难以维护。

2. 生态兼容性有限

   • 阻塞式库不兼容：大多数传统库（如 JDBC、JPA）是阻塞的，需改用响应式驱动（如 R2DBC、MongoDB Reactive）。

   • 中间件支持不足：部分框架或工具（如 Spring Security）对响应式的支持尚未完全成熟。

3. 适用场景受限

   • CPU 密集型任务不适用：非阻塞模型对计算密集型操作无优势，甚至可能因线程竞争导致性能下降。

   • 简单业务场景性价比低：对低并发、简单 CRUD 应用，传统 MVC 更易开发和维护。

4. 调试与监控困难

   • 异步堆栈信息不直观，需依赖专业工具（如 Reactor Debug Agent）定位问题。

   • 传统监控工具（如 Spring Actuator）可能无法直接适配响应式链路。

---

适用场景

• 高并发 I/O 密集型服务：如 API 网关、实时消息推送、流处理。

• 微服务间异步通信：需要高效处理大量并发请求的场景。

• 延迟敏感型应用：如实时数据分析或金融交易系统。

---

总结

• 选择 WebFlux 的条件：需要处理高并发、非阻塞 I/O，且团队熟悉响应式编程。

• 避免 WebFlux 的情况：业务逻辑简单、依赖传统阻塞库，或团队缺乏响应式经验。

实践证明，使用WebFlux开发接口能够大幅提升接口的吞吐量。

相关参数：

• 测试机器：Linux CentOS6.5 4核16G
• SpringBoot版本：2.2.2.RELEASE
• JDK版本：jdk1.8.0_151

本文主要内容如下：

1. 使用tomcat容器的代码演示
2. 使用netty容器的代码演示
3. apachebench(ab)压测接口，对比性能数据

文中代码较多，建议大家收藏后，有时间自己亲自动手开发并压测来验证结果。

tomcat容器下的代码演示

我们先基于tomcat容器来验证传统的SpringMVC以及基于Project Reactor两种方式开发接口的区别。

先来迅速搭建一个基于SpringBoot-2.2.2.RELEASE版本的demo项目，pom.xml核心依赖如下：

SpringBoot父级依赖

web依赖&project reactor依赖

项目启动类：

再定义一个传统的service，为模拟真实环境请求，service下的方法请求耗时100ms：

模拟耗时100ms

最后我们写三个接口，每个接口采用不同的方式：

1. 使用自定义调度器的方式
2. 使用缓存的弹性调度器
3. 传统的SpringMVC方式

代码如下图所示：

三种接口开发方式

ab压测

我们先对上面说的三个接口进行压测，为避免网络环境影响，我们直接在服务器上使用ab进行压力测试。

压测分三组，每组压测这三个接口，每个接口发起10w请求，每组用户数分别为200、500、1000，从而查看不同用户数请求下的响应结果。

第一组

压测结果：

10w请求数 200用户

可以看见传统的SpringMVC方式已经有阻塞了，最长的一次请求1107ms，但是整体性能基本一致，因为200个线程刚好是tomcat的线程池最大默认数。

第二组

ab -n100000 -c500 http://127.0.0.1:8080/hello1?id=1
ab -n100000 -c500 http://127.0.0.1:8080/hello2?id=1
ab -n100000 -c500 http://127.0.0.1:8080/hello3?id=1

压测结果：

10w请求 500用户

500用户请求时候可以看到hello3接口的响应时间已经是hello1和hello2两个接口响应时间的2倍以上了，但是基于project reactor响应编程开发方式的响应时间依旧和200用户一致。

我们继续将用户数加到1000。

第三组

ab -n100000 -c1000 http://127.0.0.1:8080/hello1?id=1
ab -n100000 -c1000 http://127.0.0.1:8080/hello2?id=1
ab -n100000 -c1000 http://127.0.0.1:8080/hello3?id=1

压测结果：

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?id=1
ab -n100000 -c1000 http://127.0.0.1:8080/hello2?id=1
ab -n100000 -c1000 http://127.0.0.1:8080/hello3?id=1

压测结果：

netty下压测10w请求1000用户

再和tomcat下同一压测参数进行对比：

tomcat下压测10w请求1000用户

是不是发现netty的性能比tomcat更加优越？99%的请求在149ms即可完成。如果大家自己实操的话也会发现吞吐量也会较tomcat有大幅度的提升。

总结

我们始终都在不遗余力的追求如何开发一个高并发、低延迟的接口。

通过本文实操以及linux服务器下长时间的压测，可以验证的是我们可以使用WebFlux来替代SpringMVC，从而获取更好的性能，更高的并发。如果你还和我一样，对WebFlux还一知半解，那么从今天起开始学习起来吧。