Event Sourcing mintázat

Ahelyett, hogy csak az adatok aktuális állapotát tárolja egy relációs adatbázisban, tárolja az objektumokon végrehajtott műveletek teljes sorozatát egy csak hozzáfűző tárolóban. A bolt úgy működik, mint egy rekordrendszer, amellyel materializálhatja a tartományobjektumokat. Ez a megközelítés javíthatja az auditálási és írási teljesítményt összetett rendszerekben.

Fontos

Az esemény alapú adatkezelés egy összetett minta, amely jelentős kompromisszumokat hoz magával. Megváltoztatja az adatok tárolásának módját, kezeli az egyidejűséget, fejleszti a sémákat és a lekérdezés állapotát. Költséges az eseményforrás-megoldásba vagy onnan való migrálás, és a minta bevezetése után korlátozza a jövőbeli tervezési döntéseket a rendszer azon részeiben, amelyek ezt használják. Az eseményforrás bevezetését fontolja meg, amikor annak előnyei, mint például az auditálhatóság és a történelmi rekonstrukció, igazolják a minta összetettségét. A legtöbb rendszerhez és a rendszer legtöbb részéhez elegendő a hagyományos adatkezelés.

Kontextus és probléma

A legtöbb alkalmazás az adatokkal dolgozik. Az alkalmazás általában egy relációs adatbázisban tárolja az adatok legújabb állapotát, és szükség szerint beszúrja vagy frissíti az adatokat. A hagyományos létrehozási, olvasási, frissítési és törlési (CRUD) modellben például egy alkalmazás beolvassa az adatokat az áruházból, módosítja és frissíti az adatok aktuális állapotát az új értékekkel, általában az adatokat zároló tranzakciók használatával.

A CRUD megközelítés a legtöbb forgatókönyv esetében egyszerű és gyors. A nagy terhelésű rendszerekben azonban ez a megközelítés kihívást jelent:

• Írási versengés: Mivel a frissítések olvasási-módosítási-írási ciklusokat igényelnek sorszintű zárolással, az egyidejű írások ugyanahhoz az entitáshoz csökkentik a teljesítményt, és szűk keresztmetszetté válnak a terhelés alatt.

• Naplózás: A CRUD-rendszerek csak az adatok legújabb állapotát tárolják. Ha nem implementál olyan naplózási mechanizmust, amely külön naplóban rögzíti az egyes műveletek részleteit, elveszíti az adatelőzményeket.

Megoldás

Az Event Sourcing minta meghatározza az események sorozata által vezetett adatokon végzett műveletek kezelésére vonatkozó megközelítést. A rendszer minden eseményt csak hozzáfűzéses adattárolóban rögzít. Az alkalmazáskód olyan eseményeket vet fel, amelyek az objektumon végrehajtott minden műveletet leírják. Általában egy üzenetsorba küld eseményeket, amelyekben egy külön folyamat, egy eseménykezelő figyeli az üzenetsort, és megőrzi az eseményeket egy eseménytárolóban. Minden esemény az objektum logikai változását jelöli, például AddedItemToOrder vagy OrderCanceled.

Az események egy olyan eseménytárban maradnak, amely az adatok aktuális állapotára vonatkozó rekordrendszerként vagy mérvadó adatforrásként szolgál. Az extra eseménykezelők figyelhetik az adott eseményeket, és szükség szerint műveleteket hajthatnak végre. Előfordulhat például, hogy a felhasználók olyan feladatokat kezdeményeznek, amelyek más rendszerekre alkalmazzák az események műveleteit, vagy más kapcsolódó műveleteket hajtanak végre a művelet befejezéséhez. Az eseményeket létrehozó alkalmazáskód leválasztva van az eseményekre feliratkozó rendszerektől.

Az eseményforrású rendszerek minden entitása saját eseménystreamel rendelkezik, amely az adott entitás minden változását rekordként tartalmazó rendezett eseménysorozat. Az alkalmazások bármikor elolvashatják az események előzményeit. Az alkalmazások az entitás aktuális állapotát az összes esemény ismétlésével nyerik le a streamben. Ezt a folyamatot rehidratálásnak nevezzük. Igény szerint előfordulhat, amikor az alkalmazás egy kérést kezel.

Az alkalmazások általában materializált nézeteket implementálnak, mert az események olvasása és visszajátszása költséges. A materializált nézetek az eseménytároló írásvédett vetületei, amelyek lekérdezésre vannak optimalizálva. Egy rendszer például fenntarthatja az összes ügyfélrendelés materializált nézetét, amelyet a felhasználói felület feltöltéséhez használ. Amikor az alkalmazás új rendeléseket ad hozzá, elemeket ad hozzá vagy távolít el a rendelésben, vagy szállítási adatokat ad hozzá, az alkalmazás eseményeket hoz létre, és egy kezelő frissíti a materializált nézetet.

Az alábbi ábrán ennek a mintának a áttekintése látható a Command Query Responsibility Szegregáció (CQRS) mintával kombinálva. A bemutató réteg egy külön írásvédett tárolóból olvas be, és parancsokat ír a parancskezelőknek. A parancskezelők lekérik az entitás eseménystreamjét az eseménytárolóból, üzleti logikát futtatnak, és új eseményeket küldenek egy üzenetsorba. Az eseménykezelők az üzenetsorból származó eseményeket használnak fel, és eseményeket írnak az eseménytárba, frissítik az írásvédett tárolót, vagy integrálják a külső rendszerekkel.

A diagram tetején egy mező jelöli a bemutató réteget. A jobb felső sarokban egy nyíl beolvassa a pontokat a bemutató rétegből egy üzleti objektum címkével ellátott dobozba, amely egy írásvédett tárolóra mutat. A nyíl címkével ellátott pontokat ír a bemutató rétegből a bal oldali dobozba, amely parancskezelőket és üzleti objektumokat tartalmaz. Ebből a mezőből egy 'get cart events' feliratú nyíl mutat egy eseménytárolóra. Egy másik nyíl a parancskezelők mezőről egy alul elhelyezkedő dobozra mutat, amely üzenetsorként vagy témakörként van címkézve, és hét borítékikont tartalmaz. A nyíl mellett a boríték ikonjai olyan eseményeket jelölnek, mint a kosár létrehozása, az 1. elem hozzáadva, a 2. elem hozzáadva, az 1. elem eltávolítása és a szállítási adatok hozzáadása. Három nyíl mutat az üzenetsor vagy a témakör dobozából különálló eseménykezelőkre. A bal szélső eseménykezelő eseményeket ír az eseménytárba. A középső eseménykezelő frissíti az írásvédett tárolót. A jobb szélső eseménykezelő integrálható a külső rendszerekkel.

Töltse le ennek az architektúrának a Visio fájlját.

Workflow

A következő munkafolyamat az előző diagramnak felel meg:

1. A bemutató réteg egy írásvédett tárból beolvasott objektumot hív meg. A visszaadott adatokat használja a felhasználói felület feltöltéséhez.

2. A bemutató réteg meghívja a parancskezelőket olyan műveletek végrehajtására, mint például egy kosár létrehozása vagy egy elem hozzáadása a kosárhoz.

3. A parancskezelő betölti az entitást az eseményfolyam beolvasásával az eseménytárolóból. Előfordulhat például, hogy az összes kosáreseményt lekérheti. Ezeket az eseményeket visszajátssza az entitással, hogy új művelet előtt rekonstruálja az aktuális állapotát.

4. Az üzleti logika fut, és eseményeket aktiválnak. A legtöbb implementációban az események egy üzenetsorba vagy témakörbe kerülnek az eseménykészítők és az eseményfelhasználók leválasztása érdekében.

5. Az eseménykezelők figyelik az adott eseményeket, és megteszik a megfelelő műveletet az adott kezelőhöz. Ebben a példában az eseménykezelők a következő műveleteket hajtják végre:

   1. Események írása az eseménytárba

   2. Lekérdezésekhez optimalizált írásvédett tároló frissítése

   3. Integráció külső rendszerekkel

Mintaelőnyök

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

• Az események nem módosíthatók, és csak hozzáfűző művelettel tárolhatók. Az eseményt kezdeményező felhasználói felület, munkafolyamat vagy folyamat folytatódhat, az eseményeket kezelő feladatok pedig a háttérben futhatnak. Az írási átviteli sebesség javul, különösen a megjelenítési réteg esetében, mivel a csak hozzáfűző írások elkerülik a helyben történő frissítések által létrehozott sorszintű zárolási versengést.

• Az események egyszerű objektumok, amelyek az esemény által képviselt művelet leírásához szükséges összes kapcsolódó adattal együtt leírják a műveletet. Az események közvetlenül nem frissítik az adattárakat. Az eseménykezelők akkor rögzítik és dolgozzák fel a rögzített eseményeket, ha egy kezelő elérhető, és a rendszer képes kezelni a terhelést. Események használatával 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 jelölik, nem pedig a bekövetkező eseményeket.

• 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. A parancskezelők újrahidratálnak egy entitást az eseménystreamből, hogy üzleti szabályokat kényszeríthessenek ki, mielőtt új eseményeket fűznének hozzá, így az azonos entitást egyszerre betöltő két kezelő ugyanazon az állapoton működhet.

  Például minden kezelő öt fennmaradó helyet lát, és mindkét kezelő elfogadhat foglalást. Az eseménytárolók optimista egyidejűség-vezérléssel kezelik ezt a forgatókönyvet, és elutasítanak egy hozzáfűzést, ha a stream az olvasás óta módosult. Elutasítás esetén a kezelő újra betölti az entitást, újraértékeli és újrapróbálkozza.

• A csak hozzáfűző eseménytároló olyan naplózási útvonalat biztosít, amellyel az alkalmazások figyelhetik az adattárakon végrehajtott műveleteket. Az események bármikor újrarendelésével újragenerálhatja az aktuális állapotot materializált nézetként vagy kivetítésként, és segíthet a rendszer tesztelésében és hibakeresésében.

  Az a követelmény, hogy kompenzáló eseményeket használjon a módosítások megszakításához, a fordított módosítások előzményeit is megadhatja. Ha a modell csak az aktuális állapotot tárolja, ez az előzmény nem létezik. Az események listájával elemezheti az alkalmazás teljesítményét, észlelheti a felhasználói viselkedési trendeket, és egyéb hasznos üzleti információkat szerezhet be.

• A parancskezelők eseményeket emelnek ki, és a feladatok az adott eseményekre reagálva 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ény típusát és az esemény adatait, de az eseményt kiváltó műveletről nem.

  Több feladat is képes kezelni az egyes eseményeket, így könnyen integrálhatók más szolgáltatásokkal és rendszerekkel, amelyek csak az eseménytároló által kiváltott új eseményeket figyelik. Az event sourcing események általában alacsony szintűek, ezért előfordulhat, hogy inkább konkrét integrációs eseményeket kell létrehozni.

Jótanács

Az esemény-forráskezelést gyakran kombinálják a CQRS-mintával az eseményekre válaszul végzett adatkezelési feladatok végrehajtásával, valamint a tárolt események nézeteinek materializálásával. Ezzel a kombinációval egymástól függetlenül méretezheti az olvasásokat és írásokat, mivel a csak hozzáfűző események betöltése és a lekérdezésoptimalizált előrejelzések külön működnek.

Problémák és szempontok

Vegye figyelembe a következő szempontokat, amikor úgy dönt, hogy hogyan valósítja meg ezt a mintát:

• Eseményterv: Események tervezése az egyes változások mögötti üzleti szándék rögzítéséhez az eredményként kapott állapoton kívül. A helyfoglalási rendszerben például egy olyan esemény, amely két helyet foglalt le , értékesebb, mint egy olyan esemény, amely a fennmaradó helyeket 42-re módosította. Az első esemény megmutatja, mi történt. A második esemény csak az eredményként kapott állapotot jelzi. Az állapotalapú események olyan változásnaplóra csökkentik az eseménytárat, amelynek nincs üzleti jelentése. A szándékalapú események részletesebb előrejelzéseket, jelentéssel bíró naplózási nyomokat és rugalmasságot biztosítanak a korábbi eseményekből származó új olvasási modellek létrehozásához anélkül, hogy módosítaniuk kellene az írási környezetet.

• Végleges konzisztencia: A rendszer csak akkor konzisztens, ha materializált nézeteket hoz létre, vagy események ismétlésével generálja az adatok előrejelzését. A késés akkor jelentkezik, ha egy alkalmazás kezeli a kéréseket, és eseményeket ad hozzá az eseménytárhoz, amikor az események megjelennek, és amikor a felhasználók kezelik az eseményeket. Ebben az időszakban az entitások további változásait leíró új események érkezhetnek az eseménytárba. Győződjön meg arról, hogy az ügyfelek tisztában vannak azzal, hogy az adatok végül konzisztensek, és hogy a rendszer úgy van kialakítva, hogy figyelembe vegyék a végleges konzisztenciát ezekben a forgatókönyvekben.

• Verziószámozási események: Az eseménytár az információk állandó forrása, ezért soha ne frissítse az eseményadatokat. Az entitások frissítésének vagy a módosítások visszavonásának egyetlen módja, ha egy kompenzáló eseményt ad hozzá az eseménytárhoz. A kompenzáló esemény egy új esemény, amely megfordítja vagy korrigálja egy korábbi esemény hatását. Egy esemény például ReservationCanceled egy korábbi SeatsReserved eseményt kompenzál. Az eredeti esemény a streamben marad, és a kompenzáló esemény rögzíti, hogy az visszavonásra került.

  Ez a nem módosíthatóság azt is jelenti, hogy ha egy hiba helytelen eseményeket okoz, ezek az események megmaradnak az áruházban. Az alkalmazáskódban található hiba kijavítása nem javítja ki az előzményeseményeket, ezért előfordulhat, hogy kompenzáló eseményekre vagy upcasterekre is szükség lehet a rossz adatok visszajátszás közbeni kezeléséhez. Ha a megőrzött események sémáját (az adatok helyett) módosítani kell, talán az áttelepítés során, nehéz lehet a meglévő eseményeket kombinálni az áruházban az új verzióval.

  A következő stratégiákat használhatja egyenként vagy kombinálva:

  • Toleráns deszerializálás: Az eseményfelhasználókat úgy tervezzük, hogy figyelmen kívül hagyják az ismeretlen mezőket, és az alapértelmezett értékeket használják a hiányzó mezőkhöz. Ez a megközelítés kezeli az additív, nem törhető módosításokat, például egy választható mező hozzáadását anélkül, hogy a tárolt események átalakítását kellene megkövetelnie.

  • Esemény verziószámozása: Adjon meg verzióazonosítót minden eseményhez metaadatokként az esemény borítékjában vagy az eseménytípus neve részeként. A felhasználók a verzióval választják ki a megfelelő kezelési logikát.

  • Felcímkésítés: A deszerializálás során a régebbi eseménysémákat az aktuális sémává konvertáló átalakítási függvények regisztrálása. Az upcasterek láncolhatók úgy, hogy az alkalmazás kódjának csak a legújabb verziót kelljen kezelnie. A tárolt események változatlanok maradnak, ami megőrzi a nem módosíthatóságot.

  • Helyszíni migrálás: Írja át az előzményeseményeket az új sémába közvetlenül az eseménytárban. Ez a megközelítés megszakítja a nem módosíthatóságot, és végső megoldásnak kell lennie, mert aláássa az auditnaplót.

• Eseményrendezés: A többszálú alkalmazások és az alkalmazások több példánya is tárolhat eseményeket az eseménytárban. Az eseménytár eseményeinek konzisztenciája és az adott entitás aktuális állapotát befolyásoló események sorrendje kulcsfontosságú. Ha minden eseményhez időbélyeget ad, azzal elkerülheti a problémákat. Egy másik gyakori eljárás az, hogy egy növekményes azonosítóval rendelkező kérésből származó minden eseményt megjegyzésekkel 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.

• Esemény lekérdezése: Nincsenek standard megközelítések vagy meglévő mechanizmusok, például SQL-lekérdezések az események olvasásához az információk lekéréséhez. Az egyetlen kinyerhető adat egy eseményfolyam, amely feltételként egy eseményazonosítót használ. Az eseményazonosító általában egyedi entitásokhoz társítható. Az entitás aktuális állapotát csak úgy határozhatja meg, ha az összes vele kapcsolatos eseményt az adott entitás eredeti állapotával összeveti.

• Eseménytár beállításai: Az eseménytárolók lehetnek csak hozzáfűző eseménystreamekhez tervezett célalapú adatbázisok, vagy egy általános célú, csak hozzáfűző táblával rendelkező relációs vagy dokumentumadatbázis.

  • A célalapú eseménytárolók beépített támogatást nyújtanak olyan feladatokhoz, mint a streamek entitások szerinti olvasása, optimista egyidejűség és pillanatképek.

  • A relációs adatbázisok ismerősek és széles körben elérhetők, de ezeket a viselkedéseket saját maga kell létrehoznia.

  Mivel minden entitás saját független eseményfolyammal rendelkezik, az eseményadatok természetesen entitásazonosító alapján partíciózódnak, ami szükség esetén leegyszerűsíti a horizontális skálázást vagy shardingot.

  Fontos

  Ne keverje össze az eseménytárat egy eseménystream üzenetközvetítővel. Az üzenetközvetítők, például az Apache Kafka általában nem rendelkeznek entitásonkénti streamlekérdezésekkel és optimista egyidejűséggel. Ugyanúgy működnek, mint egy terjesztési réteg, amely az eseményeket kivetítésekre és külső felhasználókra is ki tudja terjeszteni, de nem helyettesítik az eseménytárolókat.

• Entitásállapot újbóli létrehozása: Az egyes eseménystreamek hossza befolyásolja a rendszer kezelését és frissítését. Ha a streamek nagyok, az entitás rehidratálására szolgáló összes esemény ismétlése költségessé válik mind az idő, mind a számítás során. A költség csökkentése érdekében pillanatképeket hozhat létre meghatározott időközönként, például minden N eseményen. A pillanatkép az entitás állapotának szerializált ábrázolása az eseménystream egy adott pontján. Az entitás rehidratálásához töltse be a legfrissebb pillanatképet, és csak az azt követő eseményeket játssza vissza, ahelyett, hogy a teljes adatfolyamot az elejétől kezdve megismételte volna. Pillanatképek gyakoriságának kiválasztásakor egyensúlyba kell állítani a pillanatképek tárolási költségeit a rehidratálás során megtakarított idővel.

  Megjegyzés:

  A pillanatképek optimalizálást jelentenek, nem pedig az eseményfolyam helyettesítését. Az eventstream marad az igazság forrása, és bármikor újra létrehozhat pillanatképeket belőle.

• Ütközéskezelés: Az optimista egyidejűség-vezérlés megakadályozza az ütköző írásokat ugyanahhoz az eseménystreamhez, de az alkalmazásnak továbbra is kezelnie kell a több entitásra kiterjedő ütközéseket. Előfordulhat például, hogy egy esemény, amely a készletkészlet csökkenését jelzi, az adattárba érkezhet, miközben egy ügyfél megrendelést küld az adott cikkhez. Tervezze meg a rendszert, hogy összeegyeztetje ezeket a helyzeteket, például tanácsot ad az ügyfélnek, vagy hozzon létre egy visszarendelést.

• Idempotencia-követelmények: Az eseményszolgáltatás általában legalább egyszer történik, így a fogyasztók többször is megkaphatják ugyanazt az eseményt. Az eseménykezelőknek idempotensnek kell lenniük, így az ismétlődő események feldolgozása nem változtatja meg az eredményt. Ha például több példányban fut egy fogyasztói folyamat, amely az ülőhelyfoglalási eseményeket kezeli a rendelkezésre álló ülőhelyek számának nyomon követésére, akkor a duplikált foglalási eseménynek csak egy csökkentést kell eredményeznie. Idempotencia nélkül az előrejelzések eltérnek az eseményfolyamtól, és a mellékhatások, például a kifizetések vagy értesítések többször aktiválódnak. Nyomon követheti az egyes felhasználók utolsó feldolgozott eseményütemezési számát, és kihagyhatja az ismétlődéseket, illetve az eredendően biztonságosan megismételhető tervezési állapotmutációkat.

• Körkörös logika: Vegye figyelembe azokat a forgatókönyveket, amelyekben egy esemény feldolgozása egy vagy több új esemény létrehozását igényli. Ez a sorozat végtelen ciklust eredményezhet.

• Vizsgálat: Egy adott tesztelési stílus felel meg legjobban az eseményforrású rendszereknek. Korábbi események beállítása, parancs kiadása és az újonnan létrehozott események ellenőrzése. Ez a given-when-then megközelítés adatbázisok, üzenetsorok vagy előrejelzések nélkül teszteli az üzleti logikát. Emellett integrációs tesztekre is szüksége van a kivetítések, az idempotencia viselkedése és a sémafejlődési útvonalak esetében, amelyek a CRUD-rendszerekhez képest tesztfelületet adnak hozzá.

• Személyes adatok és jogszabályi megfelelőség: Az eseménytárolók csak hozzáfűző, nem módosítható jellege ütközik a személyes adatok törlését igénylő adatvédelmi előírásokkal, például az elfeledtetéshez való joggal . Az események törlése egyenesen megszakítja a stream integritását, ezért ezt a feszültséget kezdettől fogva tervezni kell.

  • Gyakori módszer a személyes adatok tárolása az eseménytárolón kívül, és azonosító alapján történő hivatkozás az eseményekben. Ez a módszer lehetővé teszi a törlést önállóan, az eseményáram befolyásolása nélkül.

  • Ha nem tudja elkülöníteni a személyes adatokat az eseményektől, használjon kriptográfiai kulcs megsemmisítést. Személyes adatok titkosítása az eseményekben tárgyonkénti kulccsal. Törölje a kulcsot az adatok helyreállíthatatlanná tétele érdekében, miközben érintetlenül hagyja az eseménystruktúrát. Ez a megközelítés titkosítási többletterhelést ad minden olvasási és írási művelethez, és robusztus kulcskezelést igényel.

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

Használja ezt a mintát a következő esetekben:

• Szándékot, célt vagy okot szeretne rögzíteni az adatokban. Rögzítheti például az ügyfélentitás módosításait meghatározott eseménytípusok sorozataként, például áthelyezett otthon, bezárt fiók vagy Elhunyt.

• Minimalizálnia vagy teljesen el kell kerülnie az adatok ütköző frissítéseit.

• Rögzíteni szeretné az eseményeket, vissza szeretné őket játszani a rendszer állapotának visszaállításához, a módosítások visszaállításához, vagy egy előzmény- és naplónapló megőrzéséhez. Ha például egy feladat több lépésből áll, előfordulhat, hogy a frissítések visszaállításához, majd néhány lépés visszajátszásához újra kell futtatnia az adatokat egy konzisztens állapotba.

• Az alkalmazás már használja az eseményeket a működésének természetes funkciójaként, és az esemény-beszerzéshez kevés extra fejlesztésre vagy megvalósításra van szükség.

• El kell választania az adatok beviteli vagy frissítési folyamatát 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 bekövetkezésekor fellépő más figyelőknek való elosztása. Például integrálhatja a bérszámfejtési rendszert egy költségbeküldési webhelytel. Mind a webhely, mind a bérszámfejtési rendszer olyan eseményeket használ fel, amelyeket az eseménytár a webhelyen frissített adatokra reagálva generál.

• Rugalmasan módosíthatja a materializált modellek és entitásadatok formátumát, ha a követelmények változnak, vagy ha CQRS-t használ, és át kell igazítania egy olvasási modellt vagy az adatokat elérhetővé tevő nézeteket.

• CQRS-t használ, és a végleges konzisztencia elfogadható az olvasási modell frissítése közben, vagy amikor az eseményfolyamból származó entitás- és adatrehidratálás elfogadható teljesítménycsökkenést eredményez.

Ez a minta nem feltétlenül megfelelő, ha:

• A rendszerek egyszerű CRUD-műveletekkel rendelkeznek, amelyek nem igényelnek naplózást, visszajátszást vagy az állapot korábbi rekonstrukcióját. Az eseménytárak működési többletterhelése nem indokolt, ha az egyetlen követelmény az aktuális állapot olvasása és írása.

• A prototípusok, minimálisan életképes termékek (MVP-k) vagy rendszerek rövid élettartamot várnak. Az eseménytervezésbe, a sémafejlődési stratégiába és a vetítési infrastruktúrába történő kezdeti befektetés ritkán eredményez megtérülést ezekben a forgatókönyvekben.

• A rendszerek konzisztenciát és valós idejű frissítéseket igényelnek az adatok nézeteihez. A végső konzisztencia az eseménytároló és a kivetítések között az esemény alapú modellezés velejárója.

• Olyan tartományok, amelyekben az adatok többnyire statikusak vagy referenciaként szolgálnak, például keresési táblák vagy katalógusok. Ez az adattípus ritkán változik, és nem előnyös a változáselőzmények szempontjából.

• A csapatok nem rendelkeznek tapasztalattal az eseményvezérelt architektúrák terén. Az esemény-beszerzés megváltoztatja a rendszer tesztelésének, hibakeresésének és működtetésének módját. Az alapszintű ismeretek nélkül történő bevezetése növeli a költségesen megfordítható antipatternek kockázatát.

Jótanács

Az esemény-beszerzésnek nem kell minden vagy semmi döntésnek lennie a teljes rendszer számára. Alkalmazza szelektíven a rendszer azon részeire, amelyek a leginkább előnyösek, például a fizetési főkönyvre vagy a rendelésfeldolgozási folyamatra. Használjon hagyományos CRUD-t olyan részekhez, ahol az összetettség nem indokolt, például felhasználói profilok kezelése vagy alkalmazáskonfiguráció.

Munkaterhelés tervezése

Értékelje ki, hogyan használhatja az Event Sourcing mintát a számítási feladatok tervezésében a Azure Well-Architected keretrendszer pilléreiben szereplő célok és alapelvek kezelésére. Az alábbi táblázat útmutatást nyújt arról, hogy ez a minta hogyan támogatja az egyes pillérek céljait.

Alappillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítják, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Ez a minta elősegítheti az állapotrekonstrukciót, ha állapottárolókat kell helyreállítania, mert az összetett üzleti folyamatok változásainak előzményeit rögzíti. - Adatparticionálás - RE:09 Vészhelyreállítás
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését .	Ez a CQRS-sel, a megfelelő tartománytervezéssel és stratégiai pillanatképkészítéssel kombinált minta javíthatja a számítási feladatok teljesítményét az atomi hozzáfűzési műveletek és az adatbázisok írási és olvasási zárolásának elkerülése miatt. - PE:08 Adatteljesítmény

Ha ez a minta kompromisszumokat vezet be egy pilléren belül, vegye figyelembe őket a többi pillér céljaival szemben.

Example

A konferenciafelügyeleti rendszernek nyomon kell követnie a konferencia befejezett foglalásainak számát. Ennek a számnak a nyomon követésével ellenőrizheti a rendelkezésre álló helyeket, amikor egy potenciális résztvevő foglalást kísérel meg. A rendszer egy konferencia foglalásainak teljes számát legalább két módon képes tárolni:

• A rendszer külön entitásként tárolhatja a foglalások teljes számával kapcsolatos információkat egy olyan adatbázisban, amely foglalási adatokat tartalmaz. Ahogy a résztvevők foglalásokat intéznek vagy lemondanak, a rendszer növeli vagy csökkenti ezt a számot. Ez a megközelítés elméletben egyszerű, de skálázhatósági problémákat okozhat, ha sok résztvevő próbál rövid idő alatt helyet foglalni. Ez a túlfeszültség például általában a foglalási időszak lezárása előtti utolsó napon fordul elő.

• A rendszer az eseménytárban tartott eseményekként tárolhatja a foglalásokkal és lemondásokkal kapcsolatos információkat. Az események ismétlésével kiszámítja a rendelkezésre álló helyek számát. Ez a megközelítés az események nem módosíthatósága miatt skálázhatóbb lehet. A rendszernek csak az eseménytárból kell adatokat olvasnia, vagy adatokat hozzáfűznie az eseménytárolóhoz. A foglalásokkal és lemondásokkal kapcsolatos eseményinformációkat soha nem módosítja.

Az alábbi ábra bemutatja, hogyan használhatja az esemény-beszerzést a konferenciafelügyeleti rendszer helyfoglalási alrendszerének implementálásához.

A diagram tetején egy mező jelöli a bemutató réteget. A nyíl címkével ellátott pontokat ír a bemutató rétegből egy olyan mezőbe, amely parancskezelőket és üzleti objektumokat tartalmaz. Egy felcímkézett nyíl az ülések rendelkezésre állási eseményeire mutat a doboztól egy eseménytárba. A nyíl, amelyre „hely foglalt (az ülések száma)” van írva, a parancskezelők mezőjéből mutat az „üzenetsor” vagy „témakör” címkét viselő mezőre. Egy nyíl az üzenetsorból vagy a témakörmezőből egy eseménykezelőre mutat. Egy másik nyíl az eseménykezelőtől az eseménytárolóig.

Töltse le ennek az architektúrának a Visio fájlját.

Workflow

A következő munkafolyamat az előző diagramnak felel meg:

1. A felhasználói felület kiad egy parancsot, amely két résztvevő számára foglal le helyeket. A parancsot egy külön parancskezelő kezeli. A parancskezelő egy olyan logikai elem, amely leválasztva van a felhasználói felületről, és a parancsként közzétett kérések kezeléséért felelős.

2. A rendszer létrehoz egy entitást, amely információkat tartalmaz a konferencia összes foglalásáról a foglalásokat és lemondásokat leíró események ismétlésével. Ezt az entitást meghívják SeatAvailability, és egy tartománymodellben található, amely az entitás adatainak lekérdezésére és módosítására szolgáló módszereket tesz elérhetővé.

   Jótanács

   Fontolja meg az optimalizálásokat, például a pillanatképeket, hogy ne kelljen újrajátszania az események teljes listáját az entitás aktuális állapotának lekéréséhez. A pillanatképek az entitás gyorsítótárazott másolatát is megőrzik a memóriában.

3. A parancskezelő meghív egy metódust, amelyet a tartománymodell elérhetővé tesz a foglalások létrehozásához.

4. Az SeatAvailability entitás létrehoz egy eseményt, amely tartalmazza a fenntartott helyek számát. Amikor az entitás legközelebb alkalmaz eseményeket, az összes foglalást felhasználja a fennmaradó helyek számának kiszámításához.

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 hasonló folyamatot követ, de a parancskezelő kiad egy parancsot, amely létrehoz egy helylemondási eseményt, és hozzáfűzi azt az eseménytárhoz.

A rendszer egy eseménytár használatával teljes körű előzményt vagy naplónyomatot biztosíthat egy konferencia foglalásainak és lemondásainak. Az eseménytárban szereplő események szolgálnak pontos rekordként. Nem kell más módon őriznie az entitásokat, mert a rendszer egyszerűen vissza tudja játszani az eseményeket, és bármikor visszaállíthatja az állapotot.

Következő lépés

• CQRS-minta: A CQRS-implementáció állandó információforrását biztosító írási tároló általában az Event Sourcing minta implementációján alapul. A minta elkülöníti az alkalmazásokban adatokat olvasó műveleteket az adatok frissítését végző műveletektől külön interfészek használatával.

Közösségi erőforrások

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

• Event Sourcing, Martin Fowler: Az eredeti 2005-ös leírás a minta, amely létrehozta az alapvető szókincset.

• CQRS Documents (PDF) Greg Young-tól: Az eseményforrásról és a CQRS-ről szóló végső forrás a gyakorlótól, aki mindkét mintát formalizálta.

Kapcsolódó erőforrások

A minta megvalósításakor az alábbi minták és útmutatók is relevánsak lehetnek:

• Materialized View minta: Az esemény-forrásrendszerben használt adattár általában nem alkalmas a hatékony lekérdezésre. Ehelyett egy gyakori megközelítés az, hogy az adatok előre kitöltött nézeteit hozzuk létre rendszeres időközönként, vagy amikor az adatok változnak.

• Kompenzáló tranzakciós minta: A rendszer nem frissíti a meglévő adatokat egy esemény-forrástárban. Ehelyett új bejegyzéseket ad hozzá, amelyek megváltoztatják az entitások állapotát az új értékekre. A módosítás megfordításához kompenzáló bejegyzéseket használ, mert nem tudja megfordítani az előző módosítást. A kompenzáló tranzakció mintája című cikk bemutatja, hogyan vonható vissza az előző művelet által elvégzett munka.

• Mikroszolgáltatások tartományelemzése: A tartományalapú tervezést (DDD) használó rendszerekben az eseménystreamet birtoklő entitás általában összesítés, konzisztenciahatár, amely parancsokat fogad, üzleti szabályokat kényszerít ki és eseményeket bocsát ki.