Quarkus兵变和无神论与反应性

Question

TL；DR：哪种模式更常见？使用Mutiny Imperative resteasy，还是只使用resteasy？

我的理解是，哗变允许我传递给Quarkus一个更长的运行动作，并让它处理代码如何在上下文中运行的细节。使用被动技能比兵变命令有同等或更多的好处吗？如果从功能的角度看，从线程处理的角度看，它是相等的或者更好，那么Reactive将是很好的，因为它需要更少的代码来维护(创建uni，等等)。然而，如果传回一个Uni明显更好，那么使用它可能是有意义的。

https://quar kus . io/guides/getting-started-reactive # important-vs-reactive-a-question-of-threads

叛乱命令：

@GET
    @Path("/getState")
    @Produces(MediaType.APPLICATION_JSON)
    public Uni<State> getState() throws InterruptedException {
        return this.serialService.getStateUni();
    }

反应性:

@GET
    @Path("/getState")
    @Produces(MediaType.APPLICATION_JSON)
    public State getState() throws InterruptedException {
        return this.serialService.getState();
    }

Answer 1

与往常一样，这要视情况而定。首先，我建议您阅读 https://quarkus.io/blog/resteasy-reactive-smart-dispatch/，其中解释了这两种方法之间的区别。

它不是关于更长的动作(异步！=更长)；是关于调度策略的。

当使用RESTEasy-Reactive时，它使用I/O线程（事件循环）来处理请求，并且仅当endpoint的签名需要时才切换到工作线程。使用I/O线程可以实现更好的并发性（因为您不使用工作线程），减少内存使用（因为您无需创建工作线程）以及降低响应时间（因为您节省了一些上下文切换）。

Quarkus检测您的方法是否可以在I/O线程上调用。启发式方法基于方法的签名（包括注释）。要重用问题中的示例：

• 返回 State 的方法被视为阻塞，因此将在工作线程上调用
• 返回 Uni 的方法

所以，问题是，你应该使用哪种调度策略？这实际上取决于你的应用程序和上下文。如果你不期望有很多并发请求（很难给出一个通用的阈值，但通常在200到500 req/sec之间），使用阻塞/命令式方法是完全可以的。如果你的应用程序充当一个具有潜在请求高峰的API网关，非阻塞会提供更好的结果。

请记住，即使您选择命令式/阻塞式方法，RESTEasy反应式方法也提供了许多好处。由于大多数繁重的请求/响应处理都是在 I/O 线程上完成的，因此您可以更快地使用更少的内存来...自由。