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

Adatelkentség mikroszolgáltatásonként

  • Cikk

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

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

A mikroszolgáltatások architektúrájának fontos szabálya, hogy minden mikroszolgáltatásnak saját tartományadataival és logikájával kell rendelkeznie. Ahogy a teljes alkalmazásnak is megvan a logikája és az adatai, úgy minden mikroszolgáltatásnak saját logikát és adatokat kell birtokolnia egy autonóm életciklus alatt, mikroszolgáltatásonként független üzembe helyezéssel.

Ez azt jelenti, hogy a tartomány fogalmi modellje eltérő lesz az alrendszerek és a mikroszolgáltatások között. Fontolja meg a nagyvállalati alkalmazásokat, ahol az ügyfélkapcsolat-kezelési (CRM-) alkalmazások, a tranzakciós vásárlási alrendszerek és az ügyféltámogatási alrendszerek minden egyes hívás egyedi ügyfél entitásattribútumokat és adatokat használnak, és ahol mindegyik más kötött környezetet (BC) használ.

Ez az elv hasonló a tartományalapú tervezésben (DDD), ahol minden egyes kötött környezetnek vagy autonóm alrendszernek vagy szolgáltatásnak saját tartománymodellje (adat és logika és viselkedés) kell lennie. Minden DDD-kötött környezet egy üzleti mikroszolgáltatáshoz (egy vagy több szolgáltatáshoz) kapcsolódik. A határolókeret-minta ezen pontja a következő szakaszban lesz kibontva.

Másrészt a sok alkalmazásban használt hagyományos (monolitikus adatok) megközelítés egyetlen központosított adatbázissal vagy csak néhány adatbázissal rendelkezik. Ez gyakran egy normalizált SQL-adatbázis, amelyet a teljes alkalmazáshoz és annak belső alrendszereihez használnak a 4–7. ábrán látható módon.

Diagram showing the two database approaches.

4-7. ábra. Adatelkonvertség összehasonlítása: monolitikus adatbázis és mikroszolgáltatások

A hagyományos megközelítésben egyetlen adatbázis van megosztva az összes szolgáltatásban, jellemzően rétegzett architektúrában. A mikroszolgáltatás-megközelítésben minden mikroszolgáltatás a saját modelljét/adatait birtokolja. A központosított adatbázis-megközelítés kezdetben egyszerűbbnek tűnik, és úgy tűnik, hogy lehetővé teszi az entitások újrafelhasználását a különböző alrendszerekben, hogy minden konzisztens legyen. A valóság azonban az, hogy hatalmas táblákkal végzi, amelyek számos különböző alrendszert szolgálnak ki, és olyan attribútumokat és oszlopokat tartalmaznak, amelyekre a legtöbb esetben nincs szükség. Ez olyan, mintha ugyanazt a fizikai térképet használná egy rövid túraútvonalra, egy egész napos autós kirándulásra és a földrajzi adatok megismerésére.

Egy jellemzően egyetlen relációs adatbázissal rendelkező monolitikus alkalmazásnak két fontos előnye van: az ACID-tranzakciók és az SQL-nyelv, amelyek az alkalmazáshoz kapcsolódó összes táblában és adatban működnek. Ez a megközelítés lehetővé teszi egy olyan lekérdezés egyszerű írását, amely több táblából származó adatokat egyesít.

Az adathozzáférés azonban sokkal bonyolultabbá válik, ha mikroszolgáltatás-architektúrára vált. Még akkor is, ha ACID-tranzakciókat használ egy mikroszolgáltatásban vagy egy határos környezetben, fontos figyelembe venni, hogy az egyes mikroszolgáltatások tulajdonában lévő adatok privátak az adott mikroszolgáltatáshoz, és csak szinkron módon, az API-végpontokon (REST, gRPC, SOAP stb.) vagy aszinkron módon, üzenetküldésen keresztül (AMQP vagy hasonló) érhetők el.

Az adatok beágyazása biztosítja, hogy a mikroszolgáltatások lazán kapcsolódnak egymáshoz, és egymástól függetlenül fejlődhetnek. Ha több szolgáltatás is hozzáfér ugyanazokhoz az adatokhoz, a sémafrissítésekhez az összes szolgáltatás összehangolt frissítése szükséges. Ez megszakítaná a mikroszolgáltatások életciklusának önállóságát. Az elosztott adatstruktúrák azonban azt jelentik, hogy nem lehet egyetlen ACID-tranzakciót létrehozni a mikroszolgáltatások között. Ez viszont azt jelenti, hogy végső konzisztenciát kell használnia, ha egy üzleti folyamat több mikroszolgáltatásra is kiterjed. Ezt sokkal nehezebb implementálni, mint az egyszerű SQL-illesztéseket, mert nem hozhat létre integritási korlátozásokat, és nem használhat elosztott tranzakciókat külön adatbázisok között, amint azt később ismertetjük. Hasonlóképpen, számos más relációsadatbázis-szolgáltatás nem érhető el több mikroszolgáltatásban.

Még tovább haladva a különböző mikroszolgáltatások gyakran különböző típusú adatbázisokat használnak. A modern alkalmazások különböző típusú adatokat tárolnak és dolgoznak fel, és a relációs adatbázis nem mindig a legjobb választás. Bizonyos használati esetekben előfordulhat, hogy egy NoSQL-adatbázis, például az Azure CosmosDB vagy a MongoDB kényelmesebb adatmodellel rendelkezik, és jobb teljesítményt és méretezhetőséget kínál, mint az SQL Server vagy az Azure SQL Database. Más esetekben továbbra is a relációs adatbázis a legjobb módszer. Ezért a mikroszolgáltatás-alapú alkalmazások gyakran SQL- és NoSQL-adatbázisok keverékét használják, amelyet gyakran többplatformos adatmegőrzési megközelítésnek is neveznek.

Az adattárolás particionált, több-perzisztens architektúrája számos előnnyel jár. Ezek közé tartoznak a lazán összekapcsolt szolgáltatások és a jobb teljesítmény, a méretezhetőség, a költségek és a kezelhetőség. Azonban néhány elosztott adatkezelési kihívást is bevezethet, amint azt a jelen fejezet későbbi, "A tartománymodell határainak azonosítása" című szakasza ismerteti.

A mikroszolgáltatások és a Kötött környezet minta közötti kapcsolat

A mikroszolgáltatás fogalma a tartományalapú tervezés (DDD) Kötött környezet (BC) mintájábólszármazik. A DDD úgy foglalkozik a nagy modellekkel, hogy több számítógépre osztja őket, és explicit módon határozza meg a határaikat. Minden BC-nek saját modellel és adatbázissal kell rendelkeznie; hasonlóképpen, minden mikroszolgáltatás a kapcsolódó adatok tulajdonosa. Emellett minden BC általában saját nyelvvel rendelkezik, amely segít a szoftverfejlesztők és a tartományi szakértők közötti kommunikációban.

Ezek a kifejezések (főként tartományi entitások) a mindenütt használt nyelven különböző neveket tartalmazhatnak a különböző kötött környezetekben, még akkor is, ha a különböző tartományi entitások azonos identitással rendelkeznek (vagyis az entitás tárolóból való olvasásához használt egyedi azonosítóval). Egy felhasználói profilhoz kötött környezetben például a felhasználói tartomány entitása megoszthat identitást a vevői tartomány entitásával a rendelési kötött környezetben.

A mikroszolgáltatások ezért olyan, mint a határolókeretes környezetek, de azt is meghatározza, hogy elosztott szolgáltatásról van szó. Külön folyamatként van létrehozva minden egyes kötött környezethez, és a korábban feljegyzett elosztott protokollokat kell használnia, például HTTP/HTTPS, WebSockets vagy AMQP. A Határoló környezet minta azonban nem határozza meg, hogy a kötött környezet elosztott szolgáltatás-e, vagy egyszerűen logikai határ (például általános alrendszer) egy monolitikus üzembehelyezési alkalmazáson belül.

Fontos kiemelni, hogy az egyes kötött környezetekhez tartozó szolgáltatások meghatározása jó kiindulópont. De nem kell a tervét korlátoznia. Néha több fizikai szolgáltatásból álló kötött környezetet vagy üzleti mikroszolgáltatást kell megterveznie. Végső soron azonban mindkét minta – a kötött környezet és a mikroszolgáltatás – szorosan összefügg.

A DDD előnyei a mikroszolgáltatásokból származnak, ha valós határokat kapnak elosztott mikroszolgáltatások formájában. Az olyan ötletek azonban, mint például a modell mikroszolgáltatások közötti megosztása, a kötött környezetekben is szükségesek.

További erőforrások

Előzőkövetkező