Események forráskezelése minta

Ahelyett, hogy a tartomány adatainak csak az aktuális állapotát tárolná, egy csak hozzáfűzéssel bővíthető tár használatával rögzítheti az adatokon végzett műveletek teljes sorozatát is. A tároló rekordrendszerként működik, és a használatával tényleges táblává alakíthatóak tartományi objektumok. Ez egyszerűsítheti a feladatokat az összetett tartományokban, mivel nem szükséges szinkronizálni az adatmodellt és a vállalati tartományt, miközben nő a teljesítmény, a skálázhatóság és a válaszképesség. Emellett konzisztenciát kölcsönöz a tranzakciós adatoknak, és teljeskörű naplókat és előzményeket tárol, ami lehetővé teszi a kompenzáló műveletek végrehajtását.

Kontextus és probléma

A legtöbb alkalmazás adatokkal dolgozik, és a szokásos megközelítés szerint az alkalmazás az adatok aktuális állapotát tárolja, és folyamatosan frissíti, ahogy a felhasználók használják azokat. A hagyományos létrehozási, olvasási, frissítési és törlési (CRUD) modellben például egy tipikus adatfolyamat az adatok beolvasása az áruházból, néhány módosítás végrehajtása és az adatok aktuális állapotának frissítése az új értékekkel – gyakran az adatokat zároló tranzakciók használatával.

A CRUD megközelítésnek vannak bizonyos korlátai:

• A CRUD-rendszerek közvetlenül egy adattáron végeznek frissítési műveleteket. Ezek a műveletek lelassíthatják a teljesítményt és a válaszkészséget, és korlátozhatják a méretezhetőséget a szükséges feldolgozási többletterhelés miatt.

• A nagyszámú egyidejű felhasználót tartalmazó együttműködési tartományokban az adatfrissítés konfliktusok valószínűbbek, mivel a frissítési műveletek egyetlen adatelemen vannak végrehajtva.

• Hacsak nincs egy másik naplózási mechanizmus, amely külön naplóban rögzíti az egyes műveletek részleteit, az előzmények elvesznek.

Megoldás

Az Események forráskezelése minta az adatokon végrehajtott műveletek kezelésére eseménysorozat-alapú megközelítést definiál, amelyben az események egy csak hozzáfűzéssel bővíthető tárban vannak rögzítve. Az alkalmazáskód ez egyes adatműveleteket imperatív módon leíró események sorát küldi a tárolóba, ahol azok megőrződnek. Mindegyik esemény az adatok módosításainak egy halmazát (például AddedItemToOrder) jelöli.

Az eseményeket egy eseménytár őrzi, amely az adatok aktuális állapotát rögzítő rekordrendszerként (mérvadó adatforrásként) működik. Az eseménytár általában közzéteszi ezeket az eseményeket, hogy a felhasználók értesüljenek róluk, és szükség szerint kezelhessék azokat. A fogyasztók például inicializálhatnak olyan feladatokat, amelyek az eseményekben lévő műveleteket más rendszerekre alkalmazzák, vagy egyéb kapcsolódó műveleteket hajtanak végre, amelyek a működéshez szükségesek. Vegyük észre, hogy az eseményeket létrehozó alkalmazáskód elválik az eseményekre feliratkozó rendszerektől.

Az eseménytár által közzétett események tipikus felhasználása az entitások tényleges táblán alapuló nézeteinek karbantartása, ahogy az alkalmazás műveletei módosítják azokat, valamint a külső rendszerekkel való integráció biztosítása. Például a rendszer megtarthatja az összes olyan ügyfélmegrendelés tényleges táblán alapuló nézetét, amelyek a felhasználói felület részein megjelentek. Az alkalmazás új rendeléseket ad hozzá, hozzáadja vagy eltávolítja a rendelés elemeit, és szállítási adatokat ad hozzá. A módosításokat leíró események kezelhetők és használhatók a materializált nézet frissítéséhez.

Az alkalmazások bármikor olvashatják az események előzményeit. Ezután az entitás aktuális állapotának materializálásához használhatja az entitáshoz kapcsolódó összes esemény lejátszásával és felhasználásával. Ez a folyamat igény szerint előfordulhat, hogy a kérések kezelésekor egy tartományi objektumot hoz létre. Vagy a folyamat egy ütemezett tevékenységen keresztül történik, így az entitás állapota materializált nézetként tárolható a bemutató réteg támogatásához.

Az ábrán a minta áttekintése látható, beleértve az eseménystream használata kínálta egyes lehetőségeket, például a tényleges táblán alapuló nézetek létrehozását, az események külső alkalmazásokkal és rendszerekkel való integrálását, valamint az események visszajátszását az adott entitások aktuális állapotai leképezéseinek létrehozásához.

Az Események forráskezelése minta az alábbi előnyöket biztosítja:

• Az események nem módosíthatók, és egy csak hozzáfűzési művelettel tárolhatók. Az eseményt inicializáló felhasználói felület, munkafolyamat vagy folyamat folytatódhat, és az eseményeket kezelő feladatok a háttérben futhatnak. Ez a folyamat, kombinálva azzal a ténnyel, hogy a tranzakciók feldolgozása során nincs versengés, jelentősen javíthatja az alkalmazások teljesítményét és méretezhetőségét, különösen a bemutató szintjén vagy a felhasználói felületen.

• Az események egyszerű objektumok, amelyek leírják a végrehajtott műveletet, valamint az esemény által képviselt művelet leírásához szükséges összes kapcsolódó adatot. Az események közvetlenül nem frissítik az adattárakat. Egyszerűen csak rögzítve vannak, hogy a megfelelő időben kezelhetőek legyenek. Az események használata egyszerűbbé teheti a végrehajtást és a felügyeletet.

• Az események általában jelentéssel bírnak a tartományszakértők számára, miközben az objektumrelációs impedanciaeltérés miatt az összetett adatbázistáblák nehezen érthetőek lehetnek. A táblák olyan mesterséges szerkezetek, amelyek a rendszer aktuális állapotát és nem a bekövetkezett eseményeket mutatják.

• Az Események forráskezelése segítségével megelőzhető, hogy a párhuzamos frissítések ütközést okozzanak, mivel nem szükséges az objektumokat közvetlenül az adattárban frissíteni. Azonban a tartománymodellt továbbra is úgy kell kialakítani, hogy védje magát az olyan kérések ellen, amelyek inkonzisztens állapotot okozhatnak.

• Az események csak hozzáfűző tárolója egy naplónaplót biztosít, amely az adattárakon végrehajtott műveletek monitorozására használható. Az események bármikor újratelepíthetők materializált nézetként vagy kivetítésként, és segíthet a rendszer tesztelésében és hibakeresésében. Emellett az a követelmény, hogy kompenzáló eseményeket használjon a módosítások megszakítására, a visszavont módosítások előzményeit is megadhatja. Ez a képesség nem lenne így, ha a modell az aktuális állapotot tárolja. Az események listája az alkalmazás teljesítményének elemzésére és a felhasználói viselkedési trendek észlelésére is használható. Vagy más hasznos üzleti információk beszerzésére is használható.

• Az eseménytár eseményeket indít, és a feladatok ezekre válaszképp hajtanak végre műveleteket. A feladatok ily módú leválasztása az eseményekről biztosítja a rugalmasságot és a bővíthetőséget. A feladatok ismerik az események típusát és adatait, az eseményeket kiváltó műveleteket azonban nem. További előny, hogy egyszerre több feladat is kezelheti az egyes eseményeket. Ez egyszerűsíti az integrációt az olyan szolgáltatásokkal és rendszerekkel, amelyek csak az eseménytár által kiváltott új eseményeket figyelik. Azonban az Események forráskezelése események általában nagyon alacsony szintűek, így szükség lehet inkább adott integrációs események létrehozására.

Az Események forráskezelése mintát általában a CQRS mintával kombinálva alkalmazzák az adatkezelési feladatoknak az eseményekre való válaszként történő végrehajtásával és a tárolt eseményekből tényleges táblán alapuló nézeteket létrehozásával.

Problémák és megfontolandó szempontok

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

A rendszer végül csak a tényleges táblán alapuló nézetek vagy adatleképezések a visszajátszott adatok alapján való létrehozásával válik konzisztenssé. A kérések kezelése, a közzétett események és az őket kezelő események felhasználói között némi késés áll fenn az alkalmazás eseménytárhoz való hozzáadása között. Ez alatt az idő alatt az entitások további módosításait leíró új események érkezhetnek az eseménytárba. A rendszert úgy kell megtervezni, hogy figyelembe vegye a végleges konzisztenciát ezekben a forgatókönyvekben.

Az eseménytár szolgál az adatok állandó forrásaként, emiatt az eseményadatokat soha nem szabad frissíteni. Az entitások frissítésének egyetlen módja a módosítások visszavonására, ha egy kompenzáló eseményt vesz fel az eseménytárba. Ha a megőrzött események formátumát (tehát nem magukat az adatokat) kell módosítani, például egy migrálás során, nehézkes lehet a tárolóban lévő meglévő eseményeket kombinálni az új verzióval. Esetleg szükséges lehet a módosításokat végrehajtó összes eseményt végigléptetni, hogy kompatibilisek legyenek az új formátummal, vagy az új formátumot használó új eseményeket hozzáadni. Érdemes lehet az eseményséma minden verzióját verzióbélyeggel ellátni a régi és az új eseményformátumok megtartásához.

Az eseménytárban több szálon vagy példányban futó alkalmazások is tárolhatnak eseményeket. Az eseménytárban tárolt események konzisztenciája létfontosságú, csakúgy, mint az egyes entitásokra ható események sorrendje (az entitásokat érintő változások sorrendje befolyásolja azok aktuális állapotát). Segíthet elkerülni a problémákat, ha az egyes eseményeket időbélyeggel látja el. Egy másik gyakori eljárás, ha a kérésekből eredő minden eseményt egy növekményes azonosítóval jelöl. Ha két művelet egyidőben próbál eseményeket hozzáadni ugyanahhoz az entitáshoz, az eseménytár elutasíthatja az olyan eseményeket, amelyek entitásazonosítója és eseményazonosítója megegyezik egy meglévőével.

Nincs szabványos megközelítés vagy létező mechanizmus (mint például az SQL-lekérdezések) az események olvasására az adatok beszerzéséhez. Adatként kizárólag eseménystreamek olvashatóak ki feltételként egy eseményazonosítót megadva. Az eseményazonosító tipikusan egyedi entitásokra képezhető le. Egy entitás aktuális állapota csak úgy határozható meg, ha visszajátssza az összes hozzá kapcsolódó eseményt az entitás eredeti állapotából kiindulva.

Az egyes eseménystreamek hossza kihat a rendszer kezelésére és frissítésére. Nagyobb streamek esetén érdemes lehet adott időközönként, például adott számú eseményenként pillanatképeket létrehozni. Az entitás aktuális állapota a pillanatképből kiindulva és az annak időpontját követően bekövetkezett eseményeket visszajátszva kérhető le. Az adatok pillanatképeinek létrehozásáról további információt az elsődleges-alárendelt pillanatkép-replikáció című témakörben talál.

Bár az Események forráskezelése minimalizálja az adatok ütköző frissítésének esélyét, az alkalmazásnak így is képesnek kell lennie kezelni a végleges konzisztenciából és a tranzakciók hiányából eredő inkonzisztenciát. Előfordulhat például, hogy egy olyan esemény, amely a készletkészlet csökkenését jelzi, az adattárba érkezhet, miközben az adott tételre vonatkozó megrendelést helyeznek el. Ez a helyzet azt eredményezi, hogy a két művelet összeegyeztetése az ügyfél tanácsával vagy egy visszarendelés létrehozásával szükséges.

Előfordulhat, hogy az esemény közzététele legalább egyszer megtörténik, ezért az események felhasználóinak idempotensnek kell lenniük. Az eseményekben leírt frissítéseket nem szabad ismételten alkalmazniuk, ha az esemény többször is kezelve lett. Egy fogyasztó több példánya is fenntarthatja és összesítheti egy entitás tulajdonságát, például a leadott rendelések teljes számát. Csak egynek kell növelnie az aggregátumot, amikor egy megrendeléssel rendelkező esemény történik. Bár ez az eredmény nem az eseményforrás egyik fő jellemzője, ez a szokásos megvalósítási döntés.

A kiválasztott eseménytárolónak támogatnia kell az alkalmazás által létrehozott eseményterhelést.
Vegye figyelembe azokat a forgatókönyveket, amelyekben egy esemény feldolgozása egy vagy több új esemény létrehozását foglalja magában, mivel ez végtelen ciklust okozhat.

Mikor érdemes ezt a mintát használni?

Az alábbi esetekben alkalmazza ezt a mintát:

• Ha rögzíteni szeretné a szándékokat, a célokat vagy az okokat az adatokban. Az ügyfélentitás módosításai például rögzíthetők meghatározott eseménytípusok sorozataként, például áthelyezve, bezárt fiókként vagy elhunytként.

• Ha elengedhetetlen az ütköző adatfrissítések előfordulásának minimalizálása vagy teljes megszüntetése.

• Ha rögzíteni szeretné az eseményeket, vissza szeretné őket játszani, hogy visszaállítsa a rendszer állapotát, visszaállítsa a módosításokat, vagy megőrizze az előzményeket és a naplókat. Ha például egy feladat több lépést is tartalmaz, előfordulhat, hogy végre kell hajtania a frissítések visszaállításához szükséges műveleteket, majd vissza kell játszania néhány lépést az adatok konzisztens állapotba hozásához.

• Amikor eseményeket használ. Ez az alkalmazás működésének természetes jellemzője, és kevés extra fejlesztési vagy megvalósítási erőfeszítést igényel.

• Ha el kell választania a bemeneti vagy frissítési folyamatot a műveletek végrehajtásához szükséges feladatoktól. Ez a változás lehet a felhasználói felület teljesítményének javítása vagy az események más figyelőknek való terjesztése, amelyek az események bekövetkezésekor műveletet hajtanak végre. Például integrálhatja a bérszámfejtési rendszert egy költségbeküldési webhelytel. Az eseménytár által a webhelyen végrehajtott adatfrissítések alapján létrehozott eseményeket a webhely és a bérszámfejtő rendszer is felhasználná.

• Ha rugalmasan szeretné módosítani a materializált modellek és entitásadatok formátumát, ha a követelmények változnak, vagy – a CQRS használatakor – át kell alakítania egy olvasási modellt vagy az adatokat elérhetővé tevő nézeteket.

• A CQRS használata esetén a végleges konzisztencia elfogadható az olvasási modell frissítésekor, vagy elfogadható az entitások és adatok eseményfolyamból való rehidratálásának teljesítményre gyakorolt hatása.

Nem érdemes ezt a mintát használni a következő helyzetekben:

• Kis vagy egyszerű tartományok, rendszerek, kis vagy semmilyen üzleti logikával nem rendelkező rendszerek, valamint a hagyományos CRUD adatkezelési mechanizmusokkal eleve jól együttműködő nem tartományi rendszerek esetén.

• Olyan rendszerek esetén, ahol a konzisztencia és az adatnézetek valós idejű frissítése szükséges.

• Olyan rendszerek, amelyekben nincs szükség naplózási nyomvonalakra, előzményekre és a műveletek visszaállítására és visszajátszására szolgáló képességekre.

• Olyan rendszerek, ahol a mögöttes adatok ütköző frissítései csak alacsonyan fordulnak elő. Például olyan rendszerek esetén, amelyek túlnyomórészt hozzáadnak, nem pedig frissítenek adatokat.

Számítási feladatok tervezése

Az építészeknek értékelniük kell, hogyan használható az esemény-beszerzési minta a számítási feladat tervezése során az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

A konferenciafelügyeleti rendszernek nyomon kell követnie a konferencia befejezett foglalásainak számát. Így ellenőrizheti, hogy vannak-e még szabad helyek, amikor egy potenciális résztvevő megpróbál foglalást végezni. A rendszer az egyes konferenciákra érkezett foglalások számát legalább kétféleképpen tárolhatja:

• A rendszer az egyes konferenciákra érkezett foglalások számára vonatkozó adatokat tárolhatja külön entitásként a foglalási adatokat tartalmazó adatbázisban. A foglalások vagy a lemondások alkalmával a rendszer megfelelően növelheti vagy csökkentheti ezt a számot. Ez a megközelítés elméletben egyszerű, azonban skálázhatósági problémákat okozhat, ha rövid időn belül nagy számú résztvevő próbál foglalni. Például egy foglalási időszak utolsó vagy utolsó néhány napján.

• A rendszer a foglalásokkal és lemondásokkal kapcsolatos adatokat tárolhatja eseményekként egy eseménytárban. Ezután a szabad helyek számát ezeknek az eseményeknek a visszajátszásával számíthatja ki. Ez a megközelítés az események változtathatatlansága miatt jobban skálázható lehet. A rendszernek csak az eseménytárból kell tudnia adatokat olvasni, vagy adatokat hozzáfűzni ugyanitt. A foglalások és a lemondások eseményadatai soha nem módosulnak.

A következő ábra azt mutatja be, hogy a konferenciakezelő rendszer helyfoglaló alrendszere hogyan implementálható az Események forráskezelése használatával.

Két hely foglalása esetén a műveletek sorrendje a következő:

1. A felhasználói felület kiad egy parancsot két hely foglalására két résztvevő számára. A parancsot egy külön parancskezelő dolgozza fel. Egy, a felhasználói felületről leválasztott és a parancsként közzétett kérések kezeléséért felelős logikai rész.

2. A konferencia összes foglalásával kapcsolatos adatokat tartalmazó összesítés a foglalásokat és a lemondásokat leíró események lekérdezésével állatható össze. Az összesítés neve SeatAvailability, és egy olyan tartományi modell tartalmazza, amely az összesítésben foglalt adatok lekérdezésére és módosítására szolgáló metódusokat tárja fel.

   Néhány megfontolandó optimalizálás pillanatképeket használ (így nem kell lekérdeznie és visszajátszania az események teljes listáját az összesítés aktuális állapotának lekéréséhez), és fenntartani az összesítés gyorsítótárazott másolatát a memóriában.

3. A parancskezelő egy, a tartományi modellben feltárt metódust hív meg a foglalások intézésére.

4. A SeatAvailability összesítés rögzíti a lefoglalt helyek számát tartalmazó eseményt. A következő alkalommal, amikor az összesítés valamilyen eseményt alkalmaz, a szabad helyek számát a rendszer az összes foglalás használatával számítja ki.

5. A rendszer hozzáfűzi az új eseményt az események sorához az eseménytárban.

Ha egy felhasználó lemond egy helyet, a rendszer ugyanezt a folyamatot követi, azzal a különbséggel, hogy a parancskezelő egy helylemondási eseményt létrehozó parancsot ad ki és fűz hozzá az eseménytárhoz.

Amellett, hogy nagyobb hatókört biztosít a méretezhetőséghez, az eseménytár használata a konferencia foglalásainak és lemondásainak teljes előzményeit vagy auditnaplóját is tartalmazza. Az eseménytárban szereplő események szolgálnak pontos rekordként. Nincs szükség az összesítések más módon történő megőrzésére, mert a rendszer egyszerűen vissza tudja játszani az eseményeket, és bármikor visszaállíthatja az állapotot.

Ezzel a példával kapcsolatban további információkat az Események forráskezelése bemutatásában talál.

Következő lépések

• Objektum-relációs impedancia eltérése

• Adatkonzisztencia – Ismertető. Ha külön olvasási tárral vagy materializált nézetekkel használja az esemény-beszerzést, az olvasási adatok nem lesznek azonnal konzisztensek. Ehelyett az adatok csak végül konzisztensek lesznek. Ez a cikk az elosztott adatok konzisztenciájának fenntartásával kapcsolatos problémákat foglalja össze.

• Adatparticionálási útmutató. Az adatok gyakran particionálva lesznek, amikor eseményforrást használ a méretezhetőség javítása, a versengés csökkentése és a teljesítmény optimalizálása érdekében. Ez a cikk azt ismerteti, hogyan oszthat fel adatokat különálló partíciókra, és milyen problémák merülhetnek fel.

• Martin Fowler blogja:

  • Event Sourcing
  • Pillanatkép Martin Fowler Vállalati alkalmazásarchitektúra webhelyéről

Kapcsolódó erőforrások

Az alábbi minták és útmutatók szintén hasznosak lehetnek a minta megvalósításakor:

• Command and Query Responsibility Segregation (CQRS) minta. A CQRS implementálások állandó adatforrását biztosító írási tároló alapjául gyakran az Események forráskezelése minta egy implementálása szolgál. A szakasz azt ismerteti, hogyan lehet különböző felületek használatával elkülöníteni az alkalmazások adatolvasó műveleteit az adatfrissítő műveletektől.

• Tényleges táblán alapuló nézet minta. Az esemény-forráskezelésen alapuló rendszerben használt adattár általában nem alkalmas a hatékony lekérdezésre. Ehelyett az általános megközelítés szerint rendszeres időközönként vagy az adatok változásakor szokás előfeltöltött nézeteket létrehozni az adatokról.

• Kompenzáló tranzakció mintája. Az esemény-forrástárban lévő meglévő adatok nem frissülnek. Ehelyett új bejegyzéseket adnak hozzá, amelyek az entitások állapotát az új értékekre váltják át. A módosítás megfordításához kompenzáló bejegyzéseket használ a rendszer, mert az előző módosítás nem fordítható vissza. A szakasz azt ismerteti, hogyan lehet visszavonni a korábbi műveletek által végrehajtott módosításokat.