In der dynamischen Landschaft der modernen Softwareentwicklung sind Microservices zum bevorzugten Architekturansatz geworden. Obwohl diese Methode zahlreiche Vorteile bietet, ist sie nicht ohne Herausforderungen. Probleme wie großer Speicherbedarf, verlängerte Startzeiten und hohe CPU-Auslastung gehen häufig mit herkömmlichen JVM-basierten Diensten einher. Diese Herausforderungen wirken sich nicht nur auf die technischen Aspekte aus, sondern haben auch finanzielle Auswirkungen, die sich erheblich auf die Gesamtkosten für den Betrieb und die Wartung von Softwarelösungen auswirken können.
GraalVM Native Image ist eine Schlüsselfunktion von GraalVM, einer Hochleistungslaufzeit, die Unterstützung für verschiedene Programmiersprachen und Ausführungsmodi bietet. Insbesondere können Sie mit GraalVM Native Image Java-Anwendungen vorab in eigenständige native ausführbare Dateien kompilieren, ohne dass zur Laufzeit eine Java Virtual Machine (JVM) erforderlich ist. Dieser innovative Ansatz führt zu ausführbaren Dateien, die im Vergleich zu ihren herkömmlichen JVM-Gegenstücken nahezu sofortige Startzeiten und einen deutlich geringeren Speicherverbrauch aufweisen. Diese nativen ausführbaren Dateien werden sorgfältig erstellt und enthalten nur die wesentlichen Klassen, Methoden und abhängigen Bibliotheken, die für die Funktionalität der Anwendung unerlässlich sind. Über seine technischen Fähigkeiten hinaus erweist sich GraalVM Native Image als strategische Lösung mit weitreichenden Auswirkungen. Es meistert nicht nur technische Herausforderungen, sondern bietet auch überzeugende finanzielle Argumente. Durch die Erleichterung der Entwicklung effizienter, sicherer und sofort skalierbarer Cloud-nativer Java-Anwendungen leistet GraalVM einen entscheidenden Beitrag zur Optimierung der Ressourcennutzung und zur Förderung der Kosteneffizienz. Im Wesentlichen spielt es eine entscheidende Rolle bei der Steigerung der Leistung und finanziellen Effizienz von Softwarelösungen in modernen, dynamischen Umgebungen.
1. Großer Speicherbedarf
Technische Auswirkungen
Herkömmliche JVM-basierte Dienste verursachen aufgrund des Klassenladens und der Metadaten für geladene Klassen häufig einen erheblichen Speicheraufwand.
Finanzfall
Ein hoher Speicherverbrauch führt zu erhöhten Infrastrukturkosten. Die Eliminierung von Metadaten für geladene Klassen und andere Optimierungen durch GraalVM führen zu einer effizienteren Nutzung von Ressourcen, was zu potenziellen Kosteneinsparungen führt.
2. Verlängerte Startzeiten
Technische Auswirkungen
Kaltstarts in Microservices können zu längeren Reaktionszeiten führen, die Benutzererfahrung beeinträchtigen und möglicherweise zu einer Verschlechterung des Dienstes führen.
Finanzfall
Längere Startzeiten wirken sich nicht nur auf die Benutzerzufriedenheit aus, sondern tragen auch zu höheren Betriebskosten bei. Die Optimierungen von GraalVM, wie die Eliminierung des Klassenladeaufwands und die Vorgenerierung des Image-Heaps während des Builds, reduzieren die Startzeiten drastisch und minimieren möglicherweise die Betriebskosten.
3. Hohe CPU-Auslastung
Technische Auswirkungen
Herkömmliche JVMs beanspruchen während des Startvorgangs häufig CPU-Zyklen für die Profilerstellung und die Just-In-Time-Kompilierung (JIT).
Finanzfall
Eine übermäßige CPU-Auslastung führt zu höheren Kosten für die Cloud-Infrastruktur. Die Vermeidung von Profiling- und JIT-ing-Overhead durch GraalVM trägt direkt zu einem reduzierten CPU-Verbrauch bei, was zu potenziellen Kosteneinsparungen bei der Cloud-Nutzung führt.
Microservices, insbesondere in serverlosen oder containerisierten Umgebungen, sind häufig mit dem Kaltstartproblem konfrontiert, das sich auf die Reaktionszeiten und die Benutzererfahrung auswirkt. GraalVM begegnet dieser Herausforderung durch die Implementierung mehrerer Optimierungen:
1. Kein Klassenladeaufwand
Herkömmliche Java-Anwendungen verlassen sich auf das Laden von Klassen zur Laufzeit, um Klassen dynamisch zu laden und zu verknüpfen. Dieser Prozess verursacht einen Mehraufwand, insbesondere während der Startphase. GraalVM minimiert diesen Overhead durch einen Prozess, der als statische oder AOT-Kompilierung (Ahead-of-Time) bezeichnet wird. Dazu gehört das Vorladen, Verknüpfen und teilweise Initiieren aller Klassen, die die Anwendung benötigt. Daher ist während des Anwendungsstarts kein Laden der Laufzeitklassen erforderlich.
2. Eliminierung von interpretiertem Code
Traditionelle Java Virtual Machines verlassen sich auf einen interpretierten Ausführungsmodus, bevor sie die Just-In-Time-Kompilierung (JIT) anwenden. Dies kann zu Startverzögerungen und erhöhter CPU-Auslastung führen. Native ausführbare Dateien enthalten keinen interpretierten Code, was zusätzlich zu schnelleren Startzeiten beiträgt.
3. Kein Profiling- und JIT-ing-Overhead
GraalVM umgeht die Notwendigkeit, den Just-In-Time-Compiler (JIT) zu starten, und reduziert so die CPU-Auslastung während des Startvorgangs.
4. Bild-Heap-Generierung zur Erstellungszeit
Das native Image-Dienstprogramm von GraalVM ermöglicht die Ausführung von Initialisierungsprozessen für bestimmte Klassen während des Build-Prozesses. Dies führt zur Generierung eines Image-Heaps, der vorinitialisierte Teile enthält, was den Start der Anwendung beschleunigt.
Das native Image-Dienstprogramm von Oracle GraalVM hat gezeigt, dass die Startzeiten fast 100-mal schneller sind als bei herkömmlichen JVM-basierten Anwendungen. Die folgende Grafik veranschaulicht die erhebliche Reduzierung des Laufzeitspeicherbedarfs und zeigt die Effizienz von GraalVM im Vergleich zu HotSpot (Abbildung 1).
Abbildung 1 – Native ausführbare Dateien werden fast sofort gestartet (oracle.com)
GraalVM trägt durch die folgenden Optimierungen zu einem geringeren Speicherbedarf bei:
1. Keine Metadaten für geladene Klassen
GraalVM vermeidet das Speichern von Metadaten für dynamisch geladene Klassen im Nicht-Heap-Speicher. Während des Build-Prozesses werden die erforderlichen Klasseninformationen vorab geladen und verknüpft, wodurch der Bedarf an zusätzlichen Metadaten zur Laufzeit minimiert wird.
2. Keine Profiling-Daten oder JIT-Optimierungen
Da sich der Bytecode bereits im nativen Code befindet, entfällt bei GraalVM die Erfassung von Profilierungsdaten für JIT-Optimierungen, wodurch der Speicheraufwand reduziert wird.
3. Isolationstechnologie
GraalVM führt Isolates ein, eine Technologie, die den Heap in kleinere, unabhängige „Heaps“ unterteilt und so die Effizienz steigert, insbesondere in Anforderungsverarbeitungsszenarien.
Im Allgemeinen verbraucht es bis zu x5-mal weniger Speicher als die Ausführung auf einer JVM (Abbildung 2)
Abbildung 2 – Nativer Speicher für ausführbare Dateien im Vergleich zu Go oder Java HotSpot (oracle.com)
Zusammenfassend lässt sich sagen, dass das native Image-Dienstprogramm von GraalVM eine transformative Lösung für die Herausforderungen von Microservices bietet und Bedenken hinsichtlich der Startzeit, des Speicherbedarfs und der CPU-Auslastung berücksichtigt. Durch die Einführung von GraalVM können Entwickler cloudnative Java-Anwendungen erstellen, die nicht nur effizient und sicher sind, sondern auch ein hervorragendes Benutzererlebnis bieten.
Um Ihren Quarkus-Dienst in ein natives Image zu kompilieren, stehen verschiedene Methoden zur Verfügung. Dieser Artikel geht zwar nicht näher auf den nativen Build-Vorgang von Quarkus ein, bietet aber einen Überblick über die wesentlichen Schritte.
Bevor Sie mit der Erstellung eines nativen Images fortfahren, ist es wichtig, das richtige native Profil in Ihrer pom.xml-Datei einzurichten. Fügen Sie das folgende Profil hinzu:
<profiles>
<profile>
<id>native</id>
<properties>
<quarkus.package.type>native</quarkus.package.type>
</properties>
</profile>
</profiles>
Erstellen einer nativen ausführbaren Datei mit installierter GraalVM
Überprüfen Sie Ihre GraalVM-Version mit dem folgenden Befehl:
./gu info native-image
Dieser Befehl zeigt die installierte GraalVM-Version an:
Downloading: Component catalog from www.graalvm.org
Filename : https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-22.3.0/native-image-installable-svm-java19-linux-amd64-22.3.0.jar
Name : Native Image
ID : native-image
Version : 22.3.0
GraalVM : 22.3.0
Stability: Experimental
Component bundle native-image cannot be installed
- The same component Native Image (org.graalvm.native-image[22.3.0.0/55b341ca1bca5219aafa8ed7c8a2273b81d184dd600d8261c837fc32d2dedae5]) is already installed in version 22.3.0
Und um eine native ausführbare Datei zu erstellen, verwenden Sie:
./mvnw install -Dnative
Diese Befehle generieren eine *-runner-Binärdatei im Zielverzeichnis, sodass Sie die native ausführbare Datei ausführen können:
./target/*-runner
Erstellen einer nativen ausführbaren Datei ohne installierte GraalVM
Wenn die lokale Installation von GraalVM eine Herausforderung darstellt, kann ein In-Container-Build verwendet werden:
./mvnw install -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=graalvm
Dieser Befehl initiiert den Build innerhalb eines Docker-Containers und stellt die erforderliche Image-Datei bereit. Anschließend können Sie die Anwendung starten mit:
./target/*-runner
In Fällen, in denen sich die Erstellung des nativen Images als schwierig erweist, stellt das RedHat-Team eine spezielle Distribution von GraalVM namens Mandrel bereit, die für das Quarkus-Framework entwickelt wurde. Dorn rationalisiert
GraalVM konzentriert sich ausschließlich auf die nativen Image-Funktionen, die für Quarkus-Anwendungen unerlässlich sind. Um Mandrel zu verwenden, befolgen Sie diese Schritte:
Identifizieren Sie die entsprechende Mandrel-Version des Mandrel-Repositorys
Legen Sie die Mandrel-Version in Ihrer application.properties-Datei fest:
quarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:23.0.1.2-Final-java17
3.Führen Sie den Maven-Build-Befehl aus:
./mvnw clean install -Pnative
Für diejenigen, die die manuelle Kontrolle der Containererstellung vorziehen, kann ein mehrstufiger Docker-Build verwendet werden.
FROM quay.io/quarkus/ubi-quarkus-mandrel-builder-image:23.0.1.2-Final-java17 AS build COPY --chown=quarkus:quarkus mvnw /app/mvnw COPY --chown=quarkus:quarkus .mvn /app/.mvn COPY --chown=quarkus:quarkus pom.xml /app/ USER quarkus WORKDIR /app RUN ./mvnw -B org.apache.maven.plugins:maven-dependency-plugin:3.6.1:go-offline COPY src /app/src RUN ./mvnw package -Dnative FROM quay.io/quarkus/quarkus-micro-image:2.0 WORKDIR /app/ COPY --from=build /app/target/*-runner /app/application RUN chmod 775 /app /app/application \ && chown -R 1001 /app \ && chmod -R "g+rwX" /app \ && chown -R 1001:root /app EXPOSE 8080 USER 1001 CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
Diese Docker-Datei orchestriert einen mehrstufigen Build, der zu einem Docker-Image mit Ihrer Quarkus-Anwendung führt. Führen Sie diese Docker-Datei aus, um das Docker-Image zu erstellen, das zur Ausführung Ihrer Quarkus-Anwendung bereit ist.
GraalVM Native Image ist eine leistungsstarke Technologie, die die Art und Weise, wie Sie Java-Microservices entwickeln und bereitstellen, revolutionieren kann. Durch die Einführung von GraalVM Native Image können Sie Microservices erstellen, die:
GraalVM Native Image ist ein wichtiger Faktor für die Cloud-native Java-Entwicklung und kann Ihnen dabei helfen, die Leistung, Skalierbarkeit und Kosteneinsparungen zu erreichen, die Ihr Unternehmen benötigt.
Das obige ist der detaillierte Inhalt vonBeschleunigen Sie Java Microservices mit Quarkus und GraalVM Native Image. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Die Beziehung zwischen Bandbreite und Netzwerkgeschwindigkeit
So aktualisieren Sie Douyin
Der Unterschied zwischen typedef und define
So verwenden Sie die Python-Bibliothek
Thunder VIP-Patch
DJVU in PDF umwandeln
Der Computer ist infiziert und kann nicht eingeschaltet werden
Welcher Ordner ist AppData, der gelöscht werden kann?
