有实际使用 SpringWebFlux 的大佬分享下经验吗？

[magese]

孤陋寡闻了，这玩意好像出了挺久了😅；

我是最近在对接 openai api 的时候偶然了解到的，看了下感觉挺有意思的。

有没有实际使用过的大佬来说一下相较于 SpringMVC 有哪些优劣势？是否能够完全平替掉 MVC ？

可以的话我想直接在自己项目来试试水了。

[Leviathann]

I think Project Loom is going to kill reactive programming.

查查说这句话的人是谁

[chendy]

17 年还是 18 年刚出的时候体验过一把，还做过一点简单的测试
个人体验得出的结论：自己学习学习玩无所谓，除非团队技术过硬或者业务足够简单，否则不要在商业项目中尝试
因为这玩意解决的是’用多线程扛高并发线程过多扛不住‘的问题，当时测试，一样的最简单接口，一样的压力，响应时间接近，但是 webflux 的内存使用相当少
代价就是换了个姿势的回调地狱，业务简单还好，业务复杂度套上这玩意的复杂度真的就是杀人级别的存在，没点实力和闲心根本 hold 不住

[yazinnnn0]

不能平替

优势是并发量大, 消耗资源少, 功能强大

劣势是编程模型复杂, 复杂点的业务你要写成 monad 地狱, 虽然并发量大,但是一般业务瓶颈在数据库, 利用不到 reactive 的最大优势

写着玩可以随便试, 用 kotlin 协程可以稍微拯救一下 monad 地狱

loom 也不是银弹, loom 是增强 blocking 的方案, 不是增强 reactive 的方案

[DoctorDeng]

可以学习，学习，没啥特殊需要一般不会使用。我之前的项目也就网关这种需要性能的模块用了。WebFlux 使用成本高，引入 WebFlux 后相关依赖的所有组件都得支持 Reactive 。另外 WebFlux 的代码阅读调试麻烦，不像同步方式那么容易让人理解，最后 WebFlux 使用对开发人员要求较高，用的不好，程序性能搞不好会倒退。

[Wien]

没啥用。20 年的时候项目改造中用过，IO 密集型应用能压榨机器 CPU ，减少内存。

[chrisia]

千万别用 WebFlux ，代码简直就是地狱，学习成本也是巨高，文档基本都是英文，调试麻烦。唯一的好处是装逼。

[cloud107202]

就个人经验，95% 的场景都用途不大，pre-loom 时期 reactive 框架解决的主要是针对 request-per-thread 这种场景造成的线程开销过多问题。

比如说，你的应用恰好是一个并发请求量偏大的场景，下层又恰好是一个可以异步的东西比如某些云数据商的异步 SDK （而非 block JDBC 为主的调用），使用 webflux 是一个合适的选择。除此之外可以说都不太适合，因为引入这套框架在带来一点线程资源开销的节省之外，会引入代码风格的巨变。这很像在 js 工程写一个 async 函数，会从调用点起在整个调用链路上做一个比较大的“类型污染/风格污染”，下层调用也充斥着 Mono<T> / Flux<T> 的情况，个别场景比如针对自己无法改造的 block API 还需要对线程与调度器更深一层理解，在合适的时候通过 publishOn() 函数切换 Scheduler

不久的将来 loom 成熟后，reactive 框架唯一的好处就剩下上一段后半段表述的：一套强类型与显示的声明式逻辑处理链路风格。这个见仁见智，在我的经验下全司几乎所有的后端研发都比较反感这一套东西，其中绝大多数人是因为不懂也不想去理解里面的设计思路。可能有一定 FP 经验接触过比如接触过 scala 里面 ZIO/Cat Effect3 那种 effect system 的人会舒适些

[chrisia]

在我看来这玩意就不适合后端用，一旦使用了整条链路都要返回 Mono/Flux ，看了好多代码比回调地狱还恐怖，一个 Mono 类里面看看有多少个方法，导致我 IDE 智能提示都卡。这种风格前端倒是可以用用。loom 出来这玩意就没啥用了，反人类的东西。

[chrisia]

如果是写网关应用，那 WebFlux 还是有较大的价值。但我为何非要用这套晦涩的东西写网关？

[chrisia]

BTW 我选择 kotlin

[BBCCBB]

放弃这个. 这种玩意儿不是给人用的...

[kuituosi]

主要是网关高并发

[mmdsun]

上家公司全线都是反应式架构设计，连 APP ，前端都是 Rxjava 、Rxjavascript 这种。

目前做的 OpenAI 相关项目也是用的这个 SpringWebflux ，处理 SSE 流相关的太方便了。个人感觉替代 MVC 不是问题。唯一不足就是对程序员要求较高。（其实这个学学函数式编程就行）

[a3mao]

关键是看能力，完全可以替换

[txzh007]

函数式编程对人的要求挺高的,自己写个项目练手挺好的.

[dlmy]

之前使用 WebFlux + Disruptor 编写了一个 Dispatch 程序，其中存在许多问题，且代码难以调试，导致开发效率很低，因此 WebFlux 是很难替换掉 MVC 的。

[flmn]

作为行业标准的 Spring 推 WebFlux 这么多年也没用起来不是没有原因的。

Java 21 出来后，WebFlux 更没有前途了。

[kytrun]

我们在用，小公司，一年开发体验下来只有一个好处：并行调用多个接口比用 CompletableFuture 简洁点

[silentsky]

掌握了响应式编程就没什么难度 一般用下网关

[srx1982]

如果你自己玩可以用，在公司千万别用，学习成本高不说，只要业务稍微有点复杂，多访问几个数据源再加点各种计算之类的，维护成本几何级上升