什么时候应该阻止/订阅 Mono/Flux？答案

【问题标题】：When should you block / subscribe to a Mono/Flux?什么时候应该阻止/订阅 Mono/Flux？
【发布时间】：2021-10-10 15:34:47
【问题描述】：

假设你有一些助焊剂和单声道

val people: Flux<Person> = repo.getPeople()
val peopleCount: Mono<Int> = people.count()

并且来自例如一个 WebFlux 控制器，你返回一个 Mono:

data class Response(
    val people: List<People>,
    val personCount: Int
)

应用程序中将通量和单声道分别解析为 List 和 Int 的适当位置在哪里？你只是阻止（）一切吗？有没有办法让框架解决所有问题？

编辑：我想我的主要困惑是我看到的所有教程响应对象中的字段实际上都不是反应性的，所以看起来我需要在从控制器返回对象之前解决所有问题。如果响应对象看起来像这样对我来说更有意义

data class Response(
    val people: Flux<People>,
    val personCount: Mono<Int>
)

【问题讨论】：

我认为控制器或服务中的发布者永远不会有block 的位置，因为它会导致异常，因为您不再是被动的。您可以从控制器方法中返回 Mono 或 Flux 并由框架解决。这同样适用于错误处理。如果您的 Mono/Flux 包含错误，我们也会为您解决。

【解决方案1】：

只有在 servlet 世界中使用反应器时才能阻塞，即使这样你也可以传回 Mono/Flux，这将是一个异步请求。

举个例子，比如，

return repo.getPeople().collectList().map( people -> new response(peoples, people.count())

最终成为框架将订阅的Mono<Response>。

您需要在 Mono/Flux 上使用运算符，而不是阻塞反应链。我建议查看 Reactor Java 文档。每个操作员都有很棒的图表，可以直观地了解操作员正在做什么。

【讨论】：