Migrace aplikací v jazyce Java do Azure
Tento článek obsahuje přehled doporučených strategií pro migraci aplikací v Javě do Azure.
Tyto pokyny k migraci se zaměřují na hlavní scénáře pro Javu v Azure a uvádějí nejdůležitější aspekty a doporučení pro plánování. Pokud chcete probrat konkrétní scénář migrace aplikací v Javě s týmem Microsoft Java v Azure, vyplňte následující dotazník a zástupce vás bude kontaktovat.
Určení typu aplikace
Před výběrem cloudového cíle pro vaši aplikaci vytvořenou v jazyce Java budete muset určit její typ. Většina aplikací v jazyce Java patří do jednoho z následujících typů:
- Aplikace Spring:
- Aplikace Java EE
- Webové aplikace
- Dávkové / naplánované úlohy
Tyto typy jsou popsané v následujících částech.
Aplikace Spring Boot / JAR
Mnohé novější aplikace se vyvolávají přímo z příkazového řádku. Tyto aplikace sice zpracovávají webové požadavky, ale místo toho, aby při obsluze požadavků HTTP spoléhaly na aplikační server, začleňují komunikaci přes protokol HTTP a všechny další závislosti přímo do balíčku aplikace. Takové aplikace jsou často vytvořeny pomocí platforem, mezi které patří Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x a další.
Tyto aplikace jsou zabalené do archivů s příponou .jar (souborů JAR).
Aplikace Spring, které používají moduly middlewaru Spring Cloud
Styl architektury mikroslužeb je přístup k vývoji jedné aplikace jako sady malých služeb. Každá služba běží ve vlastním procesu a komunikuje pomocí jednoduchých mechanismů, často rozhraní API prostředků HTTP. Tyto služby jsou založené na obchodních funkcích a nezávisle nasaditelné pomocí plně automatizovaného mechanismu nasazení. Existuje úplné minimum centralizované správy těchto služeb, které mohou být napsané v různých programovacích jazycích a používají různé technologie úložiště dat. Takové služby jsou často vytvářeny pomocí platforem, jako je Spring Cloud.
Tyto služby jsou zabalené do několika aplikací s příponou .jar (souborů JAR).
Aplikace Java EE
Aplikace Java EE (označované také jako aplikace J2EE nebo nedávno aplikace Jakarta EE) mohou obsahovat některé, všechny nebo žádné prvky webových aplikací. Tyto aplikace mohou také obsahovat a využívat mnoho dalších komponent definovaných specifikací Jakarta EE.
Aplikace Java EE mohou být zabaleny jako archivy s příponou .ear (soubory EAR) nebo jako archivy s příponou .war (soubory WAR).
Aplikace Java EE musí být nasazené na aplikační servery kompatibilní s Javou EE (například Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara a další).
Aplikace, které spoléhají jen na funkce poskytované specifikací Java EE (což jsou aplikace nezávislé na aplikačním serveru) lze migrovat z jednoho vyhovujícího aplikačního serveru na jiný. Pokud je vaše aplikace závislá na konkrétním aplikačním serveru, budete zřejmě muset vybrat cílovou službu Azure, která umožňuje hostovat tento aplikační server.
Webové aplikace
Webové aplikace běží v kontejneru servletu. Některé z těchto aplikací používají rozhraní API servletu přímo, zatímco řada z nich používá jiné architektury, které zapouzdřují rozhraní API servletu, jako jsou Apache Struts, Spring MVC, JavaServer Faces (JSF) a další.
Webové aplikace jsou zabalené do archivů s příponou .war (souborů WAR).
Dávkové / naplánované úlohy
Některé aplikace mají běžet chvíli, spustit konkrétní úlohu a pak se ukončit, přičemž nečekají na žádosti nebo vstup uživatele. Někdy je potřeba tyto úlohy spustit jednou nebo v pravidelných naplánovaných intervalech. V místním prostředí se takové úlohy často vyvolávají přes crontab serveru.
Tyto aplikace jsou zabalené do archivů s příponou .jar (souborů JAR).
Poznámka:
Pokud vaše aplikace používá ke spouštění naplánovaných úloh nějaký plánovač (například Spring Batch nebo Quartz), důrazně doporučujeme tyto úlohy přepracovat tak, aby běžely mimo aplikaci. Pokud se vaše aplikace škáluje na více instancí v cloudu, spustí se stejná úloha více než jednou. Pokud navíc váš plánovací mechanismus používá místní časové pásmo hostitele, může při škálování aplikace napříč různými oblastmi docházet k nežádoucímu chování.
Výběr cílové služby Azure
V následujících částech zjistíte, které cílové služby splňují požadavky vaší aplikace a jaké zodpovědnosti zahrnují.
Mřížka možností hostování
Pomocí následující mřížky identifikujte potenciální cíle pro váš typ aplikace. Jak vidíte, Služba Azure Kubernetes Service (AKS) a Azure Virtual Machines podporují všechny typy aplikací, ale vyžadují, aby váš tým převzal větší zodpovědnost, jak je znázorněno v další části.
| Cílová → Typ aplikace ▼ |
Aplikace Service Java SE |
Aplikace Service Tomcat |
Aplikace Service JBoss EAP |
Azure Spring Aplikace |
Azure Container Apps | AKS | Virtuální Počítače |
|---|---|---|---|---|---|---|---|
| Aplikace Spring Boot / JAR | ✔ | ||||||
| Aplikace Spring Cloud | ✔ | ✔ | ✔ | ✔ | |||
| Webové aplikace | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Aplikace Java EE | ✔ | ✔ | ✔ | ||||
| Komerční aplikační servery (například Oracle WebLogic Server nebo IBM WebSphere) |
✔ | ✔ | ✔ | ||||
| Dlouhodobé uchování v místním systému souborů | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Clustering na úrovni aplikačního serveru | ✔ | ✔ | ✔ | ||||
| Dávkové / naplánované úlohy | ✔ | ✔ | ✔ | ✔ | |||
| Integrace virtuální sítě / hybridní Připojení ivity | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Regionální dostupnost Azure | Podrobnosti | Podrobnosti | Podrobnosti | Podrobnosti | Podrobnosti | Podrobnosti | Podrobnosti |
Tabulka průběžných zodpovědností
Následující tabulka vám pomůže zjistit zodpovědnosti, které jednotlivé cíle kladou na tým provádějící migraci.
Úlohy uvedené 
v Azure se spravují výhradně nebo většinou pomocí Azure. Váš tým je průběžně zodpovědný za úkoly uvedené v 👉. Doporučujeme, abyste pro splnění všech takových zodpovědností implementovali robustní, vysoce automatizovaný proces.
Poznámka:
Seznam zodpovědností není vyčerpávající.
| Cílová → Úkol ▼ |
Aplikace Service |
Azure Spring Aplikace |
Azure Kontejner Aplikace |
AKS | Virtuální Počítače |
|---|---|---|---|---|---|
| Aktualizace knihoven (včetně nápravy ohrožení zabezpečení) |
👉 | 👉 | 👉 | 👉 | 👉 |
| Aktualizace aplikačního serveru (včetně nápravy ohrožení zabezpečení) |
|
|
👉 | 👉 | 👉 |
| Aktualizace modulu runtime Java (včetně nápravy ohrožení zabezpečení) |
|
|
👉 | 👉 | 👉 |
| Aktivace aktualizací Kubernetes (provádí Azure pomocí ruční aktivace) |
– | |
|
👉 | N/A |
| Zotavení po havárii | |
|
👉 | 👉 | |
| Sjednocení změn rozhraní API služby Kubernetes, které nejsou zpětně kompatibilní | – | |
👉 | 👉 | N/A |
| Aktualizace základní image kontejneru (včetně nápravy ohrožení zabezpečení) |
– | |
👉 | 👉 | N/A |
| Aktualizace operačního systému (včetně nápravy ohrožení zabezpečení) |
|
|
|
1 |
👉 |
| Zjišťování a restartování neúspěšných instancí | |
|
|
|
👉 |
| Implementace vyprazdňování a postupného restartování pro aktualizace | |
|
|
|
👉 |
| Správa infrastruktury | |
|
👉 | 👉 | 👉 |
| Správa monitorování a upozorňování | 👉 | 👉 | 👉 | 👉 |
1 Některé aktualizace zabezpečení můžou vyžadovat restartování uzlů, které se neprodělají automaticky. Další informace najdete v tématu Použití aktualizací zabezpečení a jádra na uzly s Linuxem ve službě Azure Kubernetes Service (AKS).
Pokud jako součást aplikace nasadíte kontejner servletu (například Spring Boot), měli byste ho považovat za knihovnu, která vždy spadá mezi vaše zodpovědnosti.
Zajištění místního připojení
Pokud vaše aplikace potřebuje přístup k některým místním službám, budete muset zřídit jednu ze služeb připojení Azure. Další informace najdete v článku Volba řešení pro připojení místní sítě k Azure. Alternativně budete muset aplikaci refaktorovat tak, aby používala veřejně přístupná rozhraní API, která nabízejí vaše místní prostředky.
To byste měli zajistit dříve, než začnete s migrací.
Inventarizace aktuální kapacity a využití prostředků
Zdokumentujte hardware aktuálních produkčních serverů plus průměrný a maximální počet žádostí a využití prostředků. Tyto informace budete potřebovat ke zřízení prostředků v cílové službě.
Pokyny k migraci
V následujících tabulkách najdete pokyny k migraci podle typu aplikace a cílové služby Azure.
Aplikace v jazyce Java
Na následujících řádcích najděte typ aplikace v jazyce Java a ve sloupcích najděte cílovou službu Azure, která bude vaši aplikaci hostovat.
Pokud chcete migrovat aplikaci JBoss EAP do Tomcatu ve službě App Service, nejprve převeďte aplikaci Java EE na Java Web Apps (servlets) běžící na Tomcat, a pak postupujte podle pokynů uvedených níže.
Pokud chcete migrovat webovou aplikaci ve službě Tomcat do Azure Spring Apps, nejprve aplikaci převeďte na aplikace Spring Cloud a pak postupujte podle pokynů uvedených níže.
| Cílová → Typ aplikace ▼ |
Aplikace Service Java SE |
Aplikace Service Tomcat |
Aplikace Service JBoss EAP |
Azure Kontejner Aplikace |
Azure Spring Aplikace |
AKS | Virtuální Počítače |
|---|---|---|---|---|---|---|---|
| Aplikace Spring Boot / JAR |
– | – | – | N/A | doprovodné materiály | – | N/A |
| Spring Cloud / aplikace |
– | – | – | N/A | doprovodné materiály | doprovodné materiály plánováno |
doprovodné materiály plánováno |
| Webové aplikace ve službě Tomcat |
– | doprovodné materiály | – | doprovodné materiály | doprovodné materiály | doprovodné materiály | doprovodné materiály plánováno |
Aplikace Java EE
Na následujících řádcích najděte typ aplikace Java EE běžící na konkrétním aplikačním serveru. Ve sloupcích najděte cílovou službu Azure, která bude vaši aplikaci hostovat.
| Cílová → Aplikační server ▼ |
Aplikace Service Java SE |
Aplikace Service Tomcat |
Aplikace Service JBoss EAP |
Azure Kontejner Aplikace |
Azure Spring Aplikace |
AKS | Virtuální Počítače |
|---|---|---|---|---|---|---|---|
| WildFly / JBoss AS |
– | N/A | doprovodné materiály | – | N/A | doprovodné materiály | doprovodné materiály plánováno |
| Oracle WebLogic Server | – | N/A | doprovodné materiály | – | N/A | doprovodné materiály | doprovodné materiály |
| IBM WebSphere | – | N/A | doprovodné materiály | – | N/A | doprovodné materiály | doprovodné materiály plánováno |
| Red Hat JBoss EAP | – | N/A | doprovodné materiály | – | N/A | doprovodné materiály | doprovodné materiály |
Viz také
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro