Udostępnij za pośrednictwem


Migrowanie aplikacji Java na platformę Azure

Ten artykuł zawiera omówienie zalecanych strategii migracji aplikacji Java na platformę Azure.

Te wskazówki dotyczące migracji opracowano w celu omówienia typowych scenariuszy z użyciem języka Java na platformie Azure i zapewnienia ogólnych sugestii dotyczących planowania. Jeśli chcesz omówić konkretny scenariusz migracji aplikacji Java z zespołem platformy Microsoft Java na platformie Azure, wypełnij poniższy kwestionariusz, a przedstawiciel skontaktuje się z Tobą.

Identyfikowanie typu aplikacji

Przed wybraniem lokalizacji docelowej w chmurze dla aplikacji Java musisz zidentyfikować typ aplikacji. Większość aplikacji Java ma jeden z następujących typów:

Te typy zostały opisane w poniższych sekcjach.

Aplikacje Spring Boot/JAR

Wiele nowszych aplikacji wywołuje się bezpośrednio z poziomu wiersza polecenia. Aplikacje te nadal obsługują żądania internetowe, ale zamiast polegać na serwerze aplikacji zapewniającym obsługę żądań HTTP, dołączają komunikację HTTP i wszystkie pozostałe zależności bezpośrednio do pakietu aplikacji. Tego rodzaju aplikacje są często kompilowane za pomocą struktur, takich jak Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x itd.

Aplikacje te są pakowane w archiwa z rozszerzeniem JAR (pliki JAR).

Aplikacje Spring korzystające z modułów oprogramowania pośredniczącego Spring Cloud

Styl architektury mikrousług to podejście do tworzenia pojedynczej aplikacji jako zestawu małych usług. Każda usługa działa we własnym procesie i komunikuje się przy użyciu uproszczonych mechanizmów, często interfejsu API zasobów HTTP. Usługi te są kompilowane w oparciu o funkcje biznesowe i niezależnie wdrażane przez całkowicie zautomatyzowane maszyny wdrożeniowe. Istnieje minimum scentralizowanego zarządzania tymi usługami, które mogą być napisane w różnych językach programowania i korzystać z różnych technologii magazynowania danych. Tego rodzaju usługi są często kompilowane za pomocą struktur, takich jak platforma Spring Cloud.

Usługi te są pakowane w wiele aplikacji z rozszerzeniem JAR (pliki JAR).

Aplikacje Java EE

Aplikacje Java EE (nazywane również aplikacjami J2EE lub ostatnio aplikacjami Jakarta EE) mogą zawierać niektóre, wszystkie lub żadne elementy aplikacji internetowych. Te aplikacje mogą również zawierać i wykorzystywać wiele innych składników zgodnie ze specyfikacją EE Dżakarta.

Aplikacje Java EE można pakować jako archiwa z rozszerzeniem EAR (pliki EAR) lub jako archiwa z rozszerzeniem WAR (pliki WAR).

Aplikacje Java EE muszą być wdrażane na serwerach aplikacji zgodnych ze standardem Java EE (takich jak Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara i inne).

Aplikacje polegające tylko na funkcjach udostępnianych przez specyfikację Java EE (tzn. aplikacje niezależne od serwera aplikacji) można migrować z jednego zgodnego serwera aplikacji na inny. Jeśli aplikacja jest zależna od określonego serwera aplikacji, może być konieczne wybranie lokalizacji docelowej usługi platformy Azure pozwalającej na hostowanie tego serwera aplikacji.

Aplikacje sieci Web

Aplikacje internetowe działają wewnątrz kontenera Servlet. Niektóre z tych aplikacji używają bezpośrednio interfejsów API serwletów, a wiele z nich korzysta z innych struktur, które hermetyzują interfejsy API serwletów, takie jak Apache Struts, Spring MVC, JavaServer Faces (JSF) i inne.

Aplikacje internetowe są pakowane w archiwa z rozszerzeniem WAR (pliki WAR).

Batch/zaplanowane zadania

Niektóre aplikacje są przeznaczone do uruchamiania na krótko, wykonywania określonego obciążenia, a następnie kończenia pracy, a nie do czekania na żądania lub wprowadzenie informacji przez użytkownika. Czasami takie zadania muszą być uruchamiane jednokrotnie lub w regularnych, zaplanowanych odstępach czasu. W środowiskach lokalnych tego rodzaju zadania są często wywoływane z pliku crontab serwera.

Aplikacje te są pakowane w archiwa z rozszerzeniem JAR (pliki JAR).

Uwaga

Jeśli aplikacja uruchamia zaplanowane zadania przy użyciu harmonogramu (np. Spring Batch lub Quartz), zdecydowanie zalecamy faktoryzację takich zadań, aby można było uruchamiać je poza aplikacją. Jeśli aplikacja jest skalowana na wiele wystąpień w chmurze, to samo zadanie zostanie uruchomione więcej niż raz. Ponadto jeśli mechanizm planowania używa lokalnej strefy czasowej hosta, podczas skalowania aplikacji na różne regiony może wystąpić niepożądane zachowanie.

Wybieranie lokalizacji docelowej usługi platformy Azure

W poniższych sekcjach pokazano, które lokalizacje docelowe usługi spełniają wymagania aplikacji oraz jakie nakładają obowiązki.

Siatka opcji hostingu

Użyj poniższej siatki, aby zidentyfikować potencjalne miejsca docelowe dla typu aplikacji. Jak widać, usługa Azure Kubernetes Service (AKS) i usługa Azure Virtual Machines obsługują wszystkie typy aplikacji, ale wymagają od zespołu podjęcia większej odpowiedzialności, jak pokazano w następnej sekcji.

→ docelowa

Typ aplikacji =
Aplikacja
Usługa
Java SE
Aplikacja
Usługa
Tomcat
Aplikacja
Usługa
JBoss EAP
Azure Container Apps AKS Wirtualne
Maszyny
Aplikacje Spring Boot/JAR
Aplikacje Spring Cloud
Aplikacje internetowe (WAR)
Aplikacje Java EE (WAR | EAR)
Komercyjne serwery aplikacji
(np. Oracle WebLogic Server lub IBM WebSphere)
Klastrowanie na poziomie serwera aplikacji
Batch/zaplanowane zadania
Integracja z siecią wirtualną/łączność hybrydowa
Dostępność w regionach świadczenia usługi Azure Szczegóły Szczegóły Szczegóły Szczegóły Szczegóły Szczegóły

Siatka stałych obowiązków

Poniższa siatka umożliwia zrozumienie obowiązków każdej lokalizacji docelowej w zespole po migracji.

Zadania wskazane za pomocą Azure usługi są zarządzane w całości lub głównie przez platformę Azure. Twój zespół jest odpowiedzialny na stałe za zadania wskazane za pomocą 👉polecenia . Zalecamy zaimplementowanie niezawodnego, wysoce zautomatyzowanego procesu do realizacji wszystkich obowiązków tego typu.

Uwaga

Nie jest to wyczerpująca lista obowiązków.

→ docelowa

Zadanie =
Aplikacja
Usługa
Azure
Kontener
Aplikacje
AKS Wirtualne
Maszyny
Aktualizowanie bibliotek
(w tym korygowanie luk w zabezpieczeniach)
👉 👉 👉 👉
Aktualizowanie serwera aplikacji
(w tym korygowanie luk w zabezpieczeniach)
Azure 👉 👉 👉
Aktualizowanie środowiska uruchomieniowego Java
(w tym korygowanie luk w zabezpieczeniach)
Azure 👉 👉 👉
Wyzwalanie aktualizacji platformy Kubernetes
(wykonywane przez platformę Azure za pomocą wyzwalacza ręcznego)
Nie dotyczy Azure 👉 Nie dotyczy
Odzyskiwanie po awarii Azure 👉 👉 Azure
Uzgadnianie zmian w interfejsie API platformy Kubernetes, które nie są zgodne z poprzednimi wersjami Brak 👉 👉 Brak
Aktualizowanie podstawowego obrazu kontenera
(w tym korygowanie luk w zabezpieczeniach)
Brak 👉 👉 Brak
Aktualizowanie systemu operacyjnego
(w tym korygowanie luk w zabezpieczeniach)
Azure Azure Azure1 👉
Wykrywanie i ponowne uruchamianie wystąpień zakończonych niepowodzeniem Azure Azure Azure 👉
Implementowanie opróżniania i stopniowego ponownego uruchamiania w celu zainstalowania aktualizacji Azure Azure Azure 👉
Zarządzanie infrastrukturą Azure 👉 👉 👉
Monitorowanie alertów i zarządzanie nimi 👉 👉 👉 👉

1 Niektóre aktualizacje zabezpieczeń mogą wymagać ponownego uruchomienia węzła, które nie są wykonywane automatycznie. Aby uzyskać więcej informacji, zobacz Stosowanie aktualizacji zabezpieczeń i jądra do węzłów systemu Linux w usłudze Azure Kubernetes Service (AKS).

Jeśli w ramach aplikacji wdrażasz kontener serwletu (np. Spring Boot), traktuj go jak bibliotekę, co oznacza, że zawsze ponosisz za niego odpowiedzialność.

Zapewnianie łączności lokalnej

Jeśli aplikacja wymaga dostępu do dowolnych usług lokalnych, musisz aprowizować jedną z usług łączności platformy Azure. Aby uzyskać więcej informacji, zobacz Łączenie sieci lokalnej z platformą Azure. Możesz również przeprowadzić refaktoryzację aplikacji, aby korzystać z publicznie dostępnych interfejsów API uwidacznianych przez Twoje zasoby lokalne.

Ten proces należy wykonać przed rozpoczęciem migracji.

Bieżąca pojemność i użycie zasobów magazynu

Zapisz składniki sprzętowe bieżących serwerów produkcyjnych, a także średnią i szczytową liczbą żądań oraz użycie zasobów. Informacje te będą potrzebne do aprowizacji zasobów w lokalizacji docelowej usługi.

Wskazówki dotyczące migracji

Poniższe siatki umożliwiają znajdowanie wskazówek dotyczących migracji według typu aplikacji i lokalizacji docelowej usługi platformy Azure.

Aplikacje Java

W poniższych wierszach możesz znaleźć typ aplikacji Java i kolumny zawierające lokalizację docelową usługi platformy Azure, w której będzie hostowana Twoja aplikacja.

Jeśli chcesz zmigrować aplikację JBoss EAP do serwera Tomcat w usłudze App Service, najpierw przekonwertuj aplikację Java EE na aplikację Java Web Apps (servlets) działającą na serwerze Tomcat, a następnie postępuj zgodnie ze wskazówkami podanymi poniżej.

→ docelowa

Typ aplikacji =
Aplikacja
Usługa
Java SE
Aplikacja
Usługa
Tomcat
Aplikacja
Usługa
JBoss EAP
Azure
Kontener
Aplikacje
AKS Wirtualne
Maszyny
Spring Boot /
Aplikacje JAR
Brak NIE DOTYCZY NIE DOTYCZY NIE DOTYCZY NIE DOTYCZY Brak
Spring Cloud /
Zastosowania
Brak NIE DOTYCZY NIE DOTYCZY Brak wytyczne
planowane
wytyczne
planowane
Aplikacje sieci Web
na serwerze Tomcat
Nie dotyczy wytyczne Nie dotyczy wytyczne wytyczne wytyczne
planowane

Aplikacje Java EE

W poniższych wierszach możesz znaleźć typ aplikacji Java EE działającej na określonym serwerze aplikacji. W kolumnach znajdziesz lokalizację docelową usługi platformy Azure, w której będzie hostowana Twoja aplikacja.

→ docelowa

Serwer aplikacji — —
Aplikacja
Usługa
Java SE
Aplikacja
Usługa
Tomcat
Aplikacja
Usługa
JBoss EAP
Azure
Kontener
Aplikacje
AKS Wirtualne
Maszyny
WildFly /
JBoss AS
Brak Brak wytyczne Nie dotyczy wytyczne wytyczne
planowane
Oracle WebLogic Server Brak Brak wytyczne Nie dotyczy wytyczne wytyczne
IBM WebSphere Brak Brak wytyczne Nie dotyczy wytyczne wytyczne
planowane
Red Hat JBoss EAP Brak Brak wytyczne Nie dotyczy wytyczne wytyczne

Zobacz też