孤陋寡闻了,这玩意好像出了挺久了😅;
我是最近在对接 openai api 的时候偶然了解到的,看了下感觉挺有意思的。
有没有实际使用过的大佬来说一下相较于 SpringMVC 有哪些优劣势?是否能够完全平替掉 MVC ?
可以的话我想直接在自己项目来试试水了。
感谢各位大佬的倾囊相授,用AI总结了一下各位的看法:
SpringWebFlux是一个响应式编程框架,相较于SpringMVC有以下优劣势:并发量大、资源消耗少、功能强大是优势;编程模型复杂、学习成本高、调试麻烦是劣势。它不能完全替代SpringMVC,适用场景主要是处理高并发的无数据库依赖的情况,如网关。对于复杂业务和团队技术不够过硬的项目来说,引入该框架可能会增加维护成本。总体而言,个人玩玩还行,但在商业项目中需谨慎选择使用,并根据具体需求权衡利弊
那我就只在自己项目对接OpenAI的地方玩玩就好了
1
Leviathann 356 天前 1
I think Project Loom is going to kill reactive programming.
查查说这句话的人是谁 |
2
chendy 356 天前 1
17 年还是 18 年刚出的时候体验过一把,还做过一点简单的测试
个人体验得出的结论:自己学习学习玩无所谓,除非团队技术过硬或者业务足够简单,否则不要在商业项目中尝试 因为这玩意解决的是’用多线程扛高并发线程过多扛不住‘的问题,当时测试,一样的最简单接口,一样的压力,响应时间接近,但是 webflux 的内存使用相当少 代价就是换了个姿势的回调地狱,业务简单还好,业务复杂度套上这玩意的复杂度真的就是杀人级别的存在,没点实力和闲心根本 hold 不住 |
3
yazinnnn0 356 天前
不能平替
优势是并发量大, 消耗资源少, 功能强大 劣势是编程模型复杂, 复杂点的业务你要写成 monad 地狱, 虽然并发量大,但是一般业务瓶颈在数据库, 利用不到 reactive 的最大优势 写着玩可以随便试, 用 kotlin 协程可以稍微拯救一下 monad 地狱 loom 也不是银弹, loom 是增强 blocking 的方案, 不是增强 reactive 的方案 |
4
DoctorDeng 356 天前
可以学习,学习,没啥特殊需要一般不会使用。我之前的项目也就网关这种需要性能的模块用了。WebFlux 使用成本高,引入 WebFlux 后相关依赖的所有组件都得支持 Reactive 。另外 WebFlux 的代码阅读调试麻烦,不像同步方式那么容易让人理解,最后 WebFlux 使用对开发人员要求较高,用的不好,程序性能搞不好会倒退。
|
5
Wien 356 天前
没啥用。20 年的时候项目改造中用过,IO 密集型应用能压榨机器 CPU ,减少内存。
|
6
chrisia 356 天前
千万别用 WebFlux ,代码简直就是地狱,学习成本也是巨高,文档基本都是英文,调试麻烦。唯一的好处是装逼。
|
7
cloud107202 356 天前 1
就个人经验,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 的人会舒适些 |
8
chrisia 356 天前
在我看来这玩意就不适合后端用,一旦使用了整条链路都要返回 Mono/Flux ,看了好多代码比回调地狱还恐怖,一个 Mono 类里面看看有多少个方法,导致我 IDE 智能提示都卡。这种风格前端倒是可以用用。loom 出来这玩意就没啥用了,反人类的东西。
|
9
chrisia 356 天前
如果是写网关应用,那 WebFlux 还是有较大的价值。但我为何非要用这套晦涩的东西写网关?
|
10
chrisia 356 天前
BTW 我选择 kotlin
|
11
BBCCBB 356 天前
放弃这个. 这种玩意儿不是给人用的...
|
12
kuituosi 356 天前
主要是网关高并发
|
13
mmdsun 356 天前 via iPhone
上家公司全线都是反应式架构设计,连 APP ,前端都是 Rxjava 、Rxjavascript 这种。
目前做的 OpenAI 相关项目也是用的这个 SpringWebflux ,处理 SSE 流相关的太方便了。个人感觉替代 MVC 不是问题。唯一不足就是对程序员要求较高。(其实这个学学函数式编程就行) |
14
a3mao 356 天前
关键是看能力,完全可以替换
|
15
txzh007 356 天前
函数式编程对人的要求挺高的,自己写个项目练手挺好的.
|
16
dlmy 356 天前
之前使用 WebFlux + Disruptor 编写了一个 Dispatch 程序,其中存在许多问题,且代码难以调试,导致开发效率很低,因此 WebFlux 是很难替换掉 MVC 的。
|
17
flmn 356 天前
作为行业标准的 Spring 推 WebFlux 这么多年也没用起来不是没有原因的。
Java 21 出来后,WebFlux 更没有前途了。 |
18
kytrun 356 天前 via Android
我们在用,小公司,一年开发体验下来只有一个好处:并行调用多个接口比用 CompletableFuture 简洁点
|
19
silentsky 356 天前 via Android
掌握了响应式编程就没什么难度 一般用下网关
|
20
srx1982 356 天前
如果你自己玩可以用,在公司千万别用,学习成本高不说,只要业务稍微有点复杂,多访问几个数据源再加点各种计算之类的,维护成本几何级上升
|
21
hdfg159 355 天前 via iPhone
学习成本很大,团队很难适应,自己玩玩还行,有其他替代品
|
22
Geekerstar 355 天前
jetlinks 有用这个
|
23
imokkkk 355 天前
不太好理解 即使你搞明白了 你的同事们 后续维护这个项目的人 很难保证能看的懂
|
24
shuimugan 355 天前
调研过,用了就相当于回到 2017 年之前的 nodejs 还没到 8.0 lts(async/await 进入稳定版)前代码中的回调地狱,当然这个 async/await 也是抄 2012 年.NET Framework 4.5 的。所以一般也就面试问问看看是不是真的有人脑子抽了选型用这个。知道它能干嘛的,确实需要解决问题的,大概率也会换个语言把要做的事情做了。
|
25
java123 355 天前
用 Vert.x 或者 Quarkus 吧
|
26
byte10 355 天前
java 21 出来之后 ,它就没啥用了。响应式编程,设计的思想挺有意思的,暂时想不到有啥特别场景非要用它的,以前是为了解决 IO 密集型,现在 loom 虚拟线程出来之后,这需求被替代了。
如果你的数据库还是同步 IO 的话,那么还是要回到多线程上来😂。 要玩的话 直接上 vert.x ,可以体验一下。vert.x 非常好玩,而且最新 4.5 版本支持虚拟线程了,任君选择。 |
27
mysunshinedreams 355 天前
使用门槛还是挺高的,非核心项目自己拿来练手还是可以的,核心项目维护人员一多,就容易出现失控的局面
|
28
Yzzm 355 天前
主要是网关这种不依赖数据库的情况下用一下,业务还是正常的 mvc
|
29
ychost 311 天前
实际项目中深度用过 Webflux (后面慢慢用 kotlin 的 Coroutine 重构了),最后还是推荐用 kotlin 的 Coroutine ,项目合作开发,很多人写得 reactor 代码一言难尽,简单的逻辑硬是写了一抹多代码
|