Tárolóalapú mikroszolgáltatások

Tipp.

Ez a tartalom egy részlet az eBook, Enterprise Application Patterns Using .NET MAUI, elérhető a .NET Docs vagy egy ingyenesen letölthető PDF, hogy lehet olvasni offline.

PDF letöltése

Az ügyfélkiszolgálói alkalmazások fejlesztése során az egyes szinteken meghatározott technológiákat használó rétegzett alkalmazások létrehozására összpontosítottak. Ezeket az alkalmazásokat gyakran monolitikusnak nevezik, és a csúcsterhelésekhez előre skálázott hardverre vannak csomagolva. Ennek a fejlesztési megközelítésnek a fő hátránya az egyes szinteken belüli összetevők szoros összekapcsolása, hogy az egyes összetevők nem méretezhetők egyszerűen, és a tesztelés költsége. Az egyszerű frissítések előre nem látható hatással lehetnek a szint többi részére, ezért az alkalmazásösszetevők módosításához újra kell tesztelni és újra üzembe helyezni a teljes szintet.

A felhő korában különösen fontos, hogy az egyes összetevőket nem lehet egyszerűen méretezni. A monolitikus alkalmazások tartományspecifikus funkciókat tartalmaznak, és általában funkcionális rétegek, például előtérbeli, üzleti logika és adattárolás szerint vannak osztva. Az alábbi képen látható, hogy egy monolitikus alkalmazás úgy van skálázva, hogy a teljes alkalmazást több gépre klónozza.

Mikroszolgáltatások

A mikroszolgáltatások eltérő megközelítést kínálnak az alkalmazások fejlesztéséhez és üzembe helyezéséhez, amely megfelel a modern felhőalkalmazások rugalmassági, méretezési és megbízhatósági követelményeinek. A mikroszolgáltatási alkalmazások független összetevőkre oszlanak, amelyek együttműködve biztosítják az alkalmazás általános funkcióit. A mikroszolgáltatás kifejezés hangsúlyozza, hogy az alkalmazásoknak olyan szolgáltatásokból kell lenniük, amelyek elég kicsik ahhoz, hogy tükrözzék az adott aggályokat, így minden mikroszolgáltatás egyetlen függvényt valósít meg. Emellett minden mikroszolgáltatás jól meghatározott szerződésekkel rendelkezik, amelyekkel más mikroszolgáltatások kommunikálnak és adatokat osztanak meg. A mikroszolgáltatások tipikus példái közé tartoznak a bevásárlókocsik, a leltárfeldolgozás, a vásárlási alrendszerek és a fizetésfeldolgozás.

A mikroszolgáltatások egymástól függetlenül skálázhatók az egymással skálázható óriás monolitikus alkalmazásokhoz képest. Ez azt jelenti, hogy egy adott funkcionális terület, amely nagyobb feldolgozási teljesítményt vagy hálózati sávszélességet igényel az igények támogatásához, méretezhető ahelyett, hogy szükségtelenül skálázható lenne a többi alkalmazásterület. Az alábbi ábra ezt a megközelítést mutatja be, ahol a mikroszolgáltatások egymástól függetlenül vannak üzembe helyezve és skálázva, és szolgáltatások példányait hoznak létre a gépeken.

A mikroszolgáltatások vertikális felskálázása szinte azonnali lehet, ami lehetővé teszi, hogy az alkalmazás alkalmazkodjon a terhelések változásához. Előfordulhat például, hogy egy alkalmazás webes funkcióinak egyetlen mikroszolgáltatása az egyetlen mikroszolgáltatás, amelyet fel kell méretezni a további bejövő forgalom kezeléséhez.

Az alkalmazások méretezhetőségének klasszikus modellje egy elosztott terhelésű, állapot nélküli szint és egy megosztott külső adattár, amely állandó adatokat tárol. Az állapotalapú mikroszolgáltatások a saját állandó adataikat kezelik, általában helyben tárolva azokat azon kiszolgálókon, amelyeken elhelyezték őket, hogy elkerüljék a hálózati hozzáférés többletterhelését és a szolgáltatásközi műveletek összetettségét. Ez lehetővé teszi az adatok lehető leggyorsabb feldolgozását, és kiküszöbölheti a gyorsítótárazási rendszerek szükségességét. Emellett a méretezhető állapotalapú mikroszolgáltatások általában particionálják az adatokat a példányaik között az adatméret kezelése és az átviteli sebesség kezelése érdekében, amelyen túl egyetlen kiszolgáló is képes támogatni.

A mikroszolgáltatások a független frissítéseket is támogatják. A mikroszolgáltatások közötti laza összekapcsolás gyors és megbízható alkalmazásfejlődést biztosít. A független, elosztott jellegük segít a frissítések gördülésében, ahol egy adott mikroszolgáltatás példányainak csak egy részhalmaza frissül. Ezért probléma észlelése esetén a hibás frissítés visszaállítható, mielőtt az összes példány frissítené a hibás kódot vagy konfigurációt. Hasonlóképpen a mikroszolgáltatások általában sémaverziót használnak, hogy az ügyfelek egységes verziót láthassanak a frissítések alkalmazásakor, függetlenül attól, hogy melyik mikroszolgáltatás-példánysal kommunikálnak.

Ezért a mikroszolgáltatási alkalmazások számos előnnyel rendelkeznek a monolitikus alkalmazásokkal szemben:

• Mindegyik mikroszolgáltatás viszonylag kicsi, könnyen kezelhető és fejleszthető.
• Minden mikroszolgáltatás más szolgáltatásoktól függetlenül fejleszthető és telepíthető.
• Az egyes mikroszolgáltatások egymástól függetlenül méretezhetők. Előfordulhat például, hogy egy katalógusszolgáltatást vagy bevásárlókosár-szolgáltatást többre kell méretezni, mint egy megrendelési szolgáltatást. Ezért az eredményként kapott infrastruktúra hatékonyabban fogja felhasználni az erőforrásokat a horizontális felskálázáskor.
• Minden mikroszolgáltatás elkülöníti a problémákat. Ha például egy szolgáltatásban probléma van, az csak az adott szolgáltatást érinti. A többi szolgáltatás továbbra is kezelheti a kéréseket.
• Minden mikroszolgáltatás a legújabb technológiákat használhatja. Mivel a mikroszolgáltatások autonómak és egymás mellett futnak, a legújabb technológiák és keretrendszerek használhatók ahelyett, hogy egy monolitikus alkalmazás által esetleg használt régebbi keretrendszert kellene használniuk.

A mikroszolgáltatás-alapú megoldásoknak azonban vannak lehetséges hátrányai is:

• Az alkalmazások mikroszolgáltatásokra való particionálásának kiválasztása kihívást jelenthet, mivel minden mikroszolgáltatásnak teljesen autonómnak kell lennie, teljes körűnek kell lennie, beleértve az adatforrásokért való felelősséget is.
• A fejlesztőknek szolgáltatásközi kommunikációt kell megvalósítaniuk, ami összetettebbé és késésebbé teszi az alkalmazást.
• Több mikroszolgáltatás közötti atomi tranzakciók általában nem lehetségesek. Ezért az üzleti követelményeknek meg kell felelnie a mikroszolgáltatások közötti végleges konzisztenciának.
• Az éles környezetben üzemeltetési összetettség áll fenn egy olyan rendszer üzembe helyezésében és kezelésében, amely számos független szolgáltatás számára veszélybe került.
• A közvetlen ügyfél-mikroszolgáltatások közötti kommunikáció megnehezítheti a mikroszolgáltatások szerződéseinek újrabontását. Előfordulhat például, hogy idővel módosítania kell a rendszer szolgáltatásokra való particionálásának módját. Előfordulhat, hogy egyetlen szolgáltatás két vagy több szolgáltatásra oszlik, és két szolgáltatás egyesülhet. Amikor az ügyfelek közvetlenül kommunikálnak a mikroszolgáltatásokkal, ez az újrabontási munka megszakíthatja az ügyfélalkalmazásokkal való kompatibilitást.

Tárolóra bontás

A tárolók a szoftverfejlesztés egyik megközelítése, amelyben egy alkalmazás és annak verziószámozott függőségei, valamint az üzembehelyezési jegyzékfájlként absztrakciós környezetkonfigurációja tárolórendszerképként van csomagolva, egységként tesztelve és egy gazdagép operációs rendszerében üzembe helyezve.

A tárolók elszigetelt, erőforrás-vezérelt és hordozható üzemeltetési környezetek, amelyekben az alkalmazások anélkül futtathatók, hogy más tárolók vagy a gazdagép erőforrásait érintenék. Ezért a tárolók úgy néznek ki és viselkednek, mint egy újonnan telepített fizikai számítógép vagy egy virtuális gép.

Számos hasonlóság van a tárolók és a virtuális gépek között, ahogy az alább látható.

A tároló operációs rendszert futtat, fájlrendszerrel rendelkezik, és úgy érhető el hálózaton keresztül, mintha fizikai vagy virtuális gép lenne. A tárolók által használt technológia és fogalmak azonban nagyon eltérnek a virtuális gépektől. A virtuális gépek közé tartoznak az alkalmazások, a szükséges függőségek és a teljes vendég operációs rendszer. A tárolók magukban foglalják az alkalmazást és annak függőségeit, de megosztják az operációs rendszert más tárolókkal, elkülönített folyamatként futnak a gazdagép operációs rendszerén (kivéve a Hyper-V-tárolókat, amelyek tárolónként egy speciális virtuális gépen futnak). Ezért a tárolók erőforrásokat osztanak meg, és általában kevesebb erőforrást igényelnek, mint a virtuális gépek.

A tárolóalapú fejlesztési és üzembe helyezési megközelítés előnye, hogy kiküszöböli a környezet inkonzisztens beállításaiból és az azokkal kapcsolatos problémákból eredő problémák többségét. A tárolók emellett lehetővé teszik az alkalmazások gyors felskálázási funkcióját, ha szükség szerint új tárolókat instancingolnak.

A tárolók létrehozása és használata során a legfontosabb fogalmak a következők:

Fogalom	Leírás
Tárológazda	A tárolók üzemeltetésére konfigurált fizikai vagy virtuális gép. A tárológazda egy vagy több tárolót fog futtatni.
Tárolólemezkép	A rendszerképek egymásra halmozott rétegzett fájlrendszerek egyesítéséből állnak, és egy tároló alapját alkotják. A rendszerképek állapota nem változik, mivel különböző környezetekben van üzembe helyezve.
Tároló	A tároló egy rendszerkép futtatókörnyezeti példánya.
Tároló operációsrendszer-lemezképe	A tárolók lemezképekből vannak üzembe helyezve. A tároló operációs rendszer lemezképe a tárolót alkotó, potenciálisan sok lemezképréteg első rétege. A tároló operációs rendszere nem módosítható, és nem módosítható.
Tárolóadattár	Minden alkalommal, amikor létrehoz egy tárolórendszerképet, a rendszerkép és függőségei egy helyi adattárban lesznek tárolva. Ezek a rendszerképek többször is felhasználhatók a tároló gazdagépén. A tárolólemezképek nyilvános vagy privát beállításjegyzékben is tárolhatók, például a Docker Hubban, így különböző tároló gazdagépeken is használhatók.

A vállalatok egyre gyakrabban vezetnek be tárolókat mikroszolgáltatás-alapú alkalmazások megvalósításakor, és a Docker lett a legtöbb szoftverplatform és felhőszolgáltató által elfogadott szabványos tároló-implementáció.

Az eShop referenciaalkalmazás a Docker használatával üzemeltet négy tárolóalapú háttérbeli mikroszolgáltatást az alábbi ábrán látható módon.

A referenciaalkalmazás háttérszolgáltatásainak architektúrája több autonóm alrendszerre oszlik, együttműködő mikroszolgáltatások és tárolók formájában. Minden mikroszolgáltatás egyetlen funkcióterületet biztosít: egy identitásszolgáltatást, egy katalógusszolgáltatást, egy rendelési szolgáltatást és egy kosárszolgáltatást.

Minden mikroszolgáltatás saját adatbázissal rendelkezik, így teljesen elkülöníthető a többi mikroszolgáltatástól. Szükség esetén a különböző mikroszolgáltatásokból származó adatbázisok közötti konzisztencia alkalmazásszintű események használatával érhető el. További információ: Mikroszolgáltatások közötti kommunikáció.

Kommunikáció az ügyfél és a mikroszolgáltatások között

Az eShop többplatformos alkalmazás közvetlen ügyfél-mikroszolgáltatás-kommunikációval kommunikál a tárolóalapú háttérbeli mikroszolgáltatásokkal, ahogy az alább látható.

Az ügyfelek közötti közvetlen kommunikáció révén a többplatformos alkalmazás az egyes mikroszolgáltatásokhoz közvetlenül a nyilvános végponton keresztül küld kéréseket, mikroszolgáltatásonként eltérő TCP-porttal. Éles környezetben a végpont általában a mikroszolgáltatás terheléselosztójára van leképezve, amely elosztja a kérelmeket az elérhető példányok között.

Tipp.

Fontolja meg az API Gateway-kommunikáció használatát.

A közvetlen ügyfél-mikroszolgáltatások közötti kommunikációnak lehetnek hátrányai egy nagy és összetett mikroszolgáltatás-alapú alkalmazás létrehozásakor, de ez több mint elegendő egy kis alkalmazáshoz. Fontolja meg az API-átjárók közötti kommunikáció használatát egy nagy mikroszolgáltatás-alapú alkalmazás több tíz mikroszolgáltatással történő tervezésekor.

Mikroszolgáltatások közötti kommunikáció

A mikroszolgáltatás-alapú alkalmazások elosztott rendszerek, amelyek több gépen is futhatnak. Minden szolgáltatáspéldány általában folyamat. A szolgáltatásoknak ezért az egyes szolgáltatások jellegétől függően folyamatközi kommunikációs protokollt kell használniuk, például HTTP, TCP, Advanced Message Queuing Protocol (AMQP) vagy bináris protokollokat.

A mikroszolgáltatások közötti kommunikáció két gyakori módszere a HTTP-alapú REST-kommunikáció az adatok lekérdezésekor, valamint az egyszerűsített aszinkron üzenetküldés, amikor több mikroszolgáltatáson keresztül kommunikálja a frissítéseket.

Az aszinkron üzenetkezelésen alapuló eseményvezérelt kommunikáció kritikus fontosságú a módosítások több mikroszolgáltatás közötti propagálása során. Ezzel a megközelítéssel egy mikroszolgáltatás közzétesz egy eseményt, amikor valami jelentős történik, például amikor frissít egy üzleti entitást. Más mikroszolgáltatások feliratkoznak ezekre az eseményekre. Ezután, amikor egy mikroszolgáltatás eseményt kap, frissíti a saját üzleti entitásait, ami pedig további események közzétételéhez vezethet. Ez a közzététel-feliratkozás funkció általában egy eseménybuszsal érhető el.

Az eseménybuszok lehetővé teszik a mikroszolgáltatások közötti közzétételi-előfizetési kommunikációt anélkül, hogy az összetevőknek explicit módon tisztában kellene lenniük egymással, ahogy az alább látható.

Az alkalmazás szempontjából az eseménybusz egyszerűen egy felületen keresztül közzétett közzétételi-előfizetési csatorna. Az eseménybusz implementálásának módja azonban eltérő lehet. Egy eseménybusz implementációja például a RabbitMQ, az Azure Service Bus vagy más szolgáltatásbuszokat, például az NServiceBust és a MassTransitet használhatja. Az alábbi ábra bemutatja, hogyan használják az eseménybuszt az eShop referenciaalkalmazásban.

A RabbitMQ használatával implementált eShop eseménybusz egy-aszinkron közzétételi-feliratkozási funkciót biztosít. Ez azt jelenti, hogy az esemény közzététele után több előfizető is figyelheti ugyanazt az eseményt. Az alábbi ábra ezt a kapcsolatot szemlélteti.

Ez az egy-a-többhöz kommunikációs megközelítés eseményeket használ több szolgáltatásra kiterjedő üzleti tranzakciók implementálásához, biztosítva a szolgáltatások közötti végleges konzisztenciát. A végleges konzisztens tranzakció elosztott lépések sorozatából áll. Ezért amikor a felhasználói profilú mikroszolgáltatás megkapja az UpdateUser parancsot, frissíti a felhasználó adatait az adatbázisban, és közzéteszi a UserUpdated eseményt az eseménybuszon. Mind a kosár mikroszolgáltatás, mind a rendelési mikroszolgáltatás feliratkozott az esemény fogadására, és válaszul frissítse a vevő adatait a megfelelő adatbázisukban.

Összegzés

A mikroszolgáltatások olyan megközelítést kínálnak az alkalmazások fejlesztéséhez és üzembe helyezéséhez, amelyek megfelelnek a modern felhőalkalmazások rugalmassági, skálázási és megbízhatósági követelményeinek. A mikroszolgáltatások egyik fő előnye, hogy egymástól függetlenül skálázhatók, ami azt jelenti, hogy egy adott funkcionális terület méretezhető, amely nagyobb feldolgozási teljesítményt vagy hálózati sávszélességet igényel a kereslet támogatásához anélkül, hogy szükségtelenül skálázzák az alkalmazás azon területeit, amelyek nem tapasztalnak megnövekedett keresletet.

A tároló egy elkülönített, erőforrás-vezérlésű és hordozható üzemeltetési környezet, ahol az alkalmazások anélkül futtathatók, hogy más tárolók vagy a gazdagép erőforrásait érintenék. A vállalatok egyre gyakrabban vezetnek be tárolókat a mikroszolgáltatás-alapú alkalmazások megvalósításakor, és a Docker a legtöbb szoftverplatform és felhőszolgáltató által elfogadott szabványos tároló-implementációvá vált.