¡Hola a todos! Esta es la segunda publicación de nuestra serie sobre Quarkus; hoy hablaremos sobre la compilación nativa.
es una pila de Java diseñada para . Si bien ciertamente hay mucho más por hacer aquí, hemos realizado un buen trabajo en muchos aspectos, incluida la optimización de la JVM y una serie de marcos. Una de las características de Quarkus que ha atraído un mayor interés por parte de los desarrolladores es su enfoque integral y fluido para convertir el código Java en archivos ejecutables para un sistema operativo específico (la llamada "compilación nativa"), similar a C y C++, donde dicha compilación normalmente ocurre al final de un ciclo de compilación, prueba e implementación.
Y si bien la compilación nativa es importante, como mostraremos a continuación, cabe señalar que Quarkus se ejecuta muy bien en la máquina Java más común, OpenJDK Hotspot, gracias a las mejoras de rendimiento que hemos implementado en toda la pila. Por lo tanto, la compilación nativa debe considerarse como una ventaja adicional que puede utilizarse según se desee o sea necesario. De hecho, Quarkus depende en gran medida de OpenJDK cuando se trata de imágenes nativas. Y el modo de desarrollo, bien aceptado por los desarrolladores, garantiza pruebas de cambios casi instantáneas gracias a las capacidades avanzadas de ejecución dinámica de código implementadas en Hotspot. Además, al crear imágenes nativas de GraalVM, se utilizan la biblioteca de clases OpenJDK y las capacidades de HotSpot.
Entonces, ¿por qué necesitas una compilación nativa si ya todo está perfectamente optimizado? Intentaremos responder a esta pregunta a continuación.
Comencemos con lo obvio: Red Hat tiene una amplia experiencia en la optimización de JVM, pilas y marcos durante el desarrollo de proyectos. incluso:
- El primer servidor de aplicaciones que funciona en la nube en la plataforma .
- El primer servidor de aplicaciones para ejecutar en ordenadores .
- El primer servidor de aplicaciones en ejecutarse .
- Una variedad de proyectos que se ejecutan en dispositivos .
Hemos estado lidiando con los desafíos de ejecutar aplicaciones Java en la nube y en dispositivos con recursos limitados (léase: IoT) durante muchos años y hemos aprendido a aprovechar al máximo la JVM en términos de rendimiento y optimización de la memoria. Como muchos otros, llevamos mucho tiempo trabajando con la compilación nativa de aplicaciones Java a través de , , e incluso y somos muy conscientes de los pros y los contras de este enfoque (por ejemplo, el dilema de elegir entre la universalidad de "compilar una vez y ejecutar en cualquier lugar" y el hecho de que las aplicaciones compiladas son más pequeñas y se ejecutan más rápido).
¿Por qué es importante considerar estos pros y contras? Porque en algunas situaciones su relación resulta decisiva:
- Por ejemplo, en entornos sin servidor/controlados por eventos donde en tiempo real (duro o suave) para tener tiempo de responder a los eventos. A diferencia de los servicios persistentes de larga duración, aquí la duración de un arranque en frío aumenta de manera crítica el tiempo de respuesta a una solicitud. La JVM todavía tarda una cantidad significativa de tiempo en iniciarse, y si bien esto puede reducirse en algunos casos mediante métodos puros de hardware, la diferencia entre un segundo y 5 milisegundos puede ser la diferencia entre la vida y la muerte. Sí, aquí puedes jugar a crear una reserva activa de máquinas Java (lo que, por ejemplo, hicimos con ), pero esto en sí mismo no garantiza que habrá suficientes JVM para procesar solicitudes a medida que aumenta la carga. Y desde un punto de vista económico, probablemente esta no sea la opción más correcta.
- A continuación, hay otro aspecto que surge a menudo: el multitenencia. A pesar de que las JVM se han acercado mucho a los sistemas operativos en sus capacidades, todavía no son capaces de hacer lo que estamos tan acostumbrados en Linux: aislar procesos. Por lo tanto, la falla de un subproceso puede provocar la caída de toda la máquina Java. Mucha gente intenta solucionar este inconveniente dedicando una JVM separada para la aplicación de cada usuario con el fin de minimizar las consecuencias de una falla. Esto es bastante lógico, pero no encaja bien con la escala.
- Además, para las aplicaciones orientadas a la nube, un indicador importante es la densidad de servicios en el host. Transición a la metodología , microservicios y Kubernetes aumentan la cantidad de máquinas Java por aplicación. Es decir, por un lado, todo ello aporta elasticidad y fiabilidad, pero al mismo tiempo también aumenta el consumo de memoria base en términos de servicio, y algunos de estos gastos no siempre son estrictamente necesarios. Los archivos ejecutables compilados estáticamente se benefician aquí debido a varias técnicas de optimización, como la eliminación de código muerto de bajo nivel, cuando la imagen final incluye solo aquellas partes de los marcos (incluido el propio JDK) que el servicio realmente utiliza. Por lo tanto, la compilación nativa de Quarkus ayuda a colocar densamente instancias de servicio en el host sin comprometer la seguridad.
En realidad, los argumentos anteriores ya son suficientes para comprender la justificación de la compilación nativa desde el punto de vista de los participantes del proyecto Quarkus. Sin embargo, hay otra razón, no técnica, pero también importante: en los últimos años, muchos programadores y empresas de desarrollo han abandonado Java en favor de nuevos lenguajes de programación, creyendo que Java, junto con sus JVM, pilas y marcos, se ha vuelto demasiado tiene hambre de memoria, es demasiado lento, etc.
Sin embargo, la costumbre de utilizar la misma herramienta para solucionar cualquier problema es . A veces es mejor dar un paso atrás y buscar algo más. Y si Quarkus hace que la gente se detenga y piense, entonces eso es bueno para todo el ecosistema Java. Quarkus representa una visión innovadora de cómo crear aplicaciones más eficientes, haciendo que Java sea más relevante para nuevas arquitecturas de aplicaciones como las sin servidor. Además, debido a su extensibilidad, se espera que Quarkus tenga un ecosistema completo de extensiones de Java, lo que aumentará significativamente la cantidad de marcos que admitirán la compilación nativa en aplicaciones listas para usar.
Fuente: habr.com