如果要在 Spring webflux 和 Vert.x web 选一个，在不仅仅只考虑性能的情况下，选哪一个

[tctc4869]

在 Spring webflux 和 Vert.x web 的两种都有基于 netty 的响应式 webmvc 框架选一个，在不仅仅只考虑性能的情况下，（例如灵活可扩展性，多种可能的开发方式选择）等，各位会选择哪一个？

除了 Spring webflux 和 Vert.x web，还有哪些呢？

[CoderGeek]

webflux rxjava ？说实话都用的少

[hantsy]

@chendy 目前 R2dbc 还不能完全代替 Jdbc 。在 Spring Data 下，Spring data jdbc 可以说是一个轻量的 ORM 框架了，Spring Data R2dbc 基于全新的 R2dbc 协议，协议范围也没有完全替代所有的 JDBC 功能。比如很现实的一个例子，Spring Data Jdbc 可以操作表关联关系，Spring Data R2dc 还不能。目前 Spring data jdbc 和 Spring data R2dbc 共享了部分代码，但是很多东西在项目处理棘手，例如对于维护数据库，怎么处理 Flyway （依赖 Jdbc 协议）等， 与 R2dbc 协作也变成困难了。

[hantsy]

@sagaxu WebFlux 只是 Spring 造出来一个词。基本上 Spring 自己的生态可以全部使用了。

Vertx 相对还是比较小众化，它的 Rective PgClient 我试用过，实在有点吃力，长期没写 JDBC，那个操作和 JDBC 一样原始。Quarkus 也集成了 Vertx 的 PgClient，MySQlClient Reactive 操作，不过现在 Hibernate 下新开了一个 Hibernate Rx 项目，利用大家熟悉的 JPA/Hibernate API （主要是保留同样的 Annnotations 使用） 重新实现 Reactive 功能。

目前几乎所有（当然还有少量没有 Reactive 版本的）的以前传统的 Spring API 都有 Reactive 版本。Spring Webflux 基本可以在项目开发中代替传统的那一套以 Spring WebMvc 为基础 API 。

[hantsy]

@liuxey Spring Data 下的项目从 Spring 5.0 加入 WebFlux 模块时，一开始就有 NoSQL 支持 Reactive Streams，比如 Mongo，Redis 是最早提供 Reactive 驱动的，现在常用的 NoSQL 有 Reactive 支持，包含 Casandra，ElasticSearch，Couchbase 等，这些在 Spring Data 都有提供 Reactive 版本。

现在 RDBMS 也通过 Spring Data R2dbc （目前流行关系数据库都提供了 R2dbc 驱动）解决 RDBMS 的 Reactive 实现问题了。Spring Data R2dbc 1.0 刚进入 Spring Boot 2.3 Release train.

[lhx2008]

生产环境不要用，特别是 webflux，性能提高并不是那么明显，但是代码可读性，面向对象的能力，扩展性，可维护性都扑街，还有各种坑等着你。
最简单的，异步整合三个数据源，三个数据源用回调函数返回数据，你怎么写回调串一起？有一个报错了你怎么处理怎么重试？下次要删掉一个呢？

[WispZhan]

看来只有我选 Ktor 这个异端？

不管是 WebFlux 还是 Vertx，你的数据库驱动必须要有良好的异步支持，不然性能比传统的阻塞式 mvc 还差。

[chendy]

自己玩的话，随意
公司项目的话，都不用

[yizmaoaa]

作为一个为 Vert.x 贡献过一点代码人。

在不考虑性能等情况下 WebFlux 和 Vert.x 都不要用

Webflux 表面看起来生态齐全，但是其大部分生态都是阻塞的客户端外面套一层壳。所以性能看起来与传统 SpringBoot 差别真心不大。

Vert.x 除非你比较强，或者说项目真的并发比较大，否则也是不太建议你使用 Vert.x

Vert.x 4 后所有的异步操作默认都返回了 Future 。所以开发也比较方便，另外就是你用 Kt 的话也会比较舒服。

相对于 Spring 家的来说，Vert.x 不是框架，而是工具。官方开发人员就那么多。维护每个中间件的 Client 已经比较累了

所以 Vert.x 的一些 Client 都很原始。并没有太多的精力在去开发框架。Vert.x 的官方人员只负责给你写一个基础协议通信的 Client 、想要更简单的开发还是需要自己写很多东西。

所以如果你的某些项目业务不复杂，而且并发高。那么用 Vert.x 是一个很好的选择

反之你的项目业务流程比较复杂，并发不高。大量的 CRUD 。我还是建议你使用传统的 SpringBoot 。开发速度更快。配套设施也齐全

再着回答一下第三条附言，要用异步驱动 jdbc 来访问数据库再能保持良好的性能么，不然性能会比传统阻塞式性能还差？

这里不得不说一下 Vert.x 下关于访问数据库的两个项目，一个是传统 JDBC 外套一个壳子的 Vertx-JDBC 。一个是完全异步的 SQL-Client 。 比传统阻塞性能还差是不存在的。只不过确实会因为传统的 JDBC 占用的大量的连接会导致吞吐量上不去。但是总体来说也是比 Springboot 强不少

另外，其实对于这种玩意来说，大吞吐量下必然情况是大多数访问打进来是打到缓存层的 Redis 啊之类的。这种就特别适合 Vert.x 。代码量少。性能高。不必纠结 SQL 问题。

你说的不考虑性能的情况下，完全操作就是基于传统数据库，那么这种比较原始的 SQL-Client 写起来是非常蛋疼的。

[araaaa]

vertx➕ spring reactor

[tctc4869]

@yizmaoaa

@YUyu101
kt? Kotlin ？
用这个做 Vert 开发比 java 用 vert 开发 舒服么？舒服在哪？代码好看便于阅读么？

[sagaxu]

@tctc4869 用了 Kotlin 就是协程那套了，不再需要回调套回调，也不需要 then 套 then 了，reactive 那套写法只适合平铺直叙，循环中带点分支就开始绕了。

@hantsy 能用和按照异步方式重新设计差别还是很大的，原生异步支持的协议是不是够全，自己开发私有协议实现是不是方便

[zoharSoul]

我选 vertx 起码比 spring webflux 成熟

[hantsy]

@sagaxu 我倒觉得恰好相反，对于 REST API，本来就是数据流的处理，用 ReactiveStreams API 感觉很亲切，异常另外一条路径返回结果就好了。

Kotlin 在 Spring 值得使用，很多配置都是 Kotlin DSL 扩展。https://github.com/hantsy/spring-kotlin-dsl-sample/blob/master/webmvc/src/main/kotlin/com/example/demo/DemoApplication.kt#L45-L75

协程在 Spring 文档中并没有太多提到如何控制，以前看过 Android Kotlin 开发一点教程，UI 和后端 IO 都用不同的 Dispatcher 来调节。

[yizmaoaa]

@tctc4869 就是开发速度和阅读性，Vert.x 自带了 Promise/Future 。但是在 4.0 之前 所有 API 默认都是 callback 那一套。

自己为每个 API 封装个 Future 太蛋疼了，要么就只能选择 RxJava 。

4.0 之后，每个 API 都原生返回 Future 了，操作起来就比较方便。

用 Kotlin 的好处就是 Vert.x 的 Kt 包是封装了 API 了。每个异步操作都是 XXXAwait 。和写传统都代码区别不大了。

Future 和 Rxjava 那套对同事以及个人水平都是有要求的。很容易把代码组织成 shi 。。。

[yizmaoaa]

另外再补充一下，Quarkus 也不错可以考虑考虑，就是用的人少点，这两个项目都算是红帽的。而且两个项目的核心开发者与 Graalvm 都交流挺密切的。另外 Vert.x 也利用 Graalvm 衍生出了 ES4X 这个项目。

另外如果真想 WebFlux 与 Vert.x 中做技术选型的话 我还是比较推荐 Vert.x 的

主要还是我觉得国内开发者参与 Vert.x 项目不少，因为前几届的谷歌夏令营项目 Vert.x 都有参与的。

而且好几个参与 Google 夏令营的国内开发者参与了 Vert.x 的一些子项目开发。

例如从去年开始出的 Vert.x-sql-client 就是国内的开发者开发的。

参与了 Vert.x 项目贡献的人也不少。虽然我也仅仅是修复了 Vert.x 的一些简单的 BUG 。

也就是说假如你使用 Vert.x 出了一些紧急问题，那么你提个 Issues，或者群里发一下问题，可能没多久就能解决掉

对于 Webflux 和 R2dbc 来说，我没太关注。不知道有没有国内的开发者贡献过代码所以出了问题很可能只能等官方解决。

[tctc4869]

@yizmaoaa 4.0?

4.0.0-milestone?

[tctc4869]

@yizmaoaa
我看了一下 maven 上关于 vert.x jar 版本的发布时间
4.0.0-milestone 是 2019 年出的，
而 3.9.0 是 2020 年出的。
3.9 与 3.9 以前的有什么区别么，3.9 与 4.0 相比呢

[yizmaoaa]

@tctc4869 是的，4.0 目前还没有正式发布。具体发布时间我也不太清楚。假如后面的项目要用 Vert.x 我还是建议直接使用 4.0 。因为 4.0 更改的东西蛮多的。之前有个朋友已经直接使用 4.0 第 4 个里程碑版本 在正式环境了。

[yizmaoaa]

@tctc4869 4.0 在 3.8 的时候就开始做了，3.9 是有一些小更改。基本都是 BUG 修复之类的。3.8 的一些变动基本上就是为了 4.0 做准备的。比如以前都是 Future 负责生产和消费。3.8 改了实现，新增了 Promise 负责生产、Future 负责消费。

4.0 的更新就比较多了，所有 API 都默认返回 Future，还有就是以前官方建议所有的第三方客户端，例如 Mysql 、HttpClient 、Redis 都是每个 Verticle 创建自己的。4.0 之后 Vert.x 将这些客户端在获取连接或者执行时都绑定在了一个 Context 上，所以可以多个 Verticle 去共享一个 Client 。 还有就是 Json 处理 Jackson 不在是强制的了，可以替换为任意一个 Json 实现。

这些是比较大的变化，其他的你可以参考 Vert.x 的 Break Change

https://github.com/vert-x3/wiki/wiki/4.0.0-Deprecations-and-breaking-changes

[yizmaoaa]

@tctc4869 还有就是增加了一个 SQL-Template 。写 SQL 能稍微方便点，目前 SQL-Client 的 PG 与 Mysql 部分总体已经完事。4.0 应该还要等 mssql 与 db2 的实现完成才会发布。4.0 应该还会发布 opentracing 与 zipkin 与 Vert.x 的集成。

总的来说，3.8 与 3.9 以及后面所发布的 3.x 改动基本上都不大了。4.0 是一个大版本。所以才会在 19 年就开始发布里程碑版。