⏭️ ❔ 🦕 Quarkus如何结合命令式和反应式编程 🛌🏽 🔻 🔯

今年，我们计划认真开发容器主题，Cloud-Native Java和Kubernetes。这些主题的合乎逻辑的延续将是已经在Habré上考虑过的Quarkus框架的故事。今天的文章并没有过多地关注Quarkus带给企业的“亚原子超快速Java设备”。（顺便说一句，注册并进入我们的网络研讨会“ 这是Quarkus-Kubernetes本机Java框架 ”，该研讨会将于5月27日举行。我们将展示如何“从头开始”或转移现成的解决方案）

Java和JVM仍然非常流行，但是当与无服务器技术和面向云的微服务一起使用时，用于JVM的Java和其他语言的使用越来越少，因为它们占用了太多的内存空间并且加载速度太慢，这使其不适用于与短寿命的容器一起使用。幸运的是，由于Quarkus，这种情况目前开始改变。

超快速亚原子Java已达到新的水平！

42个版本，8个月的社区工作和177位杰出的开发人员-所有的结果是Quarkus 1.0于2019年11月发布，该版本标志着该项目开发的重要里程碑，并提供了许多很酷的特性和功能（有关更多信息，请参见公告）。。

今天，我们将介绍Quarkus如何基于单个反应式内核结合命令式和反应式编程模型。我们将首先简要回顾一下历史，然后仔细研究Quarkus的双核会如何反应以及Java开发人员如何利用这些优势。

Mikroservisy，事件驱动的架构和无服务器功能-正如他们所说的，今天所有这些都在增加。最近，基于云的体系结构的创建变得更加简单和负担得起，但是仍然存在问题-特别是对于Java开发人员。例如，在无服务器功能和微服务的情况下，迫切需要减少启动时间，减少内存消耗并使它们的开发更加方便和愉快。近年来，Java进行了一些改进，例如针对容器修改的人体工程学功能等。但是，让Java在容器中工作仍然不容易。因此，我们将从研究Java的一些固有复杂性开始，这在开发面向容器的Java应用程序时尤为突出。

首先，让我们谈谈这个故事。

流和容器

从8u131版本开始，由于人体工程学功能的改进，Java或多或少地支持了容器。特别是，JVM现在知道它运行在多少个处理器核心上，并且可以正确配置线程池-通常为fork / join池。当然，这很棒，但是，我们有一个传统的Web应用程序，该应用程序使用HTTP Servlet，并在Tomcat，Jetty等上运行。结果，此应用程序将为每个请求提供一个单独的流，并允许它在等待I / O操作（例如，访问数据库，文件或其他服务）时阻止该流。即，这样的应用程序的大小不取决于可用核的数量，而是取决于同时请求的数量。此外，这意味着Kubernetes中按内核数进行的配额或限制在这里不会特别有用，交易将以小跑结束。

内存不足

流是内存。容器内存限制绝不是万能药。刚开始增加应用程序和线程的数量，迟早您会遇到开关频率的严重增加，从而导致性能下降。此外，如果应用程序使用传统的微服务框架或连接到数据库，或使用缓存，或以某种方式另外消耗内存，则您绝对需要一个工具，该工具可让您查看JVM内部并查看其如何管理内存，而不是杀死它。 JVM本身（例如XX：+ UseCGroupMemoryLimitForHeap）。即使从Java 9开始，JVM仍然学会了接受cgroup并进行相应的调整，但是备份和管理内存仍然是一件相当复杂的事情。

配额和限制

Java 11引入了对CPU配额的支持（例如PreferContainerQuotaForCPUCount）。 Kubernetes还提供限制和配额支持。是的，所有这些都是有道理的，但是如果应用程序再次超出分配的配额，我们再次得出结论：大小（与传统Java应用程序一样）由内核数以及为每个请求分配单独的线程来确定，然后所有这一切几乎没有意义。
此外，如果使用配额和限制或Kubernetes底层平台的水平（横向）扩展功能，问题也无法解决。我们只是花更多的资源来解决原始问题，或者结果，我们最终使用了资源。而且，如果它是公共，公共云中的高负载系统，我们几乎肯定会开始使用超出其实际需求的资源。

那怎么办呢？

如果采用简单方式，则使用异步和非阻塞I / O库和框架，例如Netty，Vert.x或Akka。它们具有反应性，因此更适合在容器中工作。由于非阻塞I / O，同一线程可以一次处理多个同时的请求。当一个请求正在等待I / O结果时，其处理线程将被释放并用于另一个请求。当I / O结果最终到达时，第一个请求的处理将继续。通过在同一流中交替处理请求，可以减少线程总数，并减少处理请求的资源消耗。

使用非阻塞I / O时，内核数成为关键参数，因为它确定了可以并行运行的I / O线程数。如果使用得当，可以有效地在内核之间分配负载，并以更少的资源应对更高的负载。

怎么样，这就是全部吗？

不，还有一件事。反应式编程有助于更好地利用资源，但也要付出代价。特别是，必须根据非阻塞原理重写代码，并避免阻塞输入输出流。这是完全不同的开发和实施模型。并且尽管有很多有用的库，但这仍然是通常思维方式的主要变化。

首先，您需要学习如何编写异步运行的代码。一旦开始使用非阻塞I / O，您需要明确规定收到请求的响应时应采取的措施。仅阻止和等待将失败。作为回报，您可以传递回调，使用反应式编程或继续。但这还不是全部：要使用非阻塞I / O，您既需要非阻塞服务器又需要客户机，并且最好在任何地方都需要。在HTTP的情况下，一切都很简单，但是还有一个数据库，文件系统等等。

尽管总的端到端反应性可提供最大的效率，但实际上这种转变可能难以消化。因此，组合反应性和命令性代码的能力成为实现以下目的的必要条件：

有效利用软件系统中负载最大的区域中的资源；
在其他部分使用更简单的样式代码。

介绍Quarkus

实际上，这是Quarkus的本质-在一个运行时环境中结合反应式和命令式模型。

Quarkus基于Vert.x和Netty，在其之上还使用了许多反应式框架和扩展来帮助开发人员。Quarkus不仅旨在构建HTTP微服务，而且还构建事件驱动的体系结构。由于其反应性，它可以与消息传递系统（Apache Kafka，AMQP等）一起非常有效地工作。

诀窍是如何在命令性代码和反应性代码中使用相同的喷气引擎。

Quarkus出色地做到了。命令式和反应式之间的选择是显而易见的-同时使用一个和另一个反应堆核心。不仅如此，它还具有快速的非阻塞代码，可处理几乎所有通过事件循环线程（事件循环线程，又称为IO线程）的内容。但是，如果您拥有经典的REST或客户端应用程序，那么Quarkus就可以使用命令式编程模型了。例如，Quarkus中的HTTP支持基于对非阻塞和Jet引擎（Eclipse Vert.x和Netty）的使用。您的应用程序收到的所有HTTP请求首先通过事件循环（IO线程），然后将它们发送到管理请求的代码部分。根据目的地，可以在单独的线程（在servlet和Jax-RS的情况下使用的所谓工作线程）中调用请求控制代码，也可以使用原始的输入输出流（反应性路由反应性路由）。