Azure bietet Teams zahlreiche Optionen zum Erstellen und Bereitstellen von Java-Anwendungen. Dieser Artikel enthält Informationen zu allgemeinen Szenarien für Java in Azure sowie allgemeine Planungsvorschläge und Überlegungen.
Apache®, Apache Kafka, Apache Struts, Apache Tomcat und das Flammenlogo sind entweder eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Die Verwendung dieser Markierungen impliziert kein Endorsement durch die Apache Software Foundation.
Plattform
Ermitteln Sie zunächst die Plattform, bevor Sie ein Cloudszenario für Ihre Java-Anwendung auswählen. Von den meisten Java-Anwendungen wird eine der folgenden Plattformen verwendet:
Spring Boot-JAR-Anwendungen
Spring Boot-JAR-Anwendungen werden in der Regel direkt über die Befehlszeile aufgerufen. Sie verarbeiten Webanforderungen. Anstatt sich bei der Verarbeitung von HTTP-Anforderungen auf einen Anwendungsserver zu verlassen, integrieren diese Anwendungen die HTTP-Kommunikation und andere Abhängigkeiten direkt in das Anwendungspaket. Anwendungen dieser Art werden häufig mit Frameworks wie Spring Boot, Dropwizard, Micronaut, MicroProfile und Vert.x erstellt.
Diese Anwendungen werden in Archiven mit der Erweiterung .jar (JAR-Dateien) verpackt.
Spring Cloud-Anwendungen
Der Microservice-Architekturstil ist ein Ansatz für die Entwicklung einer einzelnen Anwendung als Suite mit kleinen Diensten. Diese Dienste werden jeweils als eigener Prozess ausgeführt und kommunizieren über einfache Mechanismen – häufig mit einer HTTP-Ressourcen-API. Diese Dienste basieren auf den Geschäftsfunktionen.
Die Microservices werden mittels automatisierter Prozesse unabhängig voneinander bereitgestellt. Der Aufwand für die zentralisierte Verwaltung ist minimal, und es können verschiedene Programmiersprachen sowie unterschiedliche Speichertechnologien genutzt werden. Dienste dieser Art werden häufig mit Frameworks wie Spring Cloud erstellt.
Diese Dienste werden in mehreren Anwendungen als JAR-Dateien verpackt.
Webanwendungen
Webanwendungen werden in einem Servlet-Container ausgeführt. In einigen Fällen werden Servlet-APIs direkt genutzt. Es kommen aber auch zusätzliche Frameworks mit gekapselten Servlet-APIs zum Einsatz. Beispiele wären etwa Apache Struts, Spring MVC und JavaServer Faces.
Webanwendungen werden in Archiven mit der Erweiterung .war (WAR-Dateien) verpackt.
Jakarta EE-Anwendungen
Jakarta EE-Anwendungen (Jakarta Enterprise Edition) können einige, alle oder keine Elemente von Webanwendungen enthalten. Sie können auch zahlreiche weitere Komponenten enthalten und nutzen, die über die Jakarta EE-Spezifikation definiert sind. Jakarta EE-Anwendungen wurden früher als Java EE-Anwendungen oder J2EE-Anwendungen bezeichnet.
Jakarta EE-Anwendungen können als WAR-Dateien oder als Archive mit der Erweiterung .ear (EAR-Dateien) verpackt sein.
Jakarta EE-Anwendungen müssen auf Anwendungsservern bereitgestellt werden, die mit Jakarta EE kompatibel sind. Beispiele hierfür sind WebLogic, WebSphere, WildFly, GlassFish und Payara.
Anwendungen, die nur auf den Features der Jakarta EE-Spezifikation basieren, können zwischen konformen Anwendungsservern migriert werden. Falls Ihre Anwendung von einem bestimmten Anwendungsserver abhängig ist, müssen Sie ggf. ein Azure-Dienstziel auswählen, an dem Sie den Anwendungsserver hosten können.
Plattformoptionen
Anhand der folgenden Tabelle können Sie potenzielle Plattformen für Ihren Anwendungstyp ermitteln:
| Azure Spring Apps | App Service Java SE | App Service Tomcat | App Service JBoss EAP | Azure Container Apps | AKS | Virtual Machines | |
|---|---|---|---|---|---|---|---|
| Spring Boot-/JAR-Anwendungen | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Spring Cloud-Anwendungen | ✔ | ✔ | ✔ | ✔ | |||
| Webanwendungen | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Jakarta EE-Anwendungen | ✔ | ✔ | ✔ | ||||
| Verfügbarkeit von Azure-Regionen | Details | Details | Details | Details | Details | Details | Details |
Von Azure Kubernetes Service (AKS) und Virtual Machines werden zwar alle Anwendungstypen unterstützt, Ihr Team muss jedoch mehr Aufgaben übernehmen, wie im nächsten Abschnitt beschrieben.
Support-Fähigkeit
Neben den Plattformoptionen müssen für moderne Java-Anwendungen ggf. noch weitere andere Unterstützbarkeitsanforderungen erfüllt werden. Hierzu zählen beispielsweise:
- Batchaufträge oder geplante Aufträge
- Integration in ein virtuelles Netzwerk
- Serverlos
- Containerisierung
Batchaufträge oder geplante Aufträge
Anstatt auf Anforderungen oder Benutzereingaben zu warten, werden einige Anwendungen kurz ausgeführt und nach dem Ausführen einer bestimmten Workload wieder beendet. Diese Aufträge müssen teils nur einmal, teils aber auch in regelmäßigen geplanten Intervallen ausgeführt werden. In lokalen Umgebungen werden diese Aufträge häufig über die cron-Tabelle eines Servers aufgerufen.
Diese Anwendungen werden als JAR-Dateien verpackt.
Hinweis
Wenn für Ihre Anwendung ein Planer wie Spring Batch oder Quartz zum Ausführen von geplanten Aufgaben genutzt wird, sollten diese Aufgaben unbedingt außerhalb der Anwendung ausgeführt werden. Wenn Ihre Anwendung auf mehrere Instanzen in der Cloud skaliert wird, kann der gleiche Auftrag mehrmals ausgeführt werden. Falls für Ihren Planungsmechanismus die lokale Zeitzone des Hosts genutzt wird, kann es beim regionsübergreifenden Skalieren einer Anwendung zu unerwünschtem Verhalten kommen.
Integration in ein virtuelles Netzwerk
Wenn Sie eine Java-Anwendung in Ihrem virtuellen Netzwerk bereitstellen, verfügt der Dienst über ausgehende Abhängigkeiten von Diensten außerhalb des virtuellen Netzwerks. Für die Verwaltung und den Betrieb benötigt Ihr Projekt Zugriff auf bestimmte Ports und vollqualifizierte Domänennamen. Mit virtuellen Azure-Netzwerken können Sie viele Ihrer Azure-Ressourcen in einem Netzwerk platzieren, das nicht über das Internet geroutet werden kann. Die VNet-Integration ermöglicht es Ihren Anwendungen, in einem virtuellen Netzwerk oder über ein virtuelles Netzwerk auf Ressourcen zuzugreifen. Die VNet-Integration ermöglicht keinen privaten Zugriff auf Ihre Anwendungen.
Serverloses Entwicklungsmodell
Das serverlose Entwicklungsmodell ist ein cloudnatives Entwicklungsmodell, mit dem Entwickler Anwendungen ohne Serververwaltung erstellen und ausführen können. Bei serverlosen Anwendungen übernimmt der Cloud-Dienstanbieter automatisch die Bereitstellung, Skalierung und Verwaltung der für die Ausführung des Codes erforderlichen Infrastruktur. Server sind im serverlosen Modell weiterhin vorhanden. Sie werden bei der Anwendungsentwicklung lediglich abstrahiert.
Containerisierung
Als Containerisierung wird das Zusammenfassen von Softwarecode mit allen erforderlichen Komponenten wie Bibliotheken, Frameworks und anderen Abhängigkeiten in Paketen bezeichnet. Die Anwendung wird in einem eigenen Container isoliert.
CI/CD
Continuous Integration und Continuous Delivery (CI/CD) ist eine Methode zur häufigen Bereitstellung von Anwendungen für Kunden durch Integration von Automatisierung in die Phasen der Anwendungsentwicklung. Die wichtigsten Konzepte bei CI/CD sind Continuous Integration, Continuous Delivery und Continuous Deployment. Bei allen Azure-Optionen wird der Großteil der CI/CD-Tools unterstützt. Beispielsweise können Sie Lösungen wie Azure Pipelines oder Jenkins verwenden.
Open-Source-Suchmaschine
Suchvorgänge sind ein integraler Bestandteil jeder Anwendung. Wenn Geschwindigkeit, Leistung und Hochverfügbarkeit entscheidend sind, können Suchvorgänge mit Terabytes und Petabytes an Daten eine Herausforderung darstellen. Planen Sie beim Hosten von Java-Anwendungen in Azure das Hosten Ihrer zugehörigen Solr- und Elasticsearch-Instanzen ein. Alternativ können Sie auch eine Migration zu Azure Cognitive Search in Betracht ziehen.
Big-Data-Tools
Big Data-Tools ermöglichen die Automatisierung des Datenflusses zwischen den Softwaresystemen. Sie unterstützen skalierbare, robuste und optimierte Datenroutinggraphen sowie Systemvermittlungslogik. Sie werden verwendet, um Live-Datenflusspipelines zu erstellen und Anwendungen zu streamen. Informieren Sie über die Verwendung von Nifi und Apache Kafka in Azure, um ggf. Ihre Anforderungen zu erfüllen.
Unterstützbarkeitsoptionen
Anhand der folgenden Tabelle können Sie potenzielle Optionen für Ihren Anwendungstyp ermitteln: Von AKS und Virtual Machines werden alle Anwendungstypen unterstützt, Ihr Team muss jedoch mehr Aufgaben übernehmen.
| Azure Spring Apps | App Service Java SE | App Service Tomcat | App Service JBoss EAP | Azure Container Apps | AKS | Virtual Machines | |
|---|---|---|---|---|---|---|---|
| Batchaufträge oder geplante Aufträge | ✔ | ✔ | ✔ | ✔ | |||
| Integration in ein virtuelles Netzwerk | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Serverlos | ✔ | ✔ | ✔ | ✔ | |||
| Containerisierung | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Verfügbarkeit von Azure-Regionen | Details | Details | Details | Details | Details | Details | Details |
Sehen Sie sich auch die folgende Entscheidungsstruktur an:
Laden Sie eine Visio-Datei mit dieser Architektur herunter.
Erstellen oder Migrieren von Java-Anwendungen
Ermitteln Sie die Java-Plattform Ihrer Anwendungen, um die Java-Anwendungen zu erstellen oder zu migrieren. Einige beliebte Plattformen sind Java SE, Jakarta EE und MicroProfile.
Java SE
Java Platform, Standard Edition (Java SE) ist eine Computingplattform für die Entwicklung und Bereitstellung von portierbarem Code für Desktop- und Serverumgebungen. Zu beliebten Projekten, die auf Java SE basieren, zählen unter anderem Spring Boot, Spring Cloud, Spring Framework und Apache Tomcat.
Jakarta EE
Jakarta EE ist die Open Source-Zukunft von cloudnativem Java für Unternehmen. Hierbei handelt sich um eine Reihe von Spezifikationen, die Java SE um Unternehmensfeatures wie verteiltes Computing und Webdienste erweitern. Jakarta EE-Anwendungen führen Referenzruntimes aus. Diese Runtimes können Microservices oder Anwendungsserver sein. Sie kümmern sich um Transaktionen, Sicherheit, Skalierbarkeit, Parallelität und die Verwaltung der von der Anwendung bereitgestellten Komponenten.
MicroProfile
Das MicroProfile-Projekt bietet eine Sammlung von Spezifikationen, die Entwickler bei der Erstellung cloudnativer Microservices für Enterprise Java unterstützen. Quarkus und Open Liberty sind beliebte Implementierungen von MicroProfile.
Zusammenfassung zur Erstellung oder Migration
Die folgende Tabelle enthält nach Anwendungstyp und Azure-Dienst aufgeschlüsselte Erstellungs- bzw. Migrationsinformationen:
| type | Java SE | MicroProfile | Jakarta SE | |
|---|---|---|---|---|
| Virtueller Computer | IaaS | ✔ | ✔ | ✔ |
| VMware Tanzu | IaaS | ✔ | ||
| Azure Kubernetes Service | Container | ✔ | ✔ | ✔ |
| Red Hat OpenShift | Container | ✔ | ✔ | ✔ |
| Azure-Container-App | PaaS | ✔ | ✔ | |
| JBoss EAP | PaaS-App-Dienst | ✔ | ✔ | |
| Apache Tomcat | PaaS-App-Dienst | ✔ | ||
| Java SE | PaaS-App-Dienst | ✔ | ✔ | |
| Azure Spring Apps | PaaS | ✔ |
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Asir Vedamuthu Selvasingh | Principal Program Manager
- Hang Wang | Product Manager
- Xinyi Zhang | Principal PM Manager
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Übersicht über Azure Container Apps
- Azure Kubernetes Service
- Azure Spring Apps-Dokumentation
- Azure Virtual Network-Integration
- Virtuelle Computer in Azure