有在用 vert.x 的同学吗？

我司正全面切向 VERTX

我们在用。vert.x 采用类似 Node.js 的 eventloop callback 机制，优势是 Eventloop 是单线程场景下几乎是最快的并发解决方案，但也需要周边生态的支持，比如 DbClient/HttpClient 这些跟 IO 打交道的 API 需要支持异步回调的风格，社区干脆就整合或者自己实现了。依赖注入的类库可以用 Guice，整体启动时间大概是同规模 spring boot 工程的四分之一左右，基准内存占用少一半。

实践相关的经验推荐阅读这个专栏
https://zhuanlan.zhihu.com/whitewoodcity

问题是 jdbc 好像不支持 AIO 啊。。。

回调地狱。不知道涌 kotlin 有没有改善。

@icekingcy 你们是怎么用这个东西的啊？？？

@earendil1412 vertx 做了封装，他提供的 api 是异步的

@ZSeptember kotlin 协程啊，有官方的模块。还有 rx，reactivex

@cloud107202 自己搭了一个小项目，用了 spring boot，但是总感觉怪怪的。。。vertx 和 spring 好像不是很搭

我用 springboot 做 di，bean 和配置都交给它了，定时任务也用 springboot 自带的。不需要异步的地方，还在用 spring-data-jpa，jdbcTemplate 也在用。没有用 vertx 的 cluster，也没有用它那些管理工具，纯粹当 Java 版 nodejs 在用。

虽然 vert.x 有跟 spring 集成的 demo，但跟 spring 搭配起来会很奇怪，使用 vert.x 全家桶是比较好的选择。
vert.x 全家桶跟 spring 的全家桶又不一样，spring 是做好了给你送上门，vert.x 是提供食材、厨具，让你自己做...虽然 vert.x 的理念是很先进，但如果要快速把项目落地的话 spring 还是更好的选择，毕竟现在硬件比人力便宜。尤其对于小团队来说，性能、高并发什么的是不用去考虑的

@swim2sun

用 vertx 的 jdbc api 的时候有些不适应，因为在 spring 里用的 orm，直接拼 sql 感觉很不方便似的，但后来一想，之前写 node.js 的时候，用的那些框架，也一样写 sql 却没有这种感觉，应该就是先入为主的原因吧。

目前来说，vertx 全家桶要比 spring 全家桶简单太多了。只不过一直在使用 spring 的思维里，没办法跳出来，不知道该怎么组织 vertx 的代码

@sagaxu 确实，应该把 vertx 当成工具用

Spring 在线事务这一套东西确实比较好用，用 vertx 写事务比较痛苦，看场景，这两个不矛盾
Spring 主要被滥用得比较厉害（包括官方），到处 XML、注解太鬼畜了，社区组件源码质量也泥沙俱下

@Cbdy 如果 Java 能把 async/await 关键词加进来，用 vertx 就比较爽了。在这之前，HTTP 后端的最佳选择可能还是 Node.js/TypeScript

@ZSeptember 可以的。用 kotlin 的协程可以把回调用 awaitResult 来改写。

@PDX
可以自己在 vertx 基础上再封装一层
这也是相对 spring 更自由的地方

我用 vertx 封装了 ebean,加了调度器，但是工作很难找啊，国内也没社区

@brett 真的没几家公司用这个

@PDX 哈哈哈，为了方便招人，我在应用的入口上加了 spring boot 的入口，说实话 ebean 不是一般的好用，对于持续交付和写作开发的方面上

vert.x 我觉得挺好。但是只是一部分。没有 springboot 全面，数据库这块得自己写。

@runningman jooq 好像挺好用

@javenwang 你在用吗 vertx + jooq ？

@runningman 没有用 jooq

@PDX 那用的啥，这块可以交流交流，270115861

@runningman 之前研究过，现在发现它并没有解决我的痛点，jooq 并不是一个 orm，只是替我们拼 sql 执行而已

@javenwang 那最后咋整的

我们用的 vert.x + JOOQ + RX2 + Dagger2, 缓存 caffeine, 数据库协作同步 Liquibase