Migrieren von Java-Anwendungen zu Azure
Dieser Artikel enthält eine Übersicht über empfohlene Strategien für die Migration von Java-Anwendungen zu Azure.
Dieser Migrationsleitfaden wurde für gängige Szenarien mit Java in Azure konzipiert und enthält allgemeine Planungsvorschläge und -aspekte. Wenn Sie ein bestimmtes Java-App-Migrationsszenario mit dem Microsoft Java in Azure-Team besprechen möchten, füllen Sie den folgenden Fragebogen aus, und ein Vertreter kontaktiert Sie.
Identifizieren des Anwendungstyps
Bevor Sie für Ihre Java-Anwendung ein Cloudziel auswählen, müssen Sie den Anwendungstyp ermitteln. Bei den meisten Java-Anwendungen handelt es sich um einen der folgenden Typen:
- Federanwendungen:
- Java EE-Anwendungen
- Webanwendungen
- Batchaufträge/Geplante Aufträge
Diese Anwendungstypen werden in den folgenden Abschnitten beschrieben.
Spring Boot-/JAR-Anwendungen
Viele neuere Anwendungen werden direkt über die Befehlszeile aufgerufen. Mit diesen Anwendungen werden auch weiterhin Webanforderungen verarbeitet. Aber anstatt den Anwendungsserver für die Verarbeitung von HTTP-Anforderungen zu nutzen, werden die HTTP-Kommunikation und alle anderen Abhängigkeiten direkt in das Anwendungspaket eingebunden. Anwendungen dieser Art werden häufig mit Frameworks erstellt, z. B. Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x und anderen.
Diese Anwendungen werden in Archiven mit der Erweiterung .jar (JAR-Dateien) angeordnet.
Spring-Anwendungen, die Spring Cloud Middleware-Module verwenden
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 und können über vollständig automatisierte Prozesse unabhängig voneinander bereitgestellt werden. Es gibt ein minimum an zentralisierter Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen geschrieben und verschiedene Datenspeichertechnologien verwendet werden können. Dienste dieser Art werden häufig mit Frameworks, z. B. Spring Cloud, erstellt.
Die Dienste werden in mehreren Anwendungen mit der Erweiterung .jar (JAR-Dateien) angeordnet.
Java EE-Anwendungen
Java EE-Anwendungen (auch als J2EE-Anwendungen bezeichnet oder, vor kurzem, Jakarta EE-Anwendungen) können einige, alle oder keines der Elemente von Webanwendungen enthalten. Diese Anwendungen können auch viele weitere Komponenten enthalten und verbrauchen, wie in der Spezifikation von Jakarta EE definiert.
Java EE-Anwendungen können in Archiven mit der Erweiterung .ear (EAR-Dateien) oder .war (WAR-Dateien) gepackt werden.
Java EE-Anwendungen müssen auf Java EE-kompatiblen Anwendungsservern bereitgestellt werden (z. B. Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara und andere).
Anwendungen, die nur auf den Features der Java EE-Spezifikation basieren (also vom App-Server unabhängige Anwendungen), können von einem konformen Anwendungsserver zu einem anderen migriert werden. Falls Ihre Anwendung von einem bestimmten Anwendungsserver abhängig ist (App-Server-Abhängigkeit), müssen Sie ggf. ein Azure-Dienstziel auswählen, auf dem Sie den Anwendungsserver hosten können.
Webanwendungen
Webanwendungen werden in einem Servlet-Container ausgeführt. Einige dieser Anwendungen verwenden Servlet-APIs direkt, während viele andere Frameworks verwenden, die Servlet-APIs kapseln, z. B. Apache Struts, Spring MVC, JavaServer Faces (JSF) und andere.
Webanwendungen werden in Archiven mit der Erweiterung .war (WAR-Dateien) angeordnet.
Batchaufträge/Geplante Aufträge
Für einige Anwendungen ist vorgesehen, dass sie nur kurz ausgeführt werden, eine bestimmte Workload ausführen und dann beendet werden, anstatt auf Anforderungen oder Benutzereingaben zu warten. 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 das crontab-Element eines Servers aufgerufen.
Diese Anwendungen werden in Archiven mit der Erweiterung .jar (JAR-Dateien) angeordnet.
Hinweis
Wenn für Ihre Anwendung ein Planer (z. B. Spring Batch oder Quartz) zum Ausführen von geplanten Aufgaben genutzt wird, empfehlen wir Ihnen dringend eine Vorgehensweise, bei der diese Aufgaben außerhalb der Anwendung ausgeführt werden. Wenn Ihre Anwendung auf mehrere Instanzen in der Cloud skaliert wird, wird derselbe Auftrag mehr als einmal ausgeführt. Falls für Ihren Planungsmechanismus die lokale Zeitzone des Hosts genutzt wird, kann es außerdem zu unerwünschtem Verhalten kommen, wenn Sie Ihre Anwendung regionsübergreifend skalieren.
Auswählen des Azure-Dienstziels
In den folgenden Abschnitten wird veranschaulicht, welche Dienstziele Ihre Anwendungsanforderungen erfüllen und welche Zuständigkeiten damit verbunden sind.
Übersicht über die Hostingoptionen
Anhand der folgenden Übersicht können Sie potenzielle Ziele für Ihren Anwendungstyp ermitteln. Wie Sie sehen können, unterstützen Azure Kubernetes Service (AKS) und Azure Virtual Machines alle Anwendungstypen, aber sie erfordern, dass Ihr Team mehr Verantwortlichkeiten übernimmt, wie im nächsten Abschnitt gezeigt.
| Ziel-→ Anwendungstyp – – |
App Service Java SE |
App Service Tomcat |
App Service JBoss EAP |
Azure Spring Apps |
Azure Container Apps | AKS | Virtual Machines |
|---|---|---|---|---|---|---|---|
| Spring Boot-/JAR-Anwendungen | ✔ | ||||||
| Spring Cloud-Anwendungen | ✔ | ✔ | ✔ | ✔ | |||
| Webanwendungen | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Java EE-Anwendungen | ✔ | ✔ | ✔ | ||||
| Kommerzielle Anwendungsserver (z. B. Oracle WebLogic Server oder IBM WebSphere) |
✔ | ✔ | ✔ | ||||
| Langfristige Aufbewahrung im lokalen Dateisystem | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Clustering auf Anwendungsserverebene | ✔ | ✔ | ✔ | ||||
| Batchaufträge/Geplante Aufträge | ✔ | ✔ | ✔ | ✔ | |||
| VNET-Integration/Hybridkonnektivität | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Verfügbarkeit von Azure-Regionen | Details | Details | Details | Details | Details | Details | Details |
Raster zu laufenden Zuständigkeiten
Ermitteln Sie anhand des folgenden Rasters, welche Zuständigkeiten sich nach der Migration in Bezug auf die einzelnen Ziele für Ihr Team ergeben.
Die angegebenen 
Aufgaben werden vollständig oder hauptsächlich von Azure verwaltet. Ihr Team ist kontinuierlich für die mit 👉ihnen angegebenen Aufgaben verantwortlich. Wir empfehlen Ihnen, zur Erfüllung dieser Zuständigkeiten einen stabilen, stark automatisierten Prozess zu implementieren.
Hinweis
Hinweis: Es handelt sich hierbei nicht um eine umfassende Liste mit Zuständigkeiten.
| Ziel-→ Vorgang – |
App Service |
Azure Spring Apps |
Azure Container Apps |
AKS | Virtual Machines |
|---|---|---|---|---|---|
| Aktualisieren von Bibliotheken (einschließlich Behebung von Sicherheitsrisiken) |
👉 | 👉 | 👉 | 👉 | 👉 |
| Aktualisieren des Anwendungsservers (einschließlich Behebung von Sicherheitsrisiken) |
|
|
👉 | 👉 | 👉 |
| Aktualisieren der Java Runtime (einschließlich Behebung von Sicherheitsrisiken) |
|
|
👉 | 👉 | 👉 |
| Auslösen von Kubernetes-Updates (durchgeführt von Azure per manuellem Trigger) |
– | |
|
👉 | – |
| Notfallwiederherstellung | |
|
👉 | 👉 | |
| Abstimmen von nicht abwärtskompatiblen Änderungen der Kubernetes-API | – | |
👉 | 👉 | – |
| Aktualisieren des Container-Basisimages (einschließlich Behebung von Sicherheitsrisiken) |
– | |
👉 | 👉 | – |
| Aktualisieren des Betriebssystems (einschließlich Behebung von Sicherheitsrisiken) |
|
|
|
1 |
👉 |
| Erkennen und Neustarten von Instanzen mit Fehlern | |
|
|
|
👉 |
| Implementieren des Ausgleichs und parallelen Neustarts für Updates | |
|
|
|
👉 |
| Infrastrukturverwaltung | |
|
👉 | 👉 | 👉 |
| Überwachung und Warnungsverwaltung | 👉 | 👉 | 👉 | 👉 |
1 Einige Sicherheitsupdates erfordern möglicherweise Knotenneustarts, die nicht automatisch ausgeführt werden. Weitere Informationen finden Sie unter Anwenden von Sicherheits- und Kernelupdates auf Linux-Knoten in Azure Kubernetes Service (AKS).For more information, see Apply security and kernel updates to Linux nodes in Azure Kubernetes Service (AKS).
Wenn Sie den Servlet-Container (z. B. Spring Boot) als Teil Ihrer Anwendung bereitstellen, sollten Sie diesen als Bibliothek ansehen. Er liegt somit in Ihrem Zuständigkeitsbereich.
Sicherstellen der lokalen Konnektivität
Wenn Ihre Anwendung auf Ihre lokalen Dienste zugreifen muss, müssen Sie einen der Konnektivitätsdienste von Azure bereitstellen. Weitere Informationen finden Sie unter Auswählen einer Lösung zum Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure. Alternativ müssen Sie Ihre Anwendung so umgestalten, dass öffentlich zugängliche APIs genutzt werden, die von Ihren lokalen Ressourcen verfügbar gemacht werden.
Sie sollten diesen Vorgang durchführen, bevor Sie mit der Migration beginnen.
Bestand: Aktuelle Kapazität und Ressourcennutzung
Dokumentieren Sie die Hardware der aktuellen Produktionsserver sowie die durchschnittliche und maximale Anzahl von Anforderungen und die Ressourcennutzung. Sie benötigen diese Informationen, um Ressourcen auf dem Dienstziel bereitzustellen.
Hinweise zur Migration
Verwenden Sie die folgenden Raster, um Informationen zur Migration nach Anwendungstyp und gewünschtem Azure-Dienstziel zu erhalten.
Java-Anwendungen
Ermitteln Sie in den folgenden Zeilen Ihren Java-Anwendungstyp und die Spalten, um das Azure-Dienstziel zu finden, auf dem Ihre Anwendung gehostet wird.
Wenn Sie eine JBoss EAP-App zu Tomcat unter App Service migrieren möchten, sollten Sie zuerst die Java EE-App in Java-Web-Apps (Servlets) konvertieren, die unter Tomcat ausgeführt werden, und dann den unten angegebenen Leitfaden befolgen.
Wenn Sie eine Web-App auf Tomcat zu Azure Spring Apps migrieren möchten, konvertieren Sie die App zuerst in Spring Cloud-Anwendungen, und befolgen Sie dann die unten angegebenen Anleitungen.
| Ziel-→ Anwendungstyp – – |
App Service Java SE |
App Service Tomcat |
App Service JBoss EAP |
Azure Container Apps |
Azure Spring Apps |
AKS | Virtual Machines |
|---|---|---|---|---|---|---|---|
| Spring Boot-/ JAR-Anwendungen |
– | – | – | – | Leitfaden | – | – |
| Spring Cloud/ applications |
– | – | – | – | Leitfaden | Leitfaden Geplant |
Leitfaden Geplant |
| Webanwendungen unter Tomcat |
Nicht zutreffend | Leitfaden | Nicht zutreffend | Leitfaden | Leitfaden | Leitfaden | Leitfaden Geplant |
Java EE-Anwendungen
Ermitteln Sie anhand der unten angegebenen Zeilen den Typ Ihrer Java EE-Anwendung, die auf einem bestimmten App-Server ausgeführt wird. In den Spalten finden Sie das Azure-Dienstziel, auf dem Ihre Anwendung gehostet wird.
| Ziel-→ App-Server \ |
App Service Java SE |
App Service Tomcat |
App Service JBoss EAP |
Azure Container Apps |
Azure Spring Apps |
AKS | Virtual Machines |
|---|---|---|---|---|---|---|---|
| WildFly/ JBoss AS |
– | – | Leitfaden | – | – | Leitfaden | Leitfaden Geplant |
| Oracle WebLogic Server | – | – | Leitfaden | – | – | Leitfaden | Leitfaden |
| IBM WebSphere | – | – | Leitfaden | – | – | Leitfaden | Leitfaden Geplant |
| Red Hat JBoss EAP | – | – | Leitfaden | – | – | Leitfaden | Leitfaden |
Siehe auch
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für