Arquitectura Reactiva Quarkus

La palabra Reactivo está sobrecargada y asociada a muchos conceptos como la contrapresión, las mónadas o la arquitectura basada en eventos. Por lo tanto, aclaremos qué entendemos por Reactivo.

La Reactividad es un conjunto de principios y directrices para construir sistemas y aplicaciones distribuidos con capacidad de respuesta. El Manifiesto Reactivo caracteriza los Sistemas Reactivos como sistemas distribuidos que tienen cuatro características:

Además de esto, el artículo de Principios Reactivos enumera un conjunto de reglas y patrones para facilitar la construcción de sistemas reactivos.

El sistema Reactivo es un estilo arquitectónico que puede resumirse como: sistemas distribuidos bien hechos. El uso de paso de mensajes asíncronos ayuda a reforzar el acoplamiento débil (tanto en términos de espacio como de tiempo) entre los distintos componentes. Se envían mensajes a destinos virtuales. El receptor puede estar situado en cualquier lugar, o incluso no existir aún en el momento del envío del mensaje. El pilar de elasticidad permite escalar hacia arriba o hacia abajo los componentes individuales según la carga. La elasticidad también proporciona redundancia, lo que contribuye al pilar de resiliencia. Los fallos son inevitables. Los componentes que forman un sistema reactivo deben manejarlos de manera elegante, evitar fallos en cascada y adaptarse automáticamente.

Un sistema con capacidad de respuesta puede seguir gestionando la solicitud mientras se enfrenta a fallos y bajo una carga fluctuante. Quarkus ha sido diseñado específicamente para ello. Proporciona características que le ayudarán a diseñar, implementar y operar sistemas reactivos.

Quarkus no sólo le va a ayudar a construir sistemas reactivos. También garantizará que cada componente cumpla con los principios reactivos y sea altamente eficiente.

La eficiencia es esencial, especialmente en entornos de nube y contenedores. Los recursos, como la CPU y la memoria, se comparten entre varias aplicaciones. Las aplicaciones que consumen grandes cantidades de memoria son ineficientes y penalizan a las aplicaciones coexistentes. Puede ser necesario solicitar más memoria, CPU o máquinas virtuales de mayor capacidad. Esto incrementa el costo mensual en la nube o reduce la densidad de despliegue.

La E/S es una parte esencial de prácticamente cualquier sistema moderno. Ya sea para invocar un servicio remoto, interactuar con una base de datos o enviar mensajes a un intermediario, todas son operaciones basadas en E/S. Gestionarlas de manera eficiente es fundamental para evitar aplicaciones que consuman recursos de forma excesiva. Por esta razón, Quarkus utiliza E/S no bloqueante, lo que permite que un número reducido de hilos del sistema operativo gestione múltiples operaciones de E/S concurrentes. Como resultado, las aplicaciones basadas en Quarkus permiten una mayor concurrencia, consumen menos memoria y mejoran la densidad de despliegue.

Bajo el capó, Quarkus cuenta con un motor reactivo. Este motor, impulsado por Eclipse Vert.x y Netty, gestiona las interacciones de E/S no bloqueantes.

Las extensiones de Quarkus y el código de la aplicación pueden utilizar este motor para orquestar interacciones de E/S, interactuar con bases de datos, enviar y recibir mensajes, entre otras operaciones.

Si bien el uso de E/S no bloqueante ofrece beneficios significativos, no está exento de costos. De hecho, introduce un nuevo modelo de ejecución, bastante diferente del empleado por los frameworks tradicionales.

Las aplicaciones tradicionales utilizan E/S bloqueante y un modelo de ejecución imperativo (secuencial). Así, en una aplicación que expone un endpoint HTTP, cada solicitud HTTP se asocia con un hilo. En general, dicho hilo procesa toda la solicitud y permanece dedicado exclusivamente a esa solicitud durante su ejecución. Cuando el procesamiento requiere interactuar con un servicio remoto, se utiliza E/S bloqueante. El hilo queda bloqueado mientras espera el resultado de la operación de E/S. Aunque este modelo es sencillo de desarrollar (ya que todo ocurre de forma secuencial), presenta varias desventajas. Para manejar solicitudes concurrentes, se requieren múltiples hilos, lo que implica la necesidad de un grupo de hilos de trabajo (worker thread pool). El tamaño de este grupo limita la concurrencia de la aplicación. Además, cada hilo tiene un costo en términos de memoria y CPU. Los grupos de hilos grandes dan lugar a aplicaciones con alto consumo de recursos.

Como vimos anteriormente, la E/S no bloqueante evita este problema. Un número reducido de hilos puede manejar múltiples operaciones de E/S concurrentes. Volviendo al ejemplo del endpoint HTTP, el procesamiento de la solicitud se ejecuta en uno de estos hilos de E/S. Dado que son pocos, deben utilizarse de manera eficiente. Cuando el procesamiento de la solicitud requiere invocar un servicio remoto, ya no es posible bloquear el hilo. En su lugar, se programa la operación de E/S y se pasa una continuación, es decir, el código que se ejecutará una vez que la operación de E/S haya finalizado.

Este modelo es mucho más eficiente, pero se requiere una forma de escribir código que exprese estas continuaciones.

La arquitectura de Quarkus, basada en E/S no bloqueante y paso de mensajes, permite múltiples modelos de desarrollo reactivo compatibles, todos ellos diferenciados en la forma de expresar continuaciones. Las dos principales formas de escribir código reactivo con Quarkus son:

En primer lugar, Mutiny es una biblioteca de programación reactiva intuitiva y dirigida por eventos. Con Mutiny, se escribe código orientado a eventos. Su código es una tubería que recibe eventos y los procesa. Cada etapa de la tubería puede considerarse como una continuación, ya que Mutiny las invoca cuando la parte anterior de la tubería emite un evento.

La API de Mutiny ha sido adaptada para mejorar la legibilidad y el mantenimiento del código. Mutiny proporciona todo lo necesario para orquestar acciones asíncronas, incluida la ejecución concurrente. Además, ofrece un amplio conjunto de operadores para manipular eventos individuales y flujos de eventos.

Las corutinas son una forma de escribir código asíncrono de manera secuencial. Suspenden la ejecución del código durante las operaciones de E/S y registran el resto del código como continuación. Las corutinas de Kotlin son ideales al desarrollar en Kotlin cuando sólo se necesita expresar composiciones secuenciales (cadena de tareas asíncronas interdependientes).

Cambiar su modelo de desarrollo no es sencillo. Requiere reaprender y reestructurar el código para que sea no bloqueante. Afortunadamente, ¡no es necesario hacerlo!

Quarkus es inherentemente reactivo gracias a su motor reactivo. Sin embargo, usted, como desarrollador de aplicaciones, no necesita escribir código reactivo. Quarkus unifica los enfoques reactivo e imperativo. Esto significa que puede desarrollar aplicaciones tradicionales de bloqueo en Quarkus. ¿Pero cómo se evita bloquear los hilos de E/S? Quarkus implementa un patrón proactor que cambia a un hilo de trabajo cuando es necesario.

Gracias a las indicaciones en su código (como las anotaciones @Blocking y @NonBlocking), las extensiones de Quarkus pueden determinar cuándo la lógica de la aplicación es bloqueante o no bloqueante. Si volvemos al ejemplo del endpoint HTTP mencionado anteriormente, la solicitud HTTP siempre se recibe en un hilo de E/S. Luego, la extensión que despacha esa solicitud a su código decide si invocarla en el hilo de E/S, evitando cambios de hilo, o en un hilo de trabajo. Esta decisión depende de la extensión. Por ejemplo, la extensión Quarkus REST (anteriormente RESTEasy Reactive) utiliza la anotación @Blocking para determinar si el método debe ejecutarse en un hilo de trabajo o si puede ejecutarse directamente en el hilo de E/S.

Quarkus es pragmático y versátil. Usted decide cómo desarrollar y ejecutar su aplicación. Puede utilizar el enfoque imperativo, el reactivo o una combinación de ambos, aplicando la programación reactiva en las partes de la aplicación que requieren alta concurrencia.

Quarkus ofrece un amplio conjunto de API y características reactivas. Esta sección enumera las más importantes, pero no constituye una lista exhaustiva. Quarkus agrega nuevas funcionalidades en cada versión, y Quarkiverse propone numerosas extensiones que habilitan la Reactividad .