Ola a todos! Esta é a segunda publicación da nosa serie sobre Quarkus. Hoxe falaremos da compilación nativa.
é unha pila Java adaptada para . Aínda que hai moito máis que facer aquí, fixemos un bo traballo en moitos aspectos, incluíndo a optimización da JVM e unha serie de marcos. Unha das características de Quarkus que atraeu un maior interese dos desenvolvedores é o seu enfoque integral e fluido para converter o código Java en ficheiros executables para un sistema operativo específico (a chamada "compilación nativa"), similar a C e C++, onde tal compilación normalmente ocorre ao final dun ciclo de compilación, proba e despregamento.
E aínda que a compilación nativa é importante, como mostraremos a continuación, hai que ter en conta que Quarkus funciona moi ben na máquina Java máis común, OpenJDK Hotspot, grazas ás melloras de rendemento que implementamos en toda a pila. Polo tanto, a compilación nativa debe considerarse como unha bonificación adicional que se pode usar segundo se desexe ou sexa necesario. De feito, Quarkus depende moito de OpenJDK cando se trata de imaxes nativas. E o modo de desenvolvemento, moi aceptado polos desenvolvedores, garante a proba case instantánea dos cambios debido ás capacidades avanzadas de execución de código dinámico implementadas en Hotspot. Ademais, ao crear imaxes nativas de GraalVM, utilízanse a biblioteca de clases OpenJDK e as capacidades de HotSpot.
Entón, por que precisa compilación nativa se todo xa está perfectamente optimizado? Tentaremos responder a esta pregunta a continuación.
Comecemos polo obvio: Red Hat ten unha ampla experiencia na optimización de JVM, pilas e frameworks durante o desenvolvemento de proxectos. , incluíndo:
- O primeiro servidor de aplicacións que funciona na nube na plataforma .
- O primeiro servidor de aplicacións para executarse en ordenadores .
- O primeiro servidor de aplicacións no que se executa .
- Unha variedade de proxectos en execución en dispositivos .
Levamos moitos anos lidando cos retos de executar aplicacións Java na nube e en dispositivos con recursos limitados (léase: IoT) e aprendemos a sacar o máximo proveito da JVM en termos de rendemento e optimización da memoria. Como moitos outros, levamos moito tempo traballando coa compilación nativa de aplicacións Java , , e aínda e somos ben conscientes dos pros e contras deste enfoque (por exemplo, o dilema de escoller entre a universalidade de "construír unha vez - executar en calquera lugar" e o feito de que as aplicacións compiladas son máis pequenas e execútanse máis rápido).
Por que é importante ter en conta estes pros e contras? Porque nalgunhas situacións a súa proporción faise decisiva:
- Por exemplo, en ambientes sen servidor/contorno de eventos onde en tempo real (duro ou suave) para ter tempo para responder aos acontecementos. A diferenza dos servizos persistentes de longa duración, aquí a duración dun arranque en frío aumenta significativamente o tempo de resposta a unha solicitude. A JVM aínda leva unha cantidade significativa de tempo en iniciarse, e aínda que isto pode reducirse nalgúns casos mediante métodos puros de hardware, a diferenza entre un segundo e 5 milisegundos pode ser a diferenza entre a vida e a morte. Si, aquí podes xogar coa creación dunha reserva quente de máquinas Java (o que, por exemplo, fixemos con ), pero isto en si non garante que haxa suficientes JVM para procesar as solicitudes a medida que a carga se escala. E dende o punto de vista económico, esta probablemente non sexa a opción máis correcta.
- Ademais, hai outro aspecto que adoita aparecer: multitenencia. A pesar de que as JVM achegáronse moito aos sistemas operativos nas súas capacidades, aínda non son capaces de facer o que estamos tan afeitos en Linux: illar procesos. Polo tanto, a falla dun fío pode derrubar toda a máquina Java. Moitas persoas tentan evitar este inconveniente dedicando unha JVM separada para cada aplicación de usuario para minimizar as consecuencias dun fallo. Isto é bastante lóxico, pero non encaixa ben coa escala.
- Ademais, para aplicacións orientadas á nube, un indicador importante é a densidade de servizos no servidor. Transición á metodoloxía , microservizos e Kubernetes aumenta o número de máquinas Java por aplicación. É dicir, por unha banda, todo isto proporciona elasticidade e fiabilidade, pero ao mesmo tempo tamén aumenta o consumo de memoria base en canto ao servizo, e algúns destes gastos non sempre son estritamente necesarios. Os ficheiros executables compilados de forma estática benefician aquí debido a varias técnicas de optimización, como a eliminación de código morto de baixo nivel, cando a imaxe final inclúe só aquelas partes dos cadros (incluíndo o propio JDK) que realmente usa o servizo. Polo tanto, a compilación nativa de Quarkus axuda a colocar densamente as instancias de servizo no host sen comprometer a seguridade.
En realidade, os argumentos anteriores xa son suficientes para entender a xustificación da compilación nativa dende o punto de vista dos participantes no proxecto Quarkus. Non obstante, hai outra razón, non técnica, pero tamén importante: nos últimos anos, moitos programadores e empresas de desenvolvemento abandonaron Java en favor de novas linguaxes de programación, crendo que Java, xunto coas súas JVM, pilas e marcos, converteuse demasiado. fame de memoria, moi lento, etc.
Non obstante, o costume de utilizar a mesma ferramenta para resolver calquera problema é . Ás veces é mellor dar un paso atrás e buscar outra cousa. E se Quarkus fai que a xente se deteña e pense, iso é bo para todo o ecosistema Java. Quarkus representa unha visión innovadora de como crear aplicacións máis eficientes, facendo que Java sexa máis relevante para novas arquitecturas de aplicacións como sen servidor. Ademais, debido á súa extensibilidade, Quarkus contará con todo un ecosistema de extensións Java, aumentando significativamente o número de frameworks que admitirán a compilación nativa en aplicacións listas para usar.
Fonte: www.habr.com