V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
magese
V2EX  ›  Java

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

  •  
  •   magese ·
    magese · 138 天前 · 3566 次点击
    这是一个创建于 138 天前的主题,其中的信息可能已经有所发展或是发生改变。

    孤陋寡闻了,这玩意好像出了挺久了😅;

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

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

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

    第 1 条附言  ·  136 天前

    感谢各位大佬的倾囊相授,用AI总结了一下各位的看法:

    SpringWebFlux是一个响应式编程框架,相较于SpringMVC有以下优劣势:并发量大、资源消耗少、功能强大是优势;编程模型复杂、学习成本高、调试麻烦是劣势。它不能完全替代SpringMVC,适用场景主要是处理高并发的无数据库依赖的情况,如网关。对于复杂业务和团队技术不够过硬的项目来说,引入该框架可能会增加维护成本。总体而言,个人玩玩还行,但在商业项目中需谨慎选择使用,并根据具体需求权衡利弊

    那我就只在自己项目对接OpenAI的地方玩玩就好了

    29 条回复    2024-02-16 17:36:43 +08:00
    Leviathann
        1
    Leviathann  
       138 天前   ❤️ 1
    I think Project Loom is going to kill reactive programming.

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

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

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

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

    loom 也不是银弹, loom 是增强 blocking 的方案, 不是增强 reactive 的方案
    DoctorDeng
        4
    DoctorDeng  
       138 天前
    可以学习,学习,没啥特殊需要一般不会使用。我之前的项目也就网关这种需要性能的模块用了。WebFlux 使用成本高,引入 WebFlux 后相关依赖的所有组件都得支持 Reactive 。另外 WebFlux 的代码阅读调试麻烦,不像同步方式那么容易让人理解,最后 WebFlux 使用对开发人员要求较高,用的不好,程序性能搞不好会倒退。
    Wien
        5
    Wien  
       138 天前
    没啥用。20 年的时候项目改造中用过,IO 密集型应用能压榨机器 CPU ,减少内存。
    chrisia
        6
    chrisia  
       138 天前
    千万别用 WebFlux ,代码简直就是地狱,学习成本也是巨高,文档基本都是英文,调试麻烦。唯一的好处是装逼。
    cloud107202
        7
    cloud107202  
       138 天前   ❤️ 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 的人会舒适些
    chrisia
        8
    chrisia  
       138 天前
    在我看来这玩意就不适合后端用,一旦使用了整条链路都要返回 Mono/Flux ,看了好多代码比回调地狱还恐怖,一个 Mono 类里面看看有多少个方法,导致我 IDE 智能提示都卡。这种风格前端倒是可以用用。loom 出来这玩意就没啥用了,反人类的东西。
    chrisia
        9
    chrisia  
       138 天前
    如果是写网关应用,那 WebFlux 还是有较大的价值。但我为何非要用这套晦涩的东西写网关?
    chrisia
        10
    chrisia  
       138 天前
    BTW 我选择 kotlin
    BBCCBB
        11
    BBCCBB  
       138 天前
    放弃这个. 这种玩意儿不是给人用的...
    kuituosi
        12
    kuituosi  
       138 天前
    主要是网关高并发
    mmdsun
        13
    mmdsun  
       138 天前 via iPhone
    上家公司全线都是反应式架构设计,连 APP ,前端都是 Rxjava 、Rxjavascript 这种。

    目前做的 OpenAI 相关项目也是用的这个 SpringWebflux ,处理 SSE 流相关的太方便了。个人感觉替代 MVC 不是问题。唯一不足就是对程序员要求较高。(其实这个学学函数式编程就行)
    a3mao
        14
    a3mao  
       138 天前
    关键是看能力,完全可以替换
    txzh007
        15
    txzh007  
       138 天前
    函数式编程对人的要求挺高的,自己写个项目练手挺好的.
    dlmy
        16
    dlmy  
       138 天前
    之前使用 WebFlux + Disruptor 编写了一个 Dispatch 程序,其中存在许多问题,且代码难以调试,导致开发效率很低,因此 WebFlux 是很难替换掉 MVC 的。
    flmn
        17
    flmn  
       138 天前
    作为行业标准的 Spring 推 WebFlux 这么多年也没用起来不是没有原因的。

    Java 21 出来后,WebFlux 更没有前途了。
    kytrun
        18
    kytrun  
       138 天前 via Android
    我们在用,小公司,一年开发体验下来只有一个好处:并行调用多个接口比用 CompletableFuture 简洁点
    silentsky
        19
    silentsky  
       138 天前 via Android
    掌握了响应式编程就没什么难度 一般用下网关
    srx1982
        20
    srx1982  
       138 天前
    如果你自己玩可以用,在公司千万别用,学习成本高不说,只要业务稍微有点复杂,多访问几个数据源再加点各种计算之类的,维护成本几何级上升
    hdfg159
        21
    hdfg159  
       138 天前 via iPhone
    学习成本很大,团队很难适应,自己玩玩还行,有其他替代品
    Geekerstar
        22
    Geekerstar  
       137 天前
    jetlinks 有用这个
    imokkkk
        23
    imokkkk  
       137 天前
    不太好理解 即使你搞明白了 你的同事们 后续维护这个项目的人 很难保证能看的懂
    shuimugan
        24
    shuimugan  
       137 天前
    调研过,用了就相当于回到 2017 年之前的 nodejs 还没到 8.0 lts(async/await 进入稳定版)前代码中的回调地狱,当然这个 async/await 也是抄 2012 年.NET Framework 4.5 的。所以一般也就面试问问看看是不是真的有人脑子抽了选型用这个。知道它能干嘛的,确实需要解决问题的,大概率也会换个语言把要做的事情做了。
    java123
        25
    java123  
       137 天前
    用 Vert.x 或者 Quarkus 吧
    byte10
        26
    byte10  
       137 天前
    java 21 出来之后 ,它就没啥用了。响应式编程,设计的思想挺有意思的,暂时想不到有啥特别场景非要用它的,以前是为了解决 IO 密集型,现在 loom 虚拟线程出来之后,这需求被替代了。

    如果你的数据库还是同步 IO 的话,那么还是要回到多线程上来😂。

    要玩的话 直接上 vert.x ,可以体验一下。vert.x 非常好玩,而且最新 4.5 版本支持虚拟线程了,任君选择。
    mysunshinedreams
        27
    mysunshinedreams  
       137 天前
    使用门槛还是挺高的,非核心项目自己拿来练手还是可以的,核心项目维护人员一多,就容易出现失控的局面
    Yzzm
        28
    Yzzm  
       137 天前
    主要是网关这种不依赖数据库的情况下用一下,业务还是正常的 mvc
    ychost
        29
    ychost  
       93 天前
    实际项目中深度用过 Webflux (后面慢慢用 kotlin 的 Coroutine 重构了),最后还是推荐用 kotlin 的 Coroutine ,项目合作开发,很多人写得 reactor 代码一言难尽,简单的逻辑硬是写了一抹多代码
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1887 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 00:17 · PVG 08:17 · LAX 17:17 · JFK 20:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.