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

28

317 天前

作为一个为 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 写起来是非常蛋疼的。