使用 Spring webflux，与返回完全实现的 Foo 实例相比，返回 Mono<Foo> 是否降低了序列化成本？答案

【问题标题】：With Spring webflux, does returning a Mono<Foo> cut down on serialization cost compared to returning a fully-realized Foo instance?使用 Spring webflux，与返回完全实现的 Foo 实例相比，返回 Mono<Foo> 是否降低了序列化成本？
【发布时间】：2021-05-03 22:45:35
【问题描述】：

我正在转换我的数据服务以使用 MongoDB 反应式驱动程序。通过我查询信息的方式（在多个部分，同时），它使我能够更有效、更快速地协调所有活动。

到目前为止，这个 API 的消费者还没有准备好被转换，所以我最终调用了Mono.zip(...).blockOptional，然后将完全实现的对象返回给 rest 方法返回给客户端。但我想知道我是否可以从返回 Mono 中受益，并且仍然可以获得一些好处，即使我的数据服务 API 的消费者还没有准备好完全转换为响应式。

是否会在两个服务之间的 Spring Web 序列化/反序列化中返回 Mono 保存？目前，这是整个数据流中最昂贵的部分。还是返回 Mono 或对象本身的时间和性能成本基本相同？

是的，我了解使整个数据流完全响应式的好处，我同意这是最好的方法。但是，就目前而言，我正在尝试了解在“完全反应式”之前是否可以减少序列化的好处。

【问题讨论】：

标签： spring-webflux

【解决方案1】：

返回 Mono 或 Foo 时，序列化没有区别。是否阻塞线程是有区别的。

当您返回 Mono 或 Flux 时，每次 IO 行程不会阻塞线程，但一旦您的数据离开您的服务，它将被序列化为 json

此外，只要您在响应式 API 上调用 block()，就根本没有任何好处。

响应式的主要思想不是让 api 更快，而是让你的 api 处理更多。因此，如果您有一项服务完全响应，而其他消费者没有，那么您仍然有好处，因为您的服务将能够处理更多的消费者

【讨论】：