Monolitikus alkalmazások tárolóba helyezése

Tipp.

Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.

PDF letöltése

Érdemes lehet egyetlen, monolitikusan üzembe helyezett webalkalmazást vagy szolgáltatást létrehozni, és tárolóként üzembe helyezni. Maga az alkalmazás nem lehet belsőleg monolitikus, hanem több kódtárként, összetevőként vagy akár rétegként (alkalmazásréteg, tartományi réteg, adatelérési réteg stb.) strukturált. Külsőleg azonban egyetlen tárolóról van szó – egyetlen folyamatról, egyetlen webalkalmazásról vagy egyetlen szolgáltatásról.

A modell kezeléséhez egyetlen tárolót kell üzembe helyeznie az alkalmazás megjelenítéséhez. A kapacitás növeléséhez vertikális felskálázást kell végeznie, azaz csak adjon hozzá több példányt egy terheléselosztóval elöl. Az egyszerűség abból fakad, hogy egyetlen üzembe helyezést kezel egyetlen tárolóban vagy virtuális gépen.

4-1. ábra. Példa egy tárolóalapú monolitikus alkalmazás architektúrájára

Az egyes tárolókban több összetevőt, kódtárat vagy belső réteget is felvehet, a 4–1. ábrán látható módon. A monolitikus tárolóalapú alkalmazások funkcióinak nagy része egyetlen tárolón belül, belső rétegekkel vagy kódtárakkal rendelkezik, és a tároló több kiszolgálón/virtuális gépen való klónozásával skálázható fel. Ez a monolitikus minta azonban ütközhet a tároló elvével: "a tároló egy dolgot csinál, és egyetlen folyamatban végzi", de bizonyos esetekben rendben lehet.

Ennek a megközelítésnek a hátránya nyilvánvalóvá válik, ha az alkalmazás növekszik, és skálázást igényel. Ha a teljes alkalmazás méretezhető, az nem igazán probléma. A legtöbb esetben azonban az alkalmazásnak csak néhány része a skálázást igénylő fulladási pontok, míg más összetevők kevesebbet használnak.

Egy tipikus e-kereskedelmi alkalmazásban például valószínűleg skáláznia kell a termékinformációs alrendszert, mert sokkal több ügyfél böngészi a termékeket, mint megvásárolja őket. Több ügyfél használja a kosárját, mint a fizetési folyamatot. Kevesebb ügyfél fűz megjegyzéseket, vagy megtekintheti a vásárlási előzményeit. És lehet, hogy csak néhány alkalmazottja van, akiknek kezelniük kell a tartalom- és marketingkampányokat. Ha a monolitikus kialakítást skálázza, a különböző feladatok összes kódja többször lesz üzembe helyezve, és ugyanabban a minőségben lesz skálázva.

Az alkalmazások horizontális duplikálásának, az alkalmazás különböző területeinek felosztásának, valamint a hasonló üzleti fogalmak vagy adatok particionálásának több módja is van. Az összes összetevő skálázásával kapcsolatos probléma mellett azonban az egyetlen összetevő módosításához a teljes alkalmazás teljes újratesztelése és az összes példány teljes ismételt üzembe helyezése szükséges.

A monolitikus megközelítés azonban gyakori, mivel az alkalmazás fejlesztése kezdetben egyszerűbb, mint a mikroszolgáltatási megközelítések esetében. Így számos szervezet fejlődik ezzel az architekturális megközelítéssel. Míg egyes szervezeteknek elég jó eredményeik voltak, mások korlátokat érnek el. Sok szervezet ezzel a modellel tervezte alkalmazásait, mert az eszközök és az infrastruktúra miatt évekkel ezelőtt túl nehéz volt szolgáltatásorientált architektúrákat (SOA) létrehozni, és nem látja a szükséges szükségletet, amíg az alkalmazás nem növekedett.

Az infrastruktúra szempontjából minden kiszolgáló számos alkalmazást futtathat ugyanazon a gazdagépen belül, és elfogadható az erőforrás-használat hatékonysága a 4–2. ábrán látható módon.

4–2. ábra. Monolitikus megközelítés: Több alkalmazást futtató gazdagép, minden alkalmazás tárolóként fut

A Microsoft Azure monolitikus alkalmazásai minden példányhoz dedikált virtuális gépek használatával telepíthetők. Emellett az Azure-beli virtuálisgép-méretezési csoportok használatával egyszerűen skálázhatja a virtuális gépeket. Azure-alkalmazás szolgáltatás monolitikus alkalmazásokat is futtathat, és egyszerűen méretezheti a példányokat anélkül, hogy a virtuális gépeket kellene felügyelnie. 2016 óta a Azure-alkalmazás-szolgáltatások egyetlen Docker-tárolópéldányt is futtathatnak, ami leegyszerűsíti az üzembe helyezést.

Minőségbiztosítási környezetként vagy korlátozott éles környezetként több Docker-gazdagép virtuális gépet is üzembe helyezhet, és kiegyensúlyozhatja őket az Azure Balancerrel, ahogyan az a 4–3. ábrán látható. Ez lehetővé teszi a skálázás durva szemcsés megközelítéssel történő kezelését, mivel a teljes alkalmazás egyetlen tárolóban található.

4-3. ábra. Példa több gazdagépre egyetlen tárolóalkalmazás vertikális felskálázására

A különböző gazdagépeken való üzembe helyezés hagyományos üzembe helyezési technikákkal kezelhető. A Docker-gazdagépek kezelhetők olyan parancsokkal, mint például docker run manuálisan vagy docker-compose manuálisan, vagy automatizálással, például folyamatos kézbesítési (CD-) folyamatokkal.

Monolitikus alkalmazás üzembe helyezése tárolóként

A tárolók használatának számos előnye van a monolitikus alkalmazások üzembe helyezésének kezeléséhez. A tárolópéldányok méretezése sokkal gyorsabb és egyszerűbb, mint a további virtuális gépek üzembe helyezése. Még ha virtuálisgép-méretezési csoportokat is használ, a virtuális gépek indítása időt vesz igénybe. Ha tárolók helyett hagyományos alkalmazáspéldányként van üzembe helyezve, az alkalmazás konfigurációja a virtuális gép részeként történik, ami nem ideális.

A frissítések Docker-rendszerképekként való üzembe helyezése sokkal gyorsabb és hálózatilag hatékony. A Docker-rendszerképek általában másodpercek alatt indulnak el, ami felgyorsítja a bevezetést. A Docker-rendszerképpéldányok lebontása ugyanolyan egyszerű, mint egy docker stop parancs kiadása, és általában kevesebb mint egy másodperc alatt befejeződik.

Mivel a tárolók tervezés szerint nem módosíthatók, soha nem kell aggódnia a sérült virtuális gépek miatt. Ezzel szemben előfordulhat, hogy a virtuális gép frissítési szkriptjei elfelejtenek figyelembe venni a lemezen maradt bizonyos konfigurációkat vagy fájlokat.

Bár a monolitikus alkalmazások profitálhatnak a Dockerből, csak az előnyöket vesszük alapul. A tárolók kezelésének további előnyei a tárolóvezénylőkkel való üzembe helyezésből erednek, amelyek az egyes tárolópéldányok különböző példányait és életciklusát kezelik. A monolitikus alkalmazás önállóan skálázható, fejleszthető és üzembe helyezhető alrendszerekre való felosztása a mikroszolgáltatások birodalmába való belépési pont.

Egytárolós alkalmazás közzététele Azure-alkalmazás Szolgáltatásban

Akár az Azure-ban üzembe helyezett tároló érvényesítését szeretné megkapni, akár csak egytárolós alkalmazásról van szó, Azure-alkalmazás szolgáltatás nagyszerű módot kínál skálázható egytárolós szolgáltatások nyújtására. A Azure-alkalmazás szolgáltatás használata egyszerű. Nagyszerű integrációt biztosít a Gittel, hogy megkönnyítse a kód felvételét, a Visual Studióban való összeállítását és közvetlen üzembe helyezését az Azure-ban.

4-4. ábra. Egytárolós alkalmazás közzététele Azure-alkalmazás Szolgáltatásban a Visual Studio 2022-ből

Ha a Docker nélkül más képességekre, keretrendszerekre vagy függőségekre van szüksége, amelyek nem támogatottak a Azure-alkalmazás Service-ben, meg kellett várnia, amíg az Azure-csapat frissíti ezeket a függőségeket az App Service-ben. Vagy át kellett váltania más szolgáltatásokra, például az Azure Cloud Servicesre vagy a virtuális gépekre, ahol további vezérléssel rendelkezik, és telepíthet egy szükséges összetevőt vagy keretrendszert az alkalmazáshoz.

A Visual Studio 2017 és újabb verzióinak tárolótámogatása lehetővé teszi, hogy a 4–4. ábrán látható módon bármit belefoglaljon az alkalmazáskörnyezetbe. Mivel tárolóban futtatja, ha függőséget ad hozzá az alkalmazáshoz, a függőséget belefoglalhatja a Docker-fájlba vagy a Docker-rendszerképbe.

Ahogy a 4–4. ábrán is látható, a közzétételi folyamat leküld egy lemezképet egy tárolóregisztrációs adatbázison keresztül. Ez lehet az Azure Container Registry (az Azure-beli üzemelő példányokhoz közeli, Azure Active Directory-csoportok és -fiókok által védett beállításjegyzék), vagy bármely más Docker-beállításjegyzék, például a Docker Hub vagy egy helyszíni beállításjegyzék.

Előzőkövetkező