Native Compilation in Quarkus – warum das wichtig ist

Hallo zusammen! Dies ist der zweite Beitrag unserer Quarkus-Serie – heute sprechen wir über die native Kompilierung.

unterstützt Quarkus die Verwendung des Advanced Message Queuing Protocol ( – das ist ein Java-Stack, der für Kubernetesoptimiert ist. Und obwohl es hier natürlich noch viel zu tun gibt, haben wir viele Aspekte gut bearbeitet, einschließlich der Optimierung von JVM und einer Reihe von Frameworks. Ein besonderes Merkmal von Quarkus, das das Interesse der Entwickler geweckt hat, ist der umfassende nahtlose Ansatz zur Umwandlung von Java-Code in ausführbare Dateien für ein bestimmtes Betriebssystem (die sogenannte "native Kompilierung"), ähnlich wie bei C und C++, wo diese Kompilierung normalerweise am Ende eines Zyklus stattfindet, der aus Erstellung, Test und Bereitstellung besteht.

Und obwohl die native Kompilierung, wie wir im Folgenden zeigen werden, wichtig ist, sollte man beachten, dass Quarkus tatsächlich auch auf einer ganz normalen Java-Maschine mit OpenJDK Hotspot gut funktioniert, dank der Leistungsverbesserungen, die wir im gesamten Stack implementiert haben. Daher sollte native Kompilierung als zusätzlicher Bonus betrachtet werden, den man nach Wunsch oder Bedarf verwenden kann. Tatsächlich stützt sich Quarkus in Bezug auf native Images in erheblichem Maße auf OpenJDK. Der von den Entwicklern gut angenommene Entwicklungsmodus ermöglicht nahezu sofortige Tests von Änderungen dank der erweiterten dynamischen Codeausführungsfunktionen, die in Hotspot implementiert sind. Darüber hinaus wird bei der Erstellung nativer Images die OpenJDK-Klassenbibliothek und die Fähigkeit von HotSpot genutzt.

Warum ist dann native Kompilierung notwendig, wenn alles bereits hervorragend optimiert ist? Diese Frage werden wir im Folgenden zu beantworten versuchen.

Fangen wir mit dem Offensichtlichen an: Red Hat hat umfangreiche Erfahrungen in der Optimierung von JVMs, Stacks und Frameworks im Verlauf des Projekts. JBoss, einschließlich:

• Der erste Anwendungsserver für den Einsatz in der Cloud auf der Plattform -Plattform bereitstellt. Weitere Informationen über die Funktionsweise finden Sie.
• Der erste Anwendungsserver für den Einsatz auf Rechnern Plug PC.
• Der erste Anwendungsserver für den Einsatz auf Raspberry Pi.
• Eine Reihe von Projekten, die auf Geräten laufen Android.

Wir beschäftigen uns seit vielen Jahren mit dem Start von Java-Anwendungen in der Cloud und auf ressourcenbeschränkten Geräten (sprich, IoT) und haben gelernt, das Maximum aus der JVM in Bezug auf Leistung und Speichereffizienz herauszuholen. Wie viele andere arbeiten wir seit Langem mit der nativen Kompilierung von Java-Anwendungen über GCJ, Avian, Excelsior JET und sogar Dalvik und wir sind uns der Vor- und Nachteile dieses Ansatzes bewusst (zum Beispiel das Dilemma der Wahl zwischen der Vielseitigkeit "build once – run-anywhere" und dem Vorteil, dass kompilierte Anwendungen eine kleinere Größe haben und schneller starten).

Warum ist es so wichtig, diese Vor- und Nachteile zu berücksichtigen? Weil in bestimmten Situationen ihr Verhältnis entscheidend wird:

• Zum Beispiel in serverlosen/ereignisgesteuerten Umgebungen, in denen Dienste unbedingt in einem (strengen oder lockeren) Echtzeitmodus laufen müssen, um auf Ereignisse zu reagieren. Im Gegensatz zu langlebigen persistenten Diensten erhöht hier die Dauer des Kaltstarts kritisch die Antwortzeit auf Anfragen. Der Start der JVM benötigt immer noch erhebliche Zeit, und obwohl man in einigen Fällen die Zeit rein hardwareseitig reduzieren kann, kann der Unterschied zwischen einer Sekunde und 5 Millisekunden eine Frage von Leben und Tod sein. Ja, hier kann man mit der Erstellung von Hot-Standby-Java-Maschinen experimentieren (was wir zum Beispiel bei der Portierung von OpenWhisk auf Knative), aber das allein garantiert nicht genügend JVMs, um die Anforderungen bei steigender Last zu bewältigen. Auch aus wirtschaftlicher Sicht ist das sicherlich nicht die beste Lösung.
• Darüber hinaus gibt es einen häufig auftretenden Aspekt, die Multitenanz. Obwohl JVMs in ihren Fähigkeiten den Betriebssystemen stark näher gekommen sind, sind sie immer noch nicht in der Lage, das zu tun, was wir im gleichen Linux gewohnt sind – die Isolierung von Prozessen. Daher kann ein Fehler in einem Thread die gesamte Java-Maschine zum Absturz bringen. Viele versuchen, diesen Nachteil zu umgehen, indem sie für jede Anwendung eines Benutzers eine separate JVM bereitstellen, um die Auswirkungen eines Ausfalls zu minimieren. Das ist durchaus sinnvoll, harmoniert aber schlecht mit der Skalierung.
• Außerdem ist für cloudorientierte Anwendungen ein Indikator wichtig, wie die Dichte der Dienste auf dem Host. Der Übergang zur Methodik 12 Faktoren der Anwendung, Mikrodienste und Kubernetes erhöhen die Anzahl der Java-Maschinen pro Anwendung. Das bedeutet, dass dies einerseits Flexibilität und Zuverlässigkeit bietet, andererseits jedoch auch der Grundverbrauch an Speicher pro Dienst steigt, wobei ein Teil dieser Kosten nicht immer unbedingt erforderlich ist. Statisch kompilierte Executables profitieren hier von verschiedenen Optimierungstechniken, wie der Low-Level-Dead-Code-Eliminierung, bei der nur die Teile der Frameworks (einschließlich des JDK), die der Dienst tatsächlich nutzt, in das endgültige Image aufgenommen werden. Daher hilft die native Kompilierung von Quarkus dabei, Instanzen von Diensten dichter auf dem Host zu platzieren, ohne die Sicherheit zu gefährden.

Die oben genannten Argumente sind bereits ausreichend, um die Berechtigung der nativen Kompilierung aus der Perspektive der Teilnehmer des Quarkus-Projekts zu verstehen. Es gibt jedoch noch einen weiteren, nicht technischen, aber ebenso wichtigen Grund: In den letzten Jahren haben viele Programmierer und Entwicklungsunternehmen Java zugunsten neuer Programmiersprachen aufgegeben, da sie der Meinung sind, dass Java zusammen mit ihrer JVM, den Stacks und Frameworks zu speicherhungrig und zu langsam geworden ist.

Allerdings ist es nicht immer richtig, das gleiche Werkzeug für alle Aufgaben zu verwenden – das ist nicht immer die richtige Entscheidung.. Manchmal ist es besser, einen Schritt zurückzutreten und nach etwas anderem zu suchen. Wenn Quarkus die Menschen dazu bringt, eine Pause einzulegen und nachzudenken, ist das gut für das gesamte Java-Ökosystem. Quarkus verkörpert einen innovativen Ansatz dafür, wie man effizientere Anwendungen erstellt und Java relevanter für neue Anwendungsarchitekturen wie serverless macht. Darüber hinaus hoffen wir, dass Quarkus dank seiner Erweiterbarkeit ein ganzes Ökosystem von Java-Erweiterungen schafft, das die Anzahl der Frameworks erheblich erhöht, die nativ in Anwendungen unterstützt werden.

Quelle: habr.com