{"id":74795,"date":"2020-03-20T20:42:21","date_gmt":"2020-03-20T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie"},"modified":"2020-03-20T20:42:21","modified_gmt":"2020-03-20T17:42:21","slug":"kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"C\u00f3mo Quarkus une la programaci\u00f3n imperativa y reactiva","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Este a\u00f1o planeamos desarrollar en serio los temas de contenedores, Java Nativa en la Nube<\/a><\/noindex> y Kubernetes<\/a><\/noindex>. La continuaci\u00f3n l\u00f3gica de estos temas ser\u00e1 hablar del marco Quarkus, ya examinado<\/a><\/noindex> en Habr\u00e9. El art\u00edculo de hoy se centra no tanto en la estructura de la \u00abJava subat\u00f3mica ultrarr\u00e1pida\u00bb, sino en las perspectivas que Quarkus aporta a la empresa.<\/p>\n

\"C\u00f3mo
\n
\nJava y la JVM siguen siendo extremadamente populares, pero al trabajar con tecnolog\u00edas sin servidor y microservicios orientados a la nube, Java y otros lenguajes para la JVM se utilizan cada vez menos, ya que ocupan demasiada memoria y se cargan demasiado lento, lo que los hace inadecuados para el uso con contenedores de corta duraci\u00f3n. Afortunadamente, esta situaci\u00f3n est\u00e1 comenzando a cambiar gracias a Quarkus.
\n<\/a><\/noindex><\/p>\n

\u00a1La Java subat\u00f3mica ultrarr\u00e1pida ha alcanzado un nuevo nivel!<\/h3>\n

\n42 lanzamientos, 8 meses de trabajo de la comunidad y 177 desarrolladores incre\u00edbles \u2013 el resultado de todo esto fue el lanzamiento en noviembre de 2019 Quarkus 1.0<\/a><\/noindex>, un lanzamiento que marca un hito importante en el desarrollo del proyecto y ofrece un mont\u00f3n de funciones y capacidades geniales (puede leer m\u00e1s sobre ellas en el anuncio<\/a><\/noindex>).<\/p>\n

Hoy contaremos c\u00f3mo Quarkus une los modelos de programaci\u00f3n imperativa y reactiva basados en un n\u00facleo reactivo \u00fanico. Comenzaremos con una breve excursi\u00f3n a la historia y luego examinaremos en detalle en qu\u00e9 consiste el dualismo del n\u00facleo reactivo de Quarkus y c\u00f3mo Java<\/a><\/noindex>-los desarrolladores pueden aprovechar estas ventajas.<\/p>\n

Los microservicios<\/a><\/noindex>, arquitecturas impulsadas por eventos<\/a><\/noindex> y funciones sin servidor \u2013 todo esto est\u00e1, hoy en d\u00eda, en auge. Recientemente, crear arquitecturas orientadas a la nube se ha vuelto mucho m\u00e1s f\u00e1cil y accesible, sin embargo, los problemas permanecen, especialmente para los desarrolladores de Java. Por ejemplo, en el caso de las funciones sin servidor y los microservicios, existe una necesidad urgente de reducir el tiempo de arranque, disminuir el consumo de memoria y hacer que su desarrollo sea m\u00e1s conveniente y placentero. En los \u00faltimos a\u00f1os, Java ha realizado algunas mejoras, como las funcionalidades de ergonom\u00eda mejoradas para contenedores, etc. Sin embargo, lograr que Java funcione correctamente en un contenedor sigue siendo un desaf\u00edo. Por lo tanto, comenzaremos examinando algunas de las complejidades internas de Java que se manifiestan de manera m\u00e1s aguda en el desarrollo de aplicaciones Java orientadas a contenedores.<\/a><\/noindex>-Las funciones son, hoy en d\u00eda, lo que se llama un \u00e1rea en auge. Desde hace poco, la creaci\u00f3n de arquitecturas orientadas a la nube se ha vuelto mucho m\u00e1s f\u00e1cil y accesible, sin embargo, los problemas persisten, especialmente para los desarrolladores de Java. Por ejemplo, en el caso de funciones serverless y microservicios, existe una necesidad urgente de reducir el tiempo de arranque, disminuir el consumo de memoria y, en definitiva, hacer que su desarrollo sea m\u00e1s c\u00f3modo y placentero. En los \u00faltimos a\u00f1os, Java ha introducido varias mejoras, como funcionalidades de ergonom\u00eda mejoradas para contenedores, entre otras. Sin embargo, lograr un funcionamiento adecuado de Java en un contenedor sigue siendo complicado. Por lo tanto, comenzaremos examinando algunas de las complejidades internas de Java que se manifiestan con mayor intensidad al desarrollar aplicaciones Java orientadas a contenedores.<\/p>\n

Comencemos por la historia.<\/p>\n

\"C\u00f3mo<\/p>\n

Flujos y contenedores<\/h3>\n

\nA partir de la versi\u00f3n 8u131, Java ha comenzado a soportar contenedores de manera m\u00e1s o menos efectiva gracias a las mejoras en el funcionalismo de ergonomics. En particular, ahora la JVM sabe en cu\u00e1ntos n\u00facleos de procesador se est\u00e1 ejecutando y puede ajustar las piscinas de hilos en consecuencia, generalmente las piscinas fork\/join. Sin duda, esto es maravilloso, pero supongamos que tenemos una aplicaci\u00f3n web tradicional que utiliza servlets HTTP y se ejecuta en Tomcat, Jetty, etc. Como resultado, esta aplicaci\u00f3n asignar\u00e1 un hilo diferente para cada solicitud y permitir\u00e1 que este hilo se bloquee mientras espera operaciones de entrada\/salida, por ejemplo, al acceder a bases de datos, archivos u otros servicios. Es decir, el tama\u00f1o de tal aplicaci\u00f3n no depende de la cantidad de n\u00facleos disponibles, sino de la cantidad de solicitudes concurrentes. Adem\u00e1s, esto significa que las cuotas o l\u00edmites en Kubernetes en cuanto a la cantidad de n\u00facleos no ayudar\u00e1n mucho aqu\u00ed, y eventualmente terminar\u00e1 en una limitaci\u00f3n.<\/p>\n

Agotamiento de memoria<\/h3>\n

\nLos hilos son memoria. Y las limitaciones de memoria dentro de los contenedores no son una panacea. Simplemente comience a aumentar la cantidad de aplicaciones y hilos, y tarde o temprano se encontrar\u00e1 con un crecimiento cr\u00edtico en la frecuencia de conmutaciones y, como consecuencia, con una degradaci\u00f3n del rendimiento. Adem\u00e1s, si la aplicaci\u00f3n utiliza marcos de microservicios tradicionales o se conecta a una base de datos, o utiliza cach\u00e9, o consume memoria de alguna otra manera, necesita evidentemente una herramienta que le permita mirar dentro de la JVM y ver c\u00f3mo gestiona la memoria, sin acabar con la propia JVM (por ejemplo, XX:+UseCGroupMemoryLimitForHeap). Y a pesar de que, a partir de Java 9, la JVM aprendi\u00f3 a reconocer los cgroups y adaptarse en consecuencia, la reserva y gesti\u00f3n de memoria siguen siendo tareas bastante complejas.<\/p>\n

Cuotas y l\u00edmites<\/h3>\n

\nJava 11 introdujo soporte para cuotas de CPU (como PreferContainerQuotaForCPUCount). Kubernetes tambi\u00e9n ofrece soporte para l\u00edmites y cuotas. S\u00ed, todo esto tiene sentido, pero si la aplicaci\u00f3n nuevamente excede la cuota asignada, volvemos a la situaci\u00f3n en la que el tama\u00f1o \u2013 como sucede con las aplicaciones Java tradicionales \u2013 est\u00e1 determinado por la cantidad de n\u00facleos y asigna un hilo separado para cada solicitud, es decir, no sirve de mucho.
\nAdem\u00e1s, si se utilizan cuotas y l\u00edmites o funciones de escalado horizontal (scale-out) de la plataforma subyacente a Kubernetes, el problema no se resuelve por s\u00ed mismo. Simplemente gastamos m\u00e1s recursos en resolver el problema original o terminamos despilfarrando recursos. Y si se trata de un sistema altamente demandado en una nube p\u00fablica accesible, es casi seguro que empezamos a usar m\u00e1s recursos de los que realmente necesitamos.<\/p>\n

\u00bfY qu\u00e9 hacer con todo esto?<\/h3>\n

\nEn t\u00e9rminos simples, se deben utilizar bibliotecas y marcos de entrada\/salida as\u00edncronos y no bloqueantes como Netty, Vert.x<\/a><\/noindex> o Akka. Son mucho m\u00e1s adecuados para trabajar en contenedores debido a su naturaleza reactiva. Gracias a la entrada\/salida no bloqueante, el mismo hilo puede manejar m\u00faltiples solicitudes simult\u00e1neamente. Mientras una solicitud est\u00e1 esperando los resultados de entrada\/salida, el hilo que la procesa se libera y se ocupa de otra solicitud. Y cuando los resultados de entrada\/salida finalmente llegan, la procesaci\u00f3n de la primera solicitud contin\u00faa. Alternando el procesamiento de solicitudes en el mismo hilo, se puede reducir el n\u00famero total de hilos y disminuir el consumo de recursos para procesar solicitudes.<\/p>\n

Con la entrada\/salida no bloqueante, el n\u00famero de n\u00facleos se convierte en un par\u00e1metro clave, ya que determina cu\u00e1ntos hilos de entrada\/salida pueden ejecutarse en paralelo. Si se utiliza correctamente, esto permite distribuir de manera efectiva la carga entre los n\u00facleos y manejar cargas m\u00e1s altas con menos recursos.<\/p>\n

\u00bfAs\u00ed que eso es todo?<\/h3>\n

\nNo, hay algo m\u00e1s. La programaci\u00f3n reactiva ayuda a utilizar mejor los recursos, pero tambi\u00e9n tiene su costo. En particular, el c\u00f3digo tendr\u00e1 que reescribirse seg\u00fan los principios de no bloqueo y evitar la bloqueo de hilos de entrada\/salida. Y esta es una modelo de desarrollo y ejecuci\u00f3n completamente diferente. Y aunque hay muchas bibliotecas \u00fatiles, sigue siendo un cambio radical en la forma habitual de pensar.<\/p>\n

Primero, necesitas aprender a escribir c\u00f3digo que se ejecute de manera as\u00edncrona. Una vez que comiences a utilizar la entrada y salida no bloqueante, debes especificar claramente qu\u00e9 debe suceder al recibir una respuesta a una solicitud. Ya no puedes simplemente bloquear y esperar. En su lugar, puedes pasar callbacks, utilizar programaci\u00f3n reactiva o continuaciones. Pero eso no es todo: para utilizar la entrada y salida no bloqueante, necesitas servidores y clientes no bloqueantes, y preferiblemente en todas partes. En el caso de HTTP, todo es simple, pero tambi\u00e9n hay bases de datos, sistemas de archivos y mucho m\u00e1s.<\/p>\n

Y aunque la reactividad total y continua ofrece la m\u00e1xima eficiencia, puede ser dif\u00edcil de digerir en la pr\u00e1ctica. Por lo tanto, la capacidad de combinar c\u00f3digo reactivo e imperativo se vuelve una condici\u00f3n necesaria para:<\/p>\n

    \n
  1. Utilizar los recursos de manera eficiente en las \u00e1reas m\u00e1s cargadas del sistema de software;<\/li>\n
  2. Usar un c\u00f3digo m\u00e1s sencillo en estilo en las dem\u00e1s partes.<\/li>\n<\/ol>\n

    <\/p>\n

    Presentamos Quarkus<\/h3>\n

    \nDe hecho, esa es la esencia de Quarkus: combinar los modelos reactivo e imperativo en un solo entorno de ejecuci\u00f3n.<\/p>\n

    Quarkus se basa en Vert.x y Netty, sobre los cuales se utiliza toda una serie de frameworks y extensiones reactivas dise\u00f1adas para ayudar a los desarrolladores. Quarkus est\u00e1 destinado a construir no solo microservicios HTTP, sino tambi\u00e9n arquitecturas impulsadas por eventos. Gracias a su naturaleza reactiva, trabaja de manera muy eficiente con sistemas de mensajer\u00eda (Apache Kafka, AMQP, etc.).<\/p>\n

    La clave est\u00e1 en c\u00f3mo utilizar el mismo motor reactivo tanto para c\u00f3digo imperativo como para c\u00f3digo reactivo.<\/p>\n

    \"C\u00f3mo<\/p>\n

    Quarkus lo maneja magistralmente. La elecci\u00f3n entre imperativo y reactivo es obvia: usar el n\u00facleo reactivo tanto para uno como para otro. Y lo que realmente ayuda es el c\u00f3digo no bloqueante y r\u00e1pido, que maneja casi todo lo que pasa por el hilo del ciclo de eventos (event-loop thread, tambi\u00e9n conocido como IO thread). Pero si tienes aplicaciones REST cl\u00e1sicas o aplicaciones del lado del cliente, Quarkus tiene lista una modelo de programaci\u00f3n imperativa. Por ejemplo, el soporte HTTP en Quarkus se basa en el uso de un motor no bloqueante y reactivo (Eclipse Vert.x y Netty). Todas las solicitudes HTTP que recibe tu aplicaci\u00f3n pasan primero por el ciclo de eventos (IO Thread) y luego se env\u00edan a la parte del c\u00f3digo que gestiona las solicitudes. Dependiendo del destino, el c\u00f3digo de control de solicitudes puede ser llamado en un hilo separado (el llamado worker thread, que se aplica a servlets y Jax-RS) o puede usar el hilo de entrada y salida original (ruta reactiva).<\/p>\n

    \"C\u00f3mo<\/p>\n

    Para los conectores de sistemas de transmisi\u00f3n de mensajes se utilizan clientes no bloqueantes que funcionan sobre el motor Vert.x. Por lo tanto, puedes enviar, recibir y procesar mensajes de sistemas de mensajer\u00eda middleware de manera efectiva.<\/p>\n

    se indica que: Quarkus.io<\/a><\/noindex> se han reunido varias buenas gu\u00edas que te ayudar\u00e1n a empezar a trabajar con Quarkus:<\/p>\n