Hola a tots! Aquesta és la segona publicació de la nostra sèrie sobre Quarkus: avui parlarem de la compilació nativa.
és una pila de Java feta a mida . Tot i que certament hi ha molt més per fer aquí, hem fet un bon treball en molts aspectes, inclosa l'optimització de la JVM i una sèrie de marcs. Una de les característiques de Quarkus que ha despertat l'interès dels desenvolupadors és el seu enfocament integral i perfecte per convertir el codi Java en fitxers executables per a un sistema operatiu específic (l'anomenada "compilació nativa"), similar a C i C++, on aquesta compilació. generalment es produeix al final d'un cicle de compilació, prova i desplegament.
I tot i que la compilació nativa és important, com mostrarem a continuació, cal tenir en compte que Quarkus funciona molt bé a la màquina Java més comuna, OpenJDK Hotspot, gràcies a les millores de rendiment que hem implementat a tota la pila. Per tant, la compilació nativa s'ha de considerar com una bonificació addicional que es pot utilitzar segons es desitgi o sigui necessari. De fet, Quarkus depèn molt d'OpenJDK quan es tracta d'imatges natives. I el mode de desenvolupament, molt acceptat pels desenvolupadors, garanteix la prova gairebé instantània dels canvis a causa de les capacitats avançades d'execució de codi dinàmic implementades a Hotspot. A més, quan es creen imatges natives de GraalVM, s'utilitzen la biblioteca de classes OpenJDK i les capacitats HotSpot.
Aleshores, per què necessiteu una compilació nativa si ja està tot perfectament optimitzat? Intentarem respondre aquesta pregunta a continuació.
Comencem per l'obvi: Red Hat té una àmplia experiència en l'optimització de JVM, piles i marcs durant el desenvolupament de projectes. , incloent:
- El primer servidor d'aplicacions que funciona al núvol de la plataforma .
- El primer servidor d'aplicacions per executar-se en ordinadors .
- El primer servidor d'aplicacions en què s'executa .
- Una varietat de projectes que s'executen en dispositius .
Fa molts anys que ens enfrontem als reptes d'executar aplicacions Java al núvol i en dispositius amb recursos limitats (llegiu: IoT) i hem après a treure el màxim profit de la JVM en termes de rendiment i optimització de memòria. Com molts altres, hem estat treballant amb la compilació nativa d'aplicacions Java durant molt de temps , , i fins i tot i som molt conscients dels avantatges i els contres d'aquest enfocament (per exemple, el dilema de triar entre la universalitat de "construir una vegada, executar-se en qualsevol lloc" i el fet que les aplicacions compilades són més petites i s'executen més ràpid).
Per què és important tenir en compte aquests pros i contres? Perquè en algunes situacions la seva proporció esdevé decisiva:
- Per exemple, en entorns sense servidor o basats en esdeveniments on en temps real (dur o suau) per tenir temps per respondre als esdeveniments. A diferència dels serveis persistents de llarga vida, aquí la durada d'un inici en fred augmenta de manera crítica el temps de resposta a una sol·licitud. La JVM encara triga una quantitat significativa de temps a iniciar-se i, tot i que això es pot reduir en alguns casos mitjançant mètodes de maquinari pur, la diferència entre un segon i 5 mil·lisegons pot ser la diferència entre la vida i la mort. Sí, aquí podeu jugar amb la creació d'una reserva calenta de màquines Java (cosa que, per exemple, vam fer amb ), però això en si mateix no garanteix que hi hagi prou JVM per processar les sol·licituds a mesura que la càrrega s'escalfi. I des del punt de vista econòmic, probablement aquesta no és l'opció més correcta.
- A més, hi ha un altre aspecte que sovint apareix: multiarrendament. Malgrat que les JVM s'han acostat molt als sistemes operatius en les seves capacitats, encara no són capaços de fer allò que estem tan acostumats a Linux: processos d'aïllament. Per tant, la fallada d'un fil pot fer caure tota la màquina Java. Moltes persones intenten evitar aquest inconvenient dedicant una JVM independent per a l'aplicació de cada usuari per tal de minimitzar les conseqüències d'una fallada. Això és bastant lògic, però no encaixa bé amb l'escala.
- A més, per a aplicacions orientades al núvol, un indicador important és la densitat de serveis a l'amfitrió. Transició a la metodologia , microserveis i Kubernetes augmenta el nombre de màquines Java per aplicació. És a dir, d'una banda, tot això aporta elasticitat i fiabilitat, però alhora també augmenta el consum de memòria base en termes de servei, i algunes d'aquestes despeses no sempre són estrictament necessàries. Els fitxers executables compilats estàticament es beneficien aquí a causa de diverses tècniques d'optimització, com ara l'eliminació de codi mort de baix nivell, quan la imatge final inclou només aquelles parts dels marcs (inclòs el propi JDK) que el servei realment utilitza. Per tant, la compilació nativa de Quarkus ajuda a col·locar densament les instàncies de servei a l'amfitrió sense comprometre la seguretat.
De fet, els arguments anteriors ja són suficients per entendre la justificació de la compilació nativa des del punt de vista dels participants del projecte Quarkus. Tanmateix, hi ha una altra raó, no tècnica, però també important: en els darrers anys, molts programadors i empreses de desenvolupament han abandonat Java en favor dels nous llenguatges de programació, creient que Java, juntament amb les seves JVM, piles i frameworks, s'ha convertit en massa. amb fam de memòria, massa lent, etc.
No obstant això, l'hàbit d'utilitzar la mateixa eina per resoldre qualsevol problema és . De vegades és millor fer un pas enrere i buscar una altra cosa. I si Quarkus fa que la gent s'aturi i pensi, això és bo per a tot l'ecosistema Java. Quarkus representa una visió innovadora de com crear aplicacions més eficients, fent que Java sigui més rellevant per a noves arquitectures d'aplicacions com ara sense servidor. A més, a causa de la seva extensibilitat, s'espera que Quarkus tingui tot un ecosistema d'extensions de Java, augmentant significativament el nombre de frameworks que admetin la compilació nativa en aplicacions fora de la caixa.
Font: www.habr.com