Megosztás a következőn keresztül:


Java-alkalmazások migrálása az Azure-ba

Ez a cikk áttekintést nyújt a Java-alkalmazások Azure-ba való migrálásához javasolt stratégiákról.

Ez a migrálási útmutató a gyakori Azure-beli Java-forgatókönyveket mutatja be, valamint javaslatokkal és megfontolandó szempontokkal segíti a magas szintű tervezést. Ha egy adott Java-alkalmazás migrálási forgatókönyvét szeretné megvitatni az Azure-beli Microsoft Java csapatával, töltse ki a következő kérdőívet, és egy képviselő felveszi Önnel a kapcsolatot.

Java-migrálási kérdőív

Az alkalmazástípus azonosítása

Mielőtt kiválaszt egy felhőalapú célhelyet a Java-alkalmazáshoz, azonosítania kell az alkalmazás típusát. A legtöbb Java-alkalmazás a következő típusok egyikébe tartozik:

  • Spring-alkalmazások:
  • Java EE-alkalmazások
  • Webalkalmazások
  • Kötegelt/ütemezett feladatok

Ezen típusok leírását a következő szakaszok tartalmazzák.

Spring Boot-/JAR-alkalmazások

Számos újabb alkalmazás közvetlenül a parancssorból hívható meg. Ezek az alkalmazások továbbra webes kéréseket kezelnek, azonban ahelyett, hogy a HTTP-kéréseik kezelését egy alkalmazáskiszolgálóra bíznák,az alkalmazáscsomagba foglalják a HTTP-kommunikációt és minden egyéb függőséget. Az ilyen alkalmazások gyakran olyan keretrendszerekkel készülnek, mint a Spring Boot, a Dropwizard, a Micronaut, a MicroProfile, a Vert.x és hasonlók.

Ezek az alkalmazások .jar kiterjesztéssel vannak archívumokba csomagolva.

Spring Cloud köztes szoftvermodulokat használó Spring-alkalmazások

A mikroszolgáltatás architekturális stílusa egy olyan megközelítés, amely egyetlen alkalmazást fejleszt kis szolgáltatások csomagjaként. Minden szolgáltatás a saját folyamatában fut, és egyszerűsített mechanizmusokkal, gyakran HTTP-erőforrás API-val kommunikál. Ezek a szolgáltatások üzleti funkciók köré csoportosulnak, és egymástól függetlenül üzembe helyezhetők egy teljes mértékben automatizált üzembe helyezési géppel. Ezeknek a szolgáltatásoknak nincs minimális központosított felügyelete, amely különböző programozási nyelveken írható, és különböző adattárolási technológiákat használ. Az ilyen szolgáltatások gyakran olyan keretrendszerrel készülnek, mint a Spring Cloud.

Ezek a szolgáltatások több alkalmazásba vannak csomagolva a .jar kiterjesztéssel.

Java EE-alkalmazások

A Java EE-alkalmazások (más néven J2EE-alkalmazások vagy újabban Jakarta EE-alkalmazások) a webalkalmazások elemeinek egy részét, egészét vagy egyikét sem tartalmazhatják. Ezek az alkalmazások a Jakarta EE specifikációja alapján sokkal több összetevőt is tartalmazhatnak és használhatnak.

A Java EE-alkalmazások archívumként az .ear vagy a .war bővítménnyel csomagolhatók.

A Java EE-alkalmazásokat Java EE-kompatibilis alkalmazáskiszolgálókon (például Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara stb.) kell üzembe helyezni.

A kizárólag Java EE specifikáció által nyújtott funkciókra alapuló alkalmazások (tehát az alkalmazáskiszolgálóktól független alkalmazások) egy kompatibilis alkalmazáskiszolgálóról egy másikra migrálhatók. Ha az alkalmazás egy adott alkalmazáskiszolgálótól függ (alkalmazáskiszolgáló-függő), előfordulhat, hogy Önnek ki kell választania egy Azure-szolgáltatáscélt, amely lehetővé teszi, hogy üzemeltesse az alkalmazáskiszolgálót.

Webes alkalmazások

A webalkalmazások egy Servlet-tárolón belül futnak. Ezen alkalmazások némelyike közvetlenül servlet API-kat használ, míg sokan más keretrendszereket használnak, amelyek a servlet API-kat foglalják magában, például apache Struts, Spring MVC, JavaServer Faces (JSF) és mások.

A webalkalmazások .war kiterjesztéssel vannak archívumokba csomagolva.

Kötegelt/ütemezett feladatok

Egyes alkalmazások rövid ideig futnak, egy adott számítási feladatot végeznek el, majd bezáródnak anélkül, hogy kérésekre vagy felhasználói bemenetre várnának. Az ilyen feladatok néha egyszer, néha rendszeresen ütemezett időközönként futnak. A helyszínen az ilyen feladatokat gyakran egy kiszolgáló crontabján kell meghívni.

Ezek az alkalmazások .jar kiterjesztéssel vannak archívumokba csomagolva.

Feljegyzés

Ha az alkalmazás egy ütemezőt (például a Spring Batchet vagy a Quartzot) használ az ütemezett feladatok futtatásához, határozottan javasoljuk, hogy az ilyen feladatokat az alkalmazáson kívül futtassa. Ha az alkalmazást több példányra méretezi a felhőben, ugyanaz a feladat többször is lefut. Emellett, ha az ütemezési mechanizmus a gazdagép helyi időzónáját használja, nemkívánatos viselkedést tapasztalhat, amikor az alkalmazását több régióra méretezi.

Az Azure-szolgáltatás céljának kiválasztása

Az alábbi szakaszok bemutatják, hogy mely szolgáltatáscélok felelnek meg az alkalmazás követelményeinek, és milyen felelősségekkel járnak.

Tárhely lehetőségek táblázata

Az alábbi rács segítségével azonosíthatja az alkalmazástípus lehetséges célhelyeit. Mint látható, az Azure Kubernetes Service (AKS) és az Azure Virtual Machines minden alkalmazástípust támogat, de a csapatnak további feladatokat kell vállalnia, ahogyan az a következő szakaszban látható.

Cél →

Alkalmazás típusa ↓
Alkalmazás
Szolgáltatás
Java SE
Alkalmazás
Szolgáltatás
Kandúr
Alkalmazás
Szolgáltatás
JBoss EAP (Vállalati Alkalmazási Platform)
Azure Container-alkalmazások AKS Virtuális
Gépek
Spring Boot-/JAR-alkalmazások
Spring Cloud-alkalmazások
Webalkalmazások (WAR)
Java EE-alkalmazások (WAR | EAR)
Kereskedelmi alkalmazáskiszolgálók
(például Oracle WebLogic Server vagy IBM WebSphere)
Alkalmazásszerver szintű klaszterezés
Kötegelt/ütemezett feladatok
VNet-integráció/hibrid kapcsolat
Azure-régiónkénti elérhetőség Részletek Részletek Részletek Részletek Részletek Részletek

Folyamatos felelősségháló

Az alábbi rácsot használva megértheti, hogy egy adott célállomás milyen felelősséggel jár a migrálás után.

Az feladatokat teljes egészében vagy jellemzően az Azure felügyeli. Az Ön csapata folyamatos felelősséggel tartozik a 👉 jelzett feladatokért. Egy robusztus, nagy mértékben automatizált folyamatot javaslunk az ilyen felelősségek ellátására.

Feljegyzés

A lista nem tartalmazza az összes feladatot.

Cél →

Tevékenység ↓
Alkalmazás
Szolgáltatás
Azúrkék
Tároló
Alkalmazások
AKS Virtuális
Gépek
Könyvtárak frissítése
(ide tartozik a biztonsági rések kezelése is)
👉 👉 👉 👉
Az alkalmazáskiszolgáló frissítése
(ide tartozik a biztonsági rések kezelése is)
Azure 👉 👉 👉
A Java futtatókörnyezetének frissítése
(ide tartozik a biztonsági rések kezelése is)
Azure 👉 👉 👉
A Kubernetes-frissítések elindítása
(ezt az Azure végzi el egy manuális eseményindítóval)
n/a Azure 👉 n/a
Katasztrófa-helyreállítás Azure 👉 👉 Azure
A visszamenőlegesen nem kompatibilis Kubernetes API-beli változások összeegyeztetése n/a 👉 👉 n/a
Tároló alaprendszerképének módosítása
(ide tartozik a biztonsági rések kezelése is)
n/a 👉 👉 n/a
Az operációs rendszer frissítése
(ide tartozik a biztonsági rések kezelése is)
Azure Azure Azure1 👉
A hibás példányok észlelése és újraindítása Azure Azure Azure 👉
A kiürítés és a frissítések gördülő újraindításának bevezetése Azure Azure Azure 👉
Infrastruktúra-felügyelet Azure 👉 👉 👉
Monitorozás és riasztáskezelés 👉 👉 👉 👉

1 Egyes biztonsági frissítések csomópont-újraindítást igényelhetnek, amelyek nem lesznek automatikusan végrehajtva. További információért lásd Biztonsági és kernelfrissítések alkalmazása Linux-csomópontokra az Azure Kubernetes Service-ben (AKS).

Ha a servlettárolót (például a Spring Bootot) az alkalmazás részeként helyezi üzembe, könyvtárnak kell tekinteni, így ez mindig az Ön felelőssége marad.

Helyszíni kapcsolatok biztosítása

Ha az alkalmazásnak hozzá kell férnie helyszíni szolgáltatásokhoz, ki kel építenie egy Azure-beli kapcsolati szolgáltatást. További információért nézze meg a "Helyszíni hálózat csatlakoztatása az Azure-hoz" című részt. Másik megoldásként újra kell strukturálnia az alkalmazást, hogy a helyszíni erőforrások által biztosított nyilvánosan elérhető API-kat használjon.

Ezt még a migrálás előtt kell megtennie.

Az aktuális kapacitás és az erőforrás-használat leltározása

Dokumentálja a jelenlegi éles kiszolgálók hardverét, valamint az átlagos és a kiugró kérésszámokat, illetve az erőforrás-használatot. Szüksége lesz erre az információra az erőforrások kiépítéséhez a szolgáltatás célhelyén.

Útmutató az áttelepítéshez

Az alábbi rácsokkal migrálási tanácsokat kaphat alkalmazástípus és célzott Azure-szolgáltatáscél alapján.

Java-alkalmazások

Az alábbi sorokkal megtalálhatja saját Java-alkalmazásának típusát, az oszlopokkal pedig az alkalmazást üzemeltető Azure-szolgáltatáscélt.

Ha JBoss EAP-alkalmazást szeretne migrálni az App Service-en futó Tomcatbe, először konvertálja a Java EE-alkalmazást a Tomcaten futó Java Web Apps (servlets) alkalmazássá, majd kövesse az alábbi útmutatást.

Cél →

Alkalmazás típusa ↓
Alkalmazás
Szolgáltatás
Java SE
Alkalmazás
Szolgáltatás
Kandúr
Alkalmazás
Szolgáltatás
JBoss EAP (Vállalati Alkalmazási Platform)
Azúrkék
Tároló
Alkalmazások
AKS Virtuális
Gépek
Spring Boot-/
JAR-alkalmazások
útmutató n/a n/a n/a n/a n/a
Spring Cloud-/
alkalmazások
n/a n/a n/a n/a útmutató
tervezett
útmutató
tervezett
Webes alkalmazások
Tomcat alatt
n/a útmutató n/a útmutató útmutató útmutató
tervezett

Java EE-alkalmazások

Az alábbi sorokkal megtalálhatja az egy adott alkalmazáskiszolgálón futó Java EE-alkalmazását. Az oszlopokkal megtalálhatja az alkalmazást üzemeltető Azure-szolgáltatáscélt.

Cél →

Alkalmazáskiszolgáló ↓
Alkalmazás
Szolgáltatás
Java SE
Alkalmazás
Szolgáltatás
Kandúr
Alkalmazás
Szolgáltatás
JBoss EAP (Vállalati Alkalmazási Platform)
Azúrkék
Tároló
Alkalmazások
AKS Virtuális
Gépek
JBoss AS n/a n/a útmutató n/a n/a útmutató
tervezett
Oracle WebLogic-kiszolgáló n/a n/a útmutató n/a útmutató útmutató
IBM WebSphere n/a n/a útmutató n/a útmutató útmutató
tervezett
Red Hat JBoss EAP n/a n/a útmutató n/a n/a útmutató

Lásd még

  • A Java 11-re és azon túlra való áttérés okai
  • Áttérés Java 8-ról Java 11-re
  • Váltás Java 7-ről Java 8-ra