Gyakori webalkalmazás-architektúrák

  • Cikk

Tipp.

Ez a tartalom egy részlet az eBook, Architect Modern Web Applications with ASP.NET Core és Az Azure, elérhető a .NET Docs vagy egy ingyenesen letölthető PDF, amely offline olvasható.

PDF letöltése

Architect Modern Web Applications with ASP.NET Core and Azure eBook cover thumbnail.

"Ha úgy gondolja, hogy a jó architektúra drága, próbálkozzon rossz architektúrával." - Brian Foote és Joseph Yoder

A hagyományos .NET-alkalmazások többsége egyetlen egységként van üzembe helyezve, amely egy végrehajtható vagy egyetlen, egyetlen IIS-alkalmazástartományon belül futó webalkalmazásnak felel meg. Ez a megközelítés a legegyszerűbb üzembehelyezési modell, és számos belső és kisebb nyilvános alkalmazást nagyon jól szolgál ki. A legtöbb nem triviális üzleti alkalmazás azonban még ebben az egyetlen üzembe helyezési egységben is kihasználja a logikai elkülönítést több rétegre.

Mi az a monolitikus alkalmazás?

A monolitikus alkalmazás olyan alkalmazás, amely viselkedése szempontjából teljesen önálló. A műveletek végrehajtása során más szolgáltatásokkal vagy adattárakkal is kommunikálhat, de viselkedésének magja a saját folyamatán belül fut, és a teljes alkalmazás általában egyetlen egységként van üzembe helyezve. Ha egy ilyen alkalmazásnak horizontálisan kell skáláznia, általában a teljes alkalmazás duplikálva lesz több kiszolgálón vagy virtuális gépen.

All-in-one alkalmazások

Az alkalmazásarchitektúra esetében a lehető legkisebb számú projekt egy. Ebben az architektúrában az alkalmazás teljes logikája egyetlen projektben található, egyetlen szerelvényre van lefordítva, és egyetlen egységként van üzembe helyezve.

A Visual Studióban vagy a parancssorból létrehozott új ASP.NET Core-projekt egyszerű "all-in-one" monolithként indul. Az alkalmazás összes viselkedését tartalmazza, beleértve a bemutató, az üzleti és az adathozzáférési logikát. Az 5–1. ábra egy egyprojektes alkalmazás fájlstruktúráját mutatja be.

A single project ASP.NET Core app

5-1. ábra. Egyetlen projekt ASP.NET Core-alkalmazás.

Egyetlen projektforgatókönyvben a problémák elkülönítése mappák használatával történik. Az alapértelmezett sablon különálló mappákat tartalmaz a modellek, nézetek és vezérlők MVC-mintafeladataihoz, valamint további mappákat az adatokhoz és szolgáltatásokhoz. Ebben az elrendezésben a bemutató részleteit a lehető legnagyobb mértékben korlátozni kell a Nézetek mappára, az adathozzáférés implementálásának részleteit pedig az Adatok mappában tárolt osztályokra kell korlátozni. Az üzleti logikának a Modellek mappában kell lennie a szolgáltatásokban és osztályokban.

Bár egyszerű, az egyprojektes monolitikus megoldás hátrányai vannak. A projekt méretének és összetettségének növekedésével párhuzamosan a fájlok és mappák száma is nőni fog. A felhasználói felülettel (felhasználói felülettel) kapcsolatos problémák (modellek, nézetek, vezérlők) több mappában találhatók, amelyek nincsenek betűrendben csoportosítva. Ez a probléma csak akkor romlik, ha további felhasználói felületi szerkezeteket, például szűrőket vagy ModelBinders-eket adnak hozzá a saját mappájukhoz. Az üzleti logika szétszórva van a Modellek és szolgáltatások mappák között, és nincs egyértelmű jele annak, hogy mely osztályokban melyik mappáknak kell függenie másoktól. A projektszintű szervezet hiánya gyakran spagettikódhoz vezet.

Ezeknek a problémáknak a megoldása érdekében az alkalmazások gyakran többprojektes megoldásokká fejlődnek, ahol az egyes projektek az alkalmazás egy adott rétegében találhatók.

Mik azok a rétegek?

Ahogy az alkalmazások egyre összetettebbé fejlődnek, az összetettség kezelésének egyik módja az alkalmazás felosztása a felelősségi körének vagy aggályainak megfelelően. Ez a megközelítés az aggodalmak elvének elválasztását követi, és segít a növekvő kódbázis rendszerezésében, hogy a fejlesztők könnyen megtalálhassák bizonyos funkciók implementálásának helyét. A rétegzett architektúra azonban számos előnnyel jár a kódszervezésen túl.

A kód rétegekbe rendezésével a gyakori alacsony szintű funkciók újra felhasználhatók az alkalmazás teljes területén. Ez az újrafelhasználás azért hasznos, mert azt jelenti, hogy kevesebb kódot kell írni, és mivel lehetővé teszi az alkalmazás számára, hogy egységesítse az egyetlen implementációt, a ne ismételje meg a saját (DRY) elvet.

A rétegzett architektúrával az alkalmazások korlátozásokat kényszeríthetnek ki arra, hogy mely rétegek kommunikálhatnak más rétegekkel. Ez az architektúra segít a beágyazás elérésében. Ha egy réteg módosul vagy lecserélődik, csak azokat a rétegeket kell érinteni, amelyek az adott réteget használják. Annak korlátozásával, hogy mely rétegek függenek a többi rétegtől, a módosítások hatása csökkenthető, hogy egyetlen módosítás ne legyen hatással a teljes alkalmazásra.

A rétegek (és a beágyazás) sokkal egyszerűbbé teszik a funkciók cseréjét az alkalmazásban. Előfordulhat például, hogy egy alkalmazás kezdetben a saját SQL Server-adatbázisát használja az adatmegőrzéshez, de később dönthet úgy, hogy felhőalapú adatmegőrzési stratégiát használ, vagy egy webes API mögött. Ha az alkalmazás megfelelően beágyazta a perzisztencia-implementációját egy logikai rétegbe, az SQL Server-specifikus réteget lecserélheti egy új, ugyanazt a nyilvános felületet implementáló rétegre.

A követelmények jövőbeni változásaira reagáló implementációk felcserélésének lehetősége mellett az alkalmazásrétegek tesztelési célokra is egyszerűbbé tehetik az implementációk felcserélésének lehetőségét. Ahelyett, hogy olyan teszteket kellene írnia, amelyek az alkalmazás valós adatrétegén vagy felhasználói felületén működnek, ezeket a rétegeket a tesztelés során lecserélheti hamis implementációkra, amelyek ismert válaszokat adnak a kérésekre. Ez a megközelítés általában sokkal egyszerűbbé és gyorsabban futtathatóvá teszi a teszteket az alkalmazás valós infrastruktúráján végzett tesztekhez képest.

A logikai rétegzés gyakori módszer a kód vállalati szoftveralkalmazásokban való szervezésének javítására, és a kód rétegekbe rendezésének számos módja van.

Feljegyzés

A rétegek az alkalmazáson belüli logikai elkülönítést jelölik. Abban az esetben, ha az alkalmazáslogika fizikailag külön kiszolgálókra vagy folyamatokra van osztva, ezeket a különálló fizikai üzembehelyezési célokat rétegnek nevezzük. Lehetséges, és meglehetősen gyakori, hogy egy N-layer alkalmazás van üzembe helyezve egy szinten.

Hagyományos "N-Layer" architektúraalkalmazások

Az alkalmazáslogika rétegekbe való leggyakoribb rendszerezését az 5–2. ábra mutatja.

Typical application layers

5-2. ábra. Tipikus alkalmazásrétegek.

Ezeket a rétegeket gyakran rövidítve a felhasználói felület, a BLL (üzleti logikai réteg) és a DAL (adatelérési réteg). Ezzel az architektúrával a felhasználók a felhasználói felületen keresztül kérnek kéréseket, amelyek csak a BLL-vel működnek együtt. A BLL viszont meghívhatja a DAL-t az adathozzáférési kérelmekhez. A felhasználói felületi rétegnek nem szabad közvetlenül kéréseket küldenie a DAL-hoz, és nem szabad más eszközökkel közvetlenül kezelnie az adatmegőrzést. Hasonlóképpen, a BLL-nek csak a DAL-on keresztül kell működnie az adatmegőrzéssel. Ily módon minden rétegnek saját jól ismert felelőssége van.

Ennek a hagyományos rétegzési módszernek az egyik hátránya, hogy a fordítási idő függőségei felülről lefelé futnak. Vagyis a felhasználói felületi réteg a BLL-től függ, amely a DAL-tól függ. Ez azt jelenti, hogy a BLL, amely általában az alkalmazás legfontosabb logikáját tartalmazza, az adathozzáférés implementálási részleteitől (és gyakran az adatbázis meglététől) függ. Az üzleti logika tesztelése egy ilyen architektúrában gyakran nehéz, és tesztadatbázist igényel. A függőség inverziós elve használható a probléma megoldására, ahogy a következő szakaszban is látni fogja.

Az 5-3. ábra egy példamegoldást mutat be, amely az alkalmazást három projektre bontja felelősség (vagy réteg) szerint.

A simple monolithic application with three projects

5-3. ábra. Egy egyszerű monolitikus alkalmazás három projekttel.

Bár ez az alkalmazás több projektet használ szervezeti célokra, még mindig egyetlen egységként van üzembe helyezve, és az ügyfelei egyetlen webalkalmazásként fogják használni. Ez nagyon egyszerű üzembehelyezési folyamatot tesz lehetővé. Az 5–4. ábra bemutatja, hogyan üzemeltethető egy ilyen alkalmazás az Azure-zal.

Simple deployment of Azure Web App

5-4. ábra. Az Azure Web App egyszerű üzembe helyezése

Az alkalmazás növekedésével összetettebb és robusztusabb üzembehelyezési megoldásokra lehet szükség. Az 5–5. ábra egy összetettebb, további képességeket támogató üzembehelyezési tervet mutat be.

Deploying a web app to an Azure App Service

5–5. ábra. Webalkalmazás üzembe helyezése Azure-alkalmazás szolgáltatásban

A projekt szervezete belsőleg több, felelősségen alapuló projektben javítja az alkalmazás karbantarthatóságát.

Ez az egység vertikálisan felskálázható vagy kiskálázható a felhőalapú igény szerinti skálázhatóság előnyeinek kihasználásához. A vertikális felskálázás azt jelenti, hogy további PROCESSZOR-, memória-, lemezterület- vagy egyéb erőforrásokat ad hozzá az alkalmazást futtató kiszolgáló(ok)hoz. A horizontális felskálázás az ilyen kiszolgálók további példányainak hozzáadását jelenti, függetlenül attól, hogy fizikai kiszolgálókról, virtuális gépekről vagy tárolókról van-e szó. Ha az alkalmazást több példányban üzemeltetik, a rendszer terheléselosztóval rendeli hozzá a kéréseket az egyes alkalmazáspéldányokhoz.

A webalkalmazások Azure-beli méretezésének legegyszerűbb módszere, ha manuálisan konfigurálja a skálázást az alkalmazás App Service-csomagjában. Az 5–6. ábrán a megfelelő Azure-irányítópult képernyő látható, amelyen konfigurálható, hogy hány példány szolgál ki egy alkalmazást.

App Service Plan scaling in Azure

5–6. ábra. App Service-csomag skálázása az Azure-ban.

Tiszta architektúra

A függőségi inverzió elvét, valamint a tartományalapú tervezés (DDD) alapelveit követő alkalmazások általában hasonló architektúrát kapnak. Ez az architektúra az évek során számos nevet kapott. Az egyik utónév a hatszögletű architektúra volt, amelyet a portok és adapterek követtek. A közelmúltban a Hagyma architektúra vagy a Tiszta architektúra néven hivatkoztak rá. Az e-könyvben az architektúra neve a Clean Architecture (Tiszta architektúra) nevet használja.

Az eShopOnWeb referenciaalkalmazás a Tiszta architektúra megközelítést használja a kód projektekbe való rendszerezéséhez. Az ardalis/cleanarchitecture GitHub-adattárban található saját ASP.NET Core-megoldások kiindulópontjaként használható megoldássablont, vagy a Sablon NuGetből való telepítésével is megtalálhatja.

A tiszta architektúra az üzleti logikát és az alkalmazásmodellt helyezi az alkalmazás középpontjába. Ahelyett, hogy az üzleti logika az adathozzáféréstől vagy más infrastruktúra-problémáktól függ, ez a függőség inverz: az infrastruktúra és a megvalósítás részletei az Application Core-tól függenek. Ez a funkció absztrakciók vagy interfészek definiálásával érhető el az Application Core-ban, amelyeket aztán az infrastruktúrarétegben meghatározott típusok valósítanak meg. Az architektúra vizualizációjának gyakori módja, ha koncentrikus körök sorozatát használjuk, hasonlóan a hagymához. Az 5-7. ábra az architektúra ábrázolásának erre a stílusára mutat példát.

Clean Architecture; onion view

5-7. ábra. Tiszta architektúra; hagyma nézet

Ebben a diagramban a függőségek a legbelső kör felé haladnak. Az Application Core a diagram középpontjában lévő helyről veszi fel a nevét. A diagramon látható, hogy az Application Core nem függ más alkalmazásrétegekkel. Az alkalmazás entitásai és felületei a középpontban vannak. A kívülről, de még az Application Core-ban is tartományi szolgáltatások, amelyek általában a belső körben definiált interfészeket implementálják. Az Application Core-on kívül a felhasználói felület és az infrastruktúra rétegei az Application Core-tól függenek, de egymástól (szükségszerűen) nem.

Az 5–8. ábrán egy hagyományosabb vízszintes rétegdiagram látható, amely jobban tükrözi a felhasználói felület és más rétegek közötti függőséget.

Clean Architecture; horizontal layer view

5-8. ábra. Tiszta architektúra; vízszintes rétegnézet

Vegye figyelembe, hogy a folytonos nyilak fordítási idejű függőségeket, míg a szaggatott nyíl csak futásidejű függőségeket jelöl. A tiszta architektúrával a felhasználói felületi réteg fordításkor az Application Core-ban meghatározott felületekkel működik, és ideális esetben nem kell tudnia az infrastruktúrarétegben definiált implementációs típusokról. Futtatáskor azonban ezek a megvalósítási típusok szükségesek az alkalmazás végrehajtásához, ezért jelen kell lenniük, és függőséginjektáláson keresztül kell az Application Core-felületekhez csatlakoztatni őket.

Az 5–9. ábra egy ASP.NET Core-alkalmazás architektúrájának részletesebb nézetét mutatja be, amikor ezeket a javaslatokat követve készült.

ASP.NET Core architecture diagram following Clean Architecture

5-9. ábra. ASP.NET Tiszta architektúrát követő alapvető architektúradiagram.

Mivel az Application Core nem függ az infrastruktúrától, nagyon könnyű automatizált egységteszteket írni ehhez a réteghez. Az 5–10. és az 5–11. ábra bemutatja, hogy a tesztek hogyan illeszkednek ebbe az architektúrába.

UnitTestCore

5–10. ábra. Az Application Core egységtesztelése külön-külön.

IntegrationTests

5–11. ábra. Integrációtesztelési infrastruktúra-implementációk külső függőségekkel.

Mivel a felhasználói felületi réteg nem rendelkezik közvetlen függőséggel az infrastruktúraprojektben definiált típusoktól, az implementációk felcserélése szintén nagyon egyszerű, akár a tesztelés megkönnyítése, akár a változó alkalmazáskövetelményekre reagálva. ASP.NET Core beépített használata és a függőséginjektálás támogatása révén ez az architektúra a legmegfelelőbb módja a nem triviális monolitikus alkalmazások strukturálásának.

Monolitikus alkalmazások esetén az Application Core, az infrastruktúra és a felhasználói felület projektjei egyetlen alkalmazásként futnak. A futtatókörnyezeti alkalmazásarchitektúra az 5–12. ábrához hasonló lehet.

ASP.NET Core Architecture 2

5–12. ábra. Minta ASP.NET Core-alkalmazás futtatókörnyezeti architektúráját.

Kód rendszerezése a Tiszta architektúrában

A Tiszta architektúra megoldásban minden projektnek egyértelmű felelőssége van. Ezért bizonyos típusok minden projekthez tartoznak, és gyakran megtalálja az ilyen típusú mappákat a megfelelő projektben.

Application Core

Az Application Core tartalmazza az üzleti modellt, amely entitásokat, szolgáltatásokat és interfészeket tartalmaz. Ezek a felületek absztrakciókat tartalmaznak az infrastruktúra használatával végrehajtandó műveletekhez, például adathozzáféréshez, fájlrendszer-hozzáféréshez, hálózati hívásokhoz stb. Előfordulhat, hogy az ezen a rétegen definiált szolgáltatásoknak vagy felületeknek olyan nem entitástípusokkal kell működniük, amelyek nem függenek a felhasználói felülettel vagy az infrastruktúrával. Ezek definiálhatók egyszerű adatátviteli objektumokként (DTO-kként).

Application Core-típusok
  • Entitások (üzletimodell-osztályok, amelyek megmaradnak)
  • Összesítések (entitáscsoportok)
  • Interfészek
  • Tartományi szolgáltatások
  • Specifikációk
  • Egyéni kivételek és védelmi záradékok
  • Tartományi események és kezelők

Infrastruktúra

Az infrastruktúraprojekt általában adathozzáférési implementációkat tartalmaz. Egy tipikus ASP.NET Core-webalkalmazásban ezek az implementációk közé tartozik az Entity Framework (EF) DbContext, a definiált EF Core-objektumok Migration és az adathozzáférés implementálási osztályai. Az adathozzáférési implementációs kód absztrakciójának leggyakoribb módja az adattár tervezési mintájának használata.

Az adathozzáférési implementációk mellett az infrastruktúraprojektnek olyan szolgáltatások implementációit is tartalmaznia kell, amelyeknek az infrastruktúra-problémákkal kell foglalkozniuk. Ezeknek a szolgáltatásoknak az Application Core-ban meghatározott interfészeket kell implementálniuk, ezért az infrastruktúrának hivatkoznia kell az Application Core-projektre.

Infrastruktúratípusok
  • EF Core-típusok (DbContext, Migration)
  • Adathozzáférés implementálási típusai (adattárak)
  • Infrastruktúra-specifikus szolgáltatások (példáulFileLogger)SmtpNotifier

Felhasználói felületi réteg

Az ASP.NET Core MVC-alkalmazás felhasználói felületi rétege az alkalmazás belépési pontja. Ennek a projektnek hivatkoznia kell az Application Core-projektre, és típusainak szigorúan az Application Core-ban meghatározott interfészeken keresztül kell működnie az infrastruktúrával. A felhasználói felületi rétegben nem szabad engedélyezni az infrastruktúraréteg-típusok közvetlen példányosítását vagy statikus hívásait.

Felhasználói felületi rétegtípusok
  • Vezérlők
  • Egyéni szűrők
  • Egyéni köztes szoftver
  • Nézetek
  • ViewModels
  • Indítás

Az Startup osztály- vagy Program.cs fájl felelős az alkalmazás konfigurálásáért, valamint a megvalósítási típusok illesztőkhöz való csatlakoztatásáért. A logika végrehajtásának helye az alkalmazás összetételének gyökere, és ez teszi lehetővé, hogy a függőséginjektálás futásidőben megfelelően működjön.

Feljegyzés

Ahhoz, hogy az alkalmazás indítása során függőséginjektálást lehessen létrehozni, előfordulhat, hogy a felhasználói felületi réteg projektjének hivatkoznia kell az infrastruktúraprojektre. Ez a függőség kiküszöbölhető, legegyszerűbben egy egyéni DI-tároló használatával, amely beépített támogatást nyújt a szerelvények típusok betöltéséhez. A minta alkalmazásában a legegyszerűbb módszer az, hogy lehetővé teszi a felhasználói felületi projekt számára, hogy hivatkozzon az infrastruktúraprojektre (a fejlesztőknek azonban az infrastruktúraprojektben szereplő típusokra való tényleges hivatkozásokat az alkalmazás összetételének gyökerére kell korlátozniuk).

Monolitikus alkalmazások és tárolók

Létrehozhat egyetlen és monolitikus üzembe helyezésen alapuló webalkalmazást vagy szolgáltatást, és üzembe helyezheti tárolóként. Előfordulhat, hogy az alkalmazás nem monolitikus, hanem több kódtárba, összetevőbe vagy rétegbe van rendezve. Külsőleg egyetlen tároló egyetlen folyamattal, egyetlen webalkalmazással vagy egyetlen szolgáltatással.

A modell kezeléséhez egyetlen tárolót kell üzembe helyeznie az alkalmazás megjelenítéséhez. A méretezéshez csak adjon hozzá további másolatokat 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.

Figure 5-13

Az 5–13. ábrán látható módon az egyes tárolókon belül több összetevő/kódtár vagy belső réteg is szerepelhet. Azonban a "tároló egy dolgot csinál, és egy folyamatban" elv alapján a monolitikus minta ütközés lehet.

Ennek a megközelítésnek a hátránya, ha/amikor 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ás néhány része a skálázást igénylő fulladási pontok, míg más összetevők kevesebbet használnak.

A tipikus e-kereskedelmi példát használva valószínűleg a termékinformációs összetevőt kell skáláznia. Sokkal több ügyfél böngészik a termékeket, mint megvásárolni ő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 valószínűleg csak néhány alkalmazottja van egyetlen régióban, akiknek kezelniük kell a tartalom- és marketingkampányokat. A monolitikus kialakítás skálázásával az összes kód többször lesz üzembe helyezve.

A "mindent skálázással" kapcsolatos probléma mellett az egyetlen összetevő módosításaihoz 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 gyakori, és számos szervezet fejleszt ezzel az architekturális megközelítéssel. Sokan rendelkeznek elég jó eredménnyel, míg mások elérik a korlátokat. Sokan ebben a modellben tervezték az alkalmazásaikat, mert az eszközök és az infrastruktúra túl nehézkes volt a szolgáltatásorientált architektúrák (SOA) létrehozásához, és az alkalmazás bővüléséig nem láttak rá igényt. Ha úgy találja, hogy túllépi a monolitikus megközelítés korlátait, az alkalmazás felosztása a tárolók és mikroszolgáltatások jobb kihasználása érdekében a következő logikai lépés lehet.

Figure 5-14

A monolitikus alkalmazások üzembe helyezése a Microsoft Azure-ban minden példányhoz dedikált virtuális gépek használatával érhető el. 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ások monolitikus alkalmazásokat futtathatnak, és egyszerűen méretezhetik a példányokat anélkül, hogy a virtuális gépeket kellene kezelni. Azure-alkalmazás szolgáltatások egyetlen Docker-tárolópéldányt is futtathatnak, ami leegyszerűsíti az üzembe helyezést. A Docker használatával egyetlen virtuális gépet helyezhet üzembe Docker-gazdagépként, és több példányt is futtathat. Az Azure Balancer használatával az 5–14. ábrán látható módon kezelheti a skálázást.

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

Tárolóként üzembe helyezett monolitikus alkalmazás

A tárolók használatának számos előnye van a monolitikus alkalmazástelepítések kezeléséhez. A tárolópéldányok skálázása sokkal gyorsabb és egyszerűbb, mint a további virtuális gépek üzembe helyezése. Még akkor is időt vesz igénybe, ha virtuálisgép-méretezési csoportokat használ a virtuális gépek méretezéséhez. Ha alkalmazáspéldányként van üzembe helyezve, az alkalmazás konfigurációja a virtuális gép részeként lesz felügyelve.

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, és felgyorsítják a bevezetést. A Docker-példányok lebontása olyan egyszerű, mint egy docker stop parancs kiadása, általában kevesebb mint egy másodperc alatt befejeződik.

Mivel a tárolók eleve nem módosíthatók a tervezés során, soha nem kell aggódnia a sérült virtuális gépek miatt, míg a frissítési szkriptek elfelejthetik figyelembe venni a lemezen maradt bizonyos konfigurációkat vagy fájlokat.

A Docker-tárolók egyszerűbb webalkalmazások monolitikus üzembe helyezéséhez használhatók. Ez a megközelítés javítja a folyamatos integrációt és a folyamatos üzembehelyezési folyamatokat, és elősegíti az üzembe helyezés sikerességét. Nincs több "Működik a gépemen, miért nem működik éles környezetben?"

A mikroszolgáltatás-alapú architektúra számos előnnyel rendelkezik, de ezek az előnyök a megnövekedett összetettség költségével járnak. Bizonyos esetekben a költségek meghaladják az előnyöket, ezért egy monolitikus üzembehelyezési alkalmazás, amely egyetlen tárolóban vagy csak néhány tárolóban fut, jobb megoldás.

Előfordulhat, hogy egy monolitikus alkalmazás nem bontható le könnyen jól elválasztott mikroszolgáltatásokra. A mikroszolgáltatásoknak egymástól függetlenül kell működnie, hogy rugalmasabb alkalmazást biztosítsanak. Ha nem tud független funkciószeleteket szolgáltatni az alkalmazáshoz, az elkülönítése csak összetettebbé teszi az alkalmazást.

Előfordulhat, hogy egy alkalmazásnak még nem kell egymástól függetlenül méreteznie a funkciókat. Sok alkalmazás, ha egyetlen példányon túlra kell méreteznie, ezt a teljes példány klónozásának viszonylag egyszerű folyamatával teheti meg. Az alkalmazás különálló szolgáltatásokra való elkülönítésének további munkája minimális előnyt biztosít az alkalmazás teljes példányainak skálázása esetén egyszerű és költséghatékony.

Az alkalmazás fejlesztésének korai szakaszában lehet, hogy nem biztos benne, hogy hol vannak a természetes funkcionális határok. A minimálisan életképes termék fejlesztése során előfordulhat, hogy a természetes elkülönítés még nem jött létre. Egyes feltételek ideiglenesek lehetnek. Első lépésként létrehozhat egy monolitikus alkalmazást, majd elkülöníthet néhány, mikroszolgáltatásként fejlesztendő és üzembe helyezendő funkciót. Előfordulhat, hogy az alkalmazás problématerülete szempontjából más feltételek is nélkülözhetetlenek, ami azt jelenti, hogy az alkalmazás soha nem lesz több mikroszolgáltatásra bontva.

Az alkalmazások több különálló folyamatra való elkülönítése többletterhelést is jelent. A funkciók különböző folyamatokra való elkülönítése összetettebb. A kommunikációs protokollok összetettebbé válnak. Metódushívások helyett a szolgáltatások közötti aszinkron kommunikációt kell használnia. Amikor egy mikroszolgáltatás-architektúrára vált, hozzá kell adnia az eShopOnContainers alkalmazás mikroszolgáltatás-verziójában implementált számos építőelemet: az eseménybuszkezelést, az üzenet rugalmasságát és újrapróbálkozását, a végleges konzisztenciát és egyebeket.

A sokkal egyszerűbb eShopOnWeb referenciaalkalmazás támogatja az egytárolós monolitikus tároló használatát. Az alkalmazás egy olyan webalkalmazást tartalmaz, amely hagyományos MVC-nézeteket, webes API-kat és Razor Pages-eket tartalmaz. Igény szerint futtathatja az alkalmazás Blazor-alapú rendszergazdai összetevőjét, amelyhez külön API-projekt is szükséges.

Az alkalmazás a megoldás gyökeréből indítható el a parancsok és docker-compose up a docker-compose build parancsok használatával. Ez a parancs konfigurál egy tárolót a webpéldányhoz a Dockerfile webes projekt gyökérkönyvtárában található adatok használatával, és a tárolót egy megadott porton futtatja. Az alkalmazás forrását letöltheti a GitHubról, és helyileg futtathatja. Még ennek a monolitikus alkalmazásnak is előnye, hogy tárolókörnyezetben van üzembe helyezve.

Például a tárolóalapú üzembe helyezés azt jelenti, hogy az alkalmazás minden példánya ugyanabban a környezetben fut. Ez a megközelítés magában foglalja azt a fejlesztői környezetet, ahol a korai tesztelés és fejlesztés zajlik. A fejlesztői csapat egy olyan tárolóalapú környezetben futtathatja az alkalmazást, amely megfelel az éles környezetnek.

Emellett a tárolóalapú alkalmazások alacsonyabb költséggel skálázhatók fel. A tárolókörnyezet használata nagyobb erőforrás-megosztást tesz lehetővé, mint a hagyományos virtuálisgép-környezetek.

Végül az alkalmazás tárolóba helyezése különválasztja az üzleti logikát és a tárolókiszolgálót. Ahogy az alkalmazás felskálázható, a több tároló mindegyike egyetlen fizikai tárolóeszközre támaszkodik. Ez a tárolóeszköz általában egy SQL Server-adatbázist futtató magas rendelkezésre állású kiszolgáló.

Docker-támogatás

A eShopOnWeb projekt .NET-en fut. Ezért Linux- vagy Windows-alapú tárolókban is futtatható. Vegye figyelembe, hogy a Docker üzembe helyezése esetén ugyanazt a gazdagéptípust szeretné használni az SQL Serverhez. A Linux-alapú tárolók kisebb erőforrásigényt eredményeznek, és előnyben részesítik.

A Visual Studio 2017-et vagy újabb verziót használhatja Docker-támogatás meglévő alkalmazásokhoz való hozzáadásához, ha a jobb gombbal az Megoldáskezelő egyik projektére kattint, majd a Docker-támogatás hozzáadása>lehetőséget választja. Ez a lépés hozzáadja a szükséges fájlokat, és módosítja a projektet a használatukhoz. Az aktuális eShopOnWeb minta már tartalmazza ezeket a fájlokat.

A megoldásszintű docker-compose.yml fájl információkat tartalmaz arról, hogy milyen rendszerképeket kell létrehozni, és milyen tárolókat kell elindítani. A fájl lehetővé teszi, hogy a docker-compose parancs használatával egyszerre több alkalmazást is elindítson. Ebben az esetben csak a webes projektet indítja el. Függőségek konfigurálására is használható, például egy külön adatbázistárolóra.

version: '3'

services:
  eshopwebmvc:
    image: eshopwebmvc
    build:
      context: .
      dockerfile: src/Web/Dockerfile
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "5106:5106"

networks:
  default:
    external:
      name: nat

A docker-compose.yml fájl a Dockerfile projektben találhatóra hivatkozik Web . Ez Dockerfile adja meg, hogy melyik alaptárolót használja a rendszer, és hogyan konfigurálja az alkalmazást rajta. A Web' Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /app

COPY *.sln .
COPY . .
WORKDIR /app/src/Web
RUN dotnet restore

RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/src/Web/out ./

ENTRYPOINT ["dotnet", "Web.dll"]

Docker-problémák elhárítása

A tárolóalapú alkalmazás futtatása után az továbbra is fut, amíg le nem állítja. Megtekintheti, hogy mely tárolók futnak a docker ps paranccsal. A futó tárolók leállításához használja a docker stop parancsot, és adja meg a tárolóazonosítót.

Vegye figyelembe, hogy a Docker-tárolók futtatása olyan porthoz lehet kötve, amelyet egyébként a fejlesztési környezetben próbál használni. Ha egy alkalmazást a futó Docker-tárolóval megegyező porton próbál futtatni vagy hibakeresésre használni, hibaüzenet jelenik meg, amely szerint a kiszolgáló nem tud csatlakozni az adott porthoz. A tároló leállításának ismét meg kell oldania a problémát.

Ha Docker-támogatást szeretne hozzáadni az alkalmazáshoz a Visual Studióval, győződjön meg arról, hogy a Docker Desktop fut. A varázsló nem fog megfelelően futni, ha a Docker Desktop nem fut a varázsló indításakor. Emellett a varázsló megvizsgálja az aktuális tárolóválasztást a megfelelő Docker-támogatás hozzáadásához. Ha hozzá szeretné adni a Windows-tárolók támogatását, akkor futtatnia kell a varázslót, amíg a Docker Desktop windowsos tárolókkal van konfigurálva. Ha hozzá szeretné adni a Linux-tárolók támogatását, futtassa a varázslót, miközben a Docker Linux-tárolókkal van konfigurálva.

Egyéb webalkalmazás-architektúrastílusok

  • Webes üzenetsor-feldolgozó: Az architektúra alapvető összetevői az ügyfélkéréseket kiszolgáló webes kezelőfelületek, valamint egy erőforrás-igényes feladatokat, hosszan futó munkafolyamatokat vagy kötegelt feladatokat végző feldolgozó. A webes előtér egy üzenetsor segítségével kommunikál a feldolgozóval.
  • N szintű: Az N szintű architektúra logikai rétegekre és fizikai szintekre osztja az alkalmazásokat.
  • Mikroszolgáltatás: A mikroszolgáltatás-architektúra kis, autonóm szolgáltatások gyűjteményéből áll. Minden szolgáltatás önálló, és egyetlen üzleti képességet kell implementálnia egy határos környezetben.

Hivatkozások – Gyakori webarchitektúrák

Előzőkövetkező