看到有个帖子在讨论 Java 异步 技术栈的问题... 由于今天台风不能送外卖,所以我也来分析分析..

[yizmaoaa]

看到有个帖子讨论 Java 目前实现全链路异步的帖子

目前全异步的技术栈大概有

1.SpringWebFlux+Reactor+R2DBC(很久没有了解过了，不知道 Spring 还有没有支持其他服务的一些 Client)

2.Vertx+Future/Vertx+RxJava/Vertx+Mutiny/Vertx+Coroutines

3.Micronaut

4.Quarkus

Vert.x 的 Future 以及 RxJava/Mutiny/Reactor 其实这几个都差不多，基本上在异步技术栈里都是为了解决 CallBack 的问题

主要还是 Jdk 本身的 Future 太拉稀，结果现在每家都自己搞了一套...也是挺蛋疼的

SpringWebFlux/Micronaut/Quarkus 算是比较上层的大杂烩框架了。三家写起来其实都差不多。差别在于 Micronaut/Quarkus 主打的无反射 /云原生。总体打包镜像与内存占用都是比较小的

目前 SpringWebFlux 与 Micronaut 都比较依赖于第三方的 Client 实现，如果第三方的 Client 实现是阻塞的，那么对于 Micronaut 与 WebFlux 来说实际上并不能提高多少吞吐的。

对于 Quarkus 来说，由于 Quarkus 算是在 Vert.x 上面在来了一层，所以 Vert.x 自己实现的各种 Client 在 Quarkus 中也是能用的。比 Micronaut 与 WebFlux 要稍微好那么一丢丢

不过 Micronaut 其实也能用 Vert.x 的 Client，但是效果貌似一般。主要我觉得可能还是 2 套 EventLoop 的问题，不能自上而下的用一套。

理论上 WebFlux 也能用 Vert.x 的各种 Client，但是我觉得效果应该和 Micronaut 差不多。我也不太确定到底麻烦不麻烦。

Micronaut 的 SqlClient 是支持 Vert.x 这边的(之前是我提交的)

另外 Vert.x 这边基本上所有的 Client 都是自己根据协议写的，所以基本上是可以做到全链路异步的。但是碰到官方没有支持到的 Client 那么做法其实与上面的一些东西差不多了

如果你是频次较高的去操作这些没有异步支持的 Client，那么吞吐量还是同样的不尽人意的。所以这也是在做技术选型的时候需要考虑的一点。

如果你对性能的要求没那么高，但是希望内存占用小那么可以选择 Quarkus/Micronaut 两位都支持同步的写法。

如果你对性能要求高，不排除异步的写法那么你可以选择 Vert.x

不管怎么来说或者你用那个，用 Java 写异步的代码都是有点蛋疼的。

相对来说 Vertx+Kotlin Coroutines 要舒服很多，切换到 Kt 的成本也相对的没那么大。

另外目前我是不推荐使用 SpringWebFlux 或者 Micronaut 的异步写法的。

在 TechempoerBenchmarks 最新一轮的性能测试中,这两位的表现并不出色

https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db

如果你用了异步这种麻烦的写法，但是实际上并没有性能的提升，这是划不来的。

引入了异步写法的唯一目的就是希望在同样的服务器上能承受更大的吞吐。

如果引入了异步 /提高了代码的复杂性以及可维护性并没有换回来性能的提升，这是得不偿失的。

另外，异步所能解决的问题,同步同样能解决(只不过是加多少机器的问题...）

[fovecifer]

首先肯定要看业务类型，如果瓶颈点在数据库的话，其实同步还是异步差异不大。

说下我自己的看法：
1. 同步异步不是核心问题，重要是线程模型问题，像 servelet 这种一个链接一个线程的做法，虽然简单，但是性能天花板太低了
2. 纯异步写法对开发者心智要求较高，协程的方案相对来说可接受
3. 纯用户空间的协程也存在一定的问题(例如阻塞问题)，毕竟在内核调度的时候是感知不到的
4. 理论上最优的 N:M 的线程调度，golang 实现了这个，这也是我认同 golang 的关键点

[yizmaoaa]

@fovecifer 这个点倒是有点问题 /实际上 Servlet 很久就不是一个链接一个线程的做法了。

第一个点纯异步写法对开发者心智要求并不高。主要还是很多开发不太理解后段的异步是怎么一个异步法。

[yizmaoaa]

@dk7952638 业务场景有限，Reactor-Netty 其实就是给 Netty 套了层 Reactor，Rsocket 没用过....

[zoharSoul]

@x940727 #6 我都是 ci 的时候才编译 native image, 平时还是跑 jvm 的

[yizmaoaa]

@zoharSoul 基本上都这样...平时运行调试都是正常的走动，走 CI 的时候才打成 native

[JRay]

原来新闻里面帮忙改 bug 的外卖小哥是真的

[yizmaoaa]

@JRay 假的，送外卖一般都是在外面，不去里面的

[fovecifer]

@yizmaoaa 印象里 servlet 从 3.1 开始就支持 worker 线程，但是总体上好像还是一个链接一个线程

第二个问题是我自己的切身体会，相对于协程的写法，还是复杂了一点，尤其是需要考虑背压的时候

我再查一下 servlet 的线程模型，看看是不是我错了

[fovecifer]

@dk7952638 曾经用纯 netty 写过接口，当初也考虑过把 reactor 加进来，但是最后转型 OpenResty 和 golang

个人经验，仅供参考

[INCerry]

我觉得像 C#那样加入 async/await 就很不错，一样的协程+异步 高性能，一点点传染性无所谓了

[yizmaoaa]

@INCerry async/await 是很舒服的了

[shyling]

java，python 写异步主要是有心理负担，要考虑用的库是不是同步的，本来异步的会不会重复 wrap，这需要慢慢发展。。
而 node.js / go 就有先天优势

[yizmaoaa]

@shyling 不太喜欢 Go 这个是主要因素

[pippoflow]

也不要局限于这些更高层的框架；基础的框架比如 project reactor/rxjava 这些，其实还是潜力很大的；涉及网络的比如 reactor netty 也是利器啊。我觉得异步的问题就是如果做成一个类库给客户代码用，可能会存在局限：1 ）对使用方有较高的要求； 2 ）如果全链路异步可能会制约一些功能的实现，或反而将问题复杂化；不过本质上，如果开发人员能力较强，还是可以驾驭的。

[sakura1]

个人感觉异步被吹得有点神了，仔细想想只有在计算时间和等待事件的时间差距不大才有用吧

[twogoods]

三四年前了解学习了一点这块的知识，这么多年过去了除了网关，其他普通业务场景生产上使用的依旧是少数。推不动改造学习成本太高了，堆机器不好吗

[dk7952638]

@fovecifer 为啥这么大的转型啊，直接语言都换了。。。

[v2orz]

我们在生产用 webflux，感觉有点累
可能是水平有限吧，有些问题排查复现起来很困难
维护成本很高，容易写出问题代码

[fovecifer]

@dk7952638 主要考虑开发效率和资源占用，在当时的应用场景下，OpenResty 和 golang 开发出来的接口性能会高很多

[jjianwen68]

问个问题，传统方法，一般会加个 j2cache 做两级缓存；换用 webflux，你们一般还做两级缓存吗