有谁的公司已经用 WebFlux 替换了 SpringMVC 吗

？那为什么不直接用 java21 ？
Java 的现任 leader 都说了将会杀死 reactive programming 了

java 目前最现实的问题就是：想切换想更新的企业没有预算，有预算的企业不想切换不想升级

用 webflux 超过 3 年了。性能有没有提升不知道，因为是新项目，没有对比。但反应式编程对程序员要求比较高，特别是面对复杂业务逻辑的时候。就跟习惯了命令式编程之后再转函数式编程那样，是思维模式的转换。

尝试过，最后放弃，投入产出比过于低
reactor 这套东西，或者说所有类似的东西，主要是高并发下的资源占用少很多，也就是说，如果 存在高并发 且 希望减少资源使用 的情况下可以尝试，否则完全没有用的必要
另外的问题是，不能用同步语法写的异步都是 xx ，业务逻辑本就盘根错节，再来这么一层 Mono 和 Flux 真的就要命了
系统压力太大扛不住大不了可以加机器，神仙代码出问题找不到神仙解决那是真难受，不是神仙非要学神仙写神仙代码最后一对问题解决不了那是真 xx

在 WebFlux ，Vert.x ，Quarkus 三个响应式框架中做过选择，最终选择了 Vert.x 。

三个都有回调地域的心智负担，当循环+分支+递归时，响应式写法要炸，WebFlux 还是这三个里性能最弱鸡的。

Quarkus 很好，但美中不足的是不支持 reproducible builds ，官方也很不以为意，四五年不解决，所以也放弃了
https://github.com/quarkusio/quarkus/issues/676

Vert.x 非常符合要求，高性能 + 框架简单 + 支持 native image + 支持 Java virtual threads + 支持 Kotlin Coroutine ，为了方便协程式同步写法，早年折腾出 vertx-sync ，后来用上了 quasar ，在 Kotlin 和 Java 的协程出来后也是立马就支持了。

我赞同 1 楼，别研究了 WebFlux ，Virtual Threads 杀死了比赛

用 webflux 开发了网关，性能不知道，但是代码是真的难维护，很看个人的功力，如果业务比较复杂的话，感觉应该挺困难用这个开发的

没有熟悉这块的大佬，不建议重新搞，更不建议上生产环境。这玩意不熟悉的话属于是明知道有 BUG ，明知道哪里问题，但是就是不知道怎么修。

除非你业务真的就是异步的，比如游戏服务器，不然别弄啥反应式。
单纯为了性能，你不如重新学 go 用 go 搞还简单些，更别说现在有 Java21 了。

每一个环节都需要异步，不然的话都会拖垮性能，每个中间件都得支持异步，服务端需要异步，客户端也需要异步

@holulu 不怕招不到人么?

不要用，问题太多
最严重的是各种场景下会发生内存泄露，最新版也无法解决

我们做网关用了几年了，让我重新选，我会选择不用
问题跟上面的兄弟说的一样：
1 ）投入产出低，不能用同步语法写，业务逻辑多了之后要命。减少资源这一特点对于大一点的公司来说并不很重要；
2 ）内存泄漏，github 上有个 issue 是我们团队提的，好多年了，我们自己没找到原因（缓解了），维护者也没找到

@v2orz能分享一下内存泄露的问题吗？现在已经小范围在用了，主要使用场景还在 SSE ，希望能取一些经，避免踩坑。或者能给个 issue 地址吗

@v2orz 真是，用了新版的 spring cloud gateway 强制升级版本以后真是套娃套的脑袋疼。

以前用 webflux 改造过网关，写了一版后觉得收益太差又用回原来的了。webflux 维护麻烦，性能在我那个场景下也没优势。

1 不存在传说中的性能收益，尤其是针对 DB CRUD 的应用
2 写法不直观，耗费心智，debug 困难
3 居然还有新人关注？

别用，不如升级 jdk

如果真有使用 WebFlux 的需求，还不如试一试 Go 呢，因为 java 生态本就是同步的，硬上 WebFlux 很难受，对开发者的要求也高。Go 生来就把异步做到了语言里，三方库天然支持。

如果没有那么大的压力，纯粹 MVC 用腻了想提升一下，那大可不必。

你再等个几年，同步的写法性能也上来了（ Java 21 ）。

我是用来做数据上报的采集服务。目前使用的是 vertx 和 jdk23 ，整体来说：
1 、jdk21 （最好 >= 23 ）+ SpringBoot 3.x + Virtual Thread ，大概是 85%～ 90% 左右的性能，但是相比较原来的写法，几乎没变化
2 、复杂业务可能还是得等 vt+structured Concurrency + Scoped Value 这套完全体，估计 jdk 25+应该有希望
3 、vert.x 性能还是相当 OK 的，因为我的业务逻辑相对简单，所以使用起来，性能确实比 vt 要好点。但如果之前是 springboot 那套，还是得改不少东西

我就两个字+一句话。劝退+别给自己找不痛快了。

用 golang 吧 心智成本低

java 有协程, 极度需要性能的场景用 callback, 其他场景用协程

已经用了好几年了,从 18 年所有项目都是 WebFLux

@Ayanokouji hhhh ，还真是这样，辛辛苦苦在 callback 地狱挣扎，结果 loom 出来了

@billbob 你们公司的业务场景是怎样的？没遇到什么问题吗

我们就网关用了 gateway ，但是使用 kotlin Coroutine ，很少写回调。感觉就除了内存低，没啥其它优势，数据库驱动不支持 java 的原生，只能用 r2dbc ，所以好多业务只能手写 sql 。现在 loom 也出来了，而且 gateway 也有 mvc 版本了，不过 mvc 版本还不完善，后续可能会迁移到 mvc 版本。

用 vertx 做的网关模块，性能完全满足需求
看果 webflux ，但写法太复杂，遂放弃

在 2020 年左右用过一段时间反应式编程,不推荐用来写业务,复杂的页面,跟意大利面条一样,各种 flatmap,一个简单的获取都需要花很大功夫来弄,当时用的是还是 rxjava,就很难受.最后那个项目维护太复杂了.
之后归纳总结,考虑了下适用的场景,反应式编程在前端可能更合适,防止页面或者窗口阻塞,然后流式的传输,中间做桥进行转接也不错,类似楼上说的网关.

@holulu 你好，请问写业务有最佳实践可以分享一下嘛

@DanLi 没问题啊,mysql,pg 都支持 r2dbc,用起来很爽