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:
- Aplikacje Spring:
- Aplikacje Java EE
- Aplikacje sieci Web
- Batch/zaplanowane zadania
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 Service Java SE |
Aplikacja Service Tomcat |
Aplikacja Service JBoss EAP |
Azure Spring Aplikacje |
Azure Container Apps | AKS | Wirtualne Maszyny |
|---|---|---|---|---|---|---|---|
| Aplikacje Spring Boot/JAR | ✔ | ||||||
| Aplikacje Spring Cloud | ✔ | ✔ | ✔ | ✔ | |||
| Aplikacje sieci Web | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Aplikacje Java EE | ✔ | ✔ | ✔ | ||||
| Komercyjne serwery aplikacji (np. Oracle WebLogic Server lub IBM WebSphere) |
✔ | ✔ | ✔ | ||||
| Długoterminowa trwałość lokalnego systemu plików | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Klastrowanie na poziomie serwera aplikacji | ✔ | ✔ | ✔ | ||||
| Batch/zaplanowane zadania | ✔ | ✔ | ✔ | ✔ | |||
| Integracja z siecią wirtualną/Połączenie ivity | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Dostępność w regionach świadczenia usługi Azure | Szczegóły | 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ą 
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 Service |
Azure Spring Aplikacje |
Azure Kontener Aplikacje |
AKS | Wirtualne Maszyny |
|---|---|---|---|---|---|
| Aktualizowanie bibliotek (w tym korygowanie luk w zabezpieczeniach) |
👉 | 👉 | 👉 | 👉 | 👉 |
| Aktualizowanie serwera aplikacji (w tym korygowanie luk w zabezpieczeniach) |
|
|
👉 | 👉 | 👉 |
| Aktualizowanie środowiska uruchomieniowego Java (w tym korygowanie luk w zabezpieczeniach) |
|
|
👉 | 👉 | 👉 |
| Wyzwalanie aktualizacji platformy Kubernetes (wykonywane przez platformę Azure za pomocą wyzwalacza ręcznego) |
Brak | |
|
👉 | Brak |
| Odzyskiwanie po awarii | |
|
👉 | 👉 | |
| 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) |
|
|
|
1 |
👉 |
| Wykrywanie i ponowne uruchamianie wystąpień zakończonych niepowodzeniem | |
|
|
|
👉 |
| Implementowanie opróżniania i stopniowego ponownego uruchamiania w celu zainstalowania aktualizacji | |
|
|
|
👉 |
| Zarządzanie infrastrukturą | |
|
👉 | 👉 | 👉 |
| 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 Wybieranie rozwiązania do łączenia 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.
Jeśli chcesz zmigrować aplikację internetową na serwerze Tomcat do usługi Azure Spring Apps, najpierw przekonwertuj aplikację na aplikacje Spring Cloud, a następnie postępuj zgodnie ze wskazówkami podanymi poniżej.
| → docelowa Typ aplikacji = |
Aplikacja Service Java SE |
Aplikacja Service Tomcat |
Aplikacja Service JBoss EAP |
Azure Kontener Aplikacje |
Azure Spring Aplikacje |
AKS | Wirtualne Maszyny |
|---|---|---|---|---|---|---|---|
| Spring Boot / Aplikacje JAR |
Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | wytyczne | Brak | Brak |
| Spring Cloud / Zastosowania |
Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | wytyczne | wytyczne planowane |
wytyczne planowane |
| Aplikacje sieci Web na serwerze Tomcat |
Nie dotyczy | wytyczne | Nie dotyczy | wytyczne | 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 Service Java SE |
Aplikacja Service Tomcat |
Aplikacja Service JBoss EAP |
Azure Kontener Aplikacje |
Azure Spring Aplikacje |
AKS | Wirtualne Maszyny |
|---|---|---|---|---|---|---|---|
| WildFly / JBoss AS |
Brak | Brak | wytyczne | Brak | Brak | wytyczne | wytyczne planowane |
| Oracle WebLogic Server | Brak | Brak | wytyczne | Brak | Brak | wytyczne | wytyczne |
| IBM WebSphere | Brak | Brak | wytyczne | Brak | Brak | wytyczne | wytyczne planowane |
| Red Hat JBoss EAP | Brak | Brak | wytyczne | Brak | Brak | wytyczne | wytyczne |
Zobacz też
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla