Eseményvezérelt architektúra: négy különböző jelentés
Célok
A lecke végére meg tudod különböztetni az „eseményvezérelt” kifejezés négy jelentését, és fel tudod ismerni, melyikről van szó egy konkrét tervben.
Miért kell szétválasztani?
Ha két ember azt mondja, „eseményvezérelt rendszert építenek”, könnyen két különböző dologról beszél. Az egyik arra gondol, hogy a szolgáltatások értesítik egymást, a másik arra, hogy minden állapotváltozást eseménysorként tárolnak. A két megoldás költsége és kockázata nagyon eltér. Martin Fowler ezért négy külön mintát nevez meg.
Mi az esemény?
Az esemény megtörtént tény: „valami megtörtént”. Más, mint a parancs, amely szándékot fejez ki, és amelyet a címzett elutasíthat (részletesen a 6.2 leckében). A termelő nem vár a fogyasztóra, és nem is tud róla; az Azure Architecture Center is úgy írja le, hogy a termelők és a fogyasztók közvetlen függés nélkül, csatornán vagy közvetítőn át kommunikálnak.
A négy jelentés
Minta
Mit jelent?
Fő előny
Fő kockázat
Event notification (esemény-értesítés)
A rendszer értesíti a többit a saját területén történt változásról
Kis csatolás, egyszerű bevezetni
A teljes folyamat nem látszik a kódban; az esemény álcázott paranccsá válhat
Event-carried state transfer
Az esemény magával viszi a megváltozott adatot, a fogadó saját másolatot tart
Kisebb függés a forrástól, kisebb késleltetés
Sok adatmásolat; a fogadónak az állapotot gondoznia kell
Event sourcing
Minden állapotváltozás eseményként tárolódik; az eseménynapló az igazság forrása
Auditálhatóság, visszajátszás
Sémaváltozás; külső hatások visszajátszása
CQRS (Command Query Responsibility Segregation)
Külön adatszerkezet az olvasásra és az írásra
Eltérő olvasási és írási igények kezelése
Többletkomplexitás; félrehasznált minta
Fowler hangsúlyozza, hogy a CQRS szigorúan véve nem az eseményekről szól, és használható azok nélkül is.
flowchart LR
P["Termelő"] -->|"esemény"| C["Csatorna"]
C --> F1["Fogyasztó 1"]
C --> F2["Fogyasztó 2"]
Event notification
A termelő csak azt közli, hogy valami változott, minimális adattal. A fogyasztó szükség esetén visszakérdez. Így kicsi a csatolás: a termelőnek nem kell tudnia a fogyasztókról. Fowler figyelmeztet: a logikai folyamat szétszóródik, ezért nehéz látni, hibakeresni és módosítani. Az is gyakori hiba, hogy az „esemény” valójában parancs, amelyet a termelő elvár a fogadótól.
Event-carried state transfer
Az esemény magával viszi az adatot is, így a fogadó nem kérdez vissza, hanem saját másolatot frissít. Ez javítja a rugalmasságot (a forrás kiesésekor is van adat) és csökkenti a forrás terhelését, de másolja az adatot, és a fogadónak az állapotot kezelnie kell. A másolat frissessége a szerződés része (4.4, 5.1).
Hogyan viszonyulnak egymáshoz?
A négy minta egymástól függetlenül is használható, és kombinálható. Egy rendszer lehet event notification-alapú event sourcing nélkül, és használhat CQRS-t eseményektől függetlenül. A következő leckék az event sourcingot és a CQRS-t, majd a közös kompromisszumokat tárgyalják.
Gyakori tévhitek
Állítás
Pontosítás
„Az eseményvezérelt rendszer = event sourcing.”
Az event sourcing csak az egyik jelentés.
„Az események megszüntetik a csatolást.”
A kapcsolat az esemény szerződésén át megmarad (4.4).
„Az esemény parancs, csak más néven.”
Az esemény tény, a parancs szándék; ha az esemény parancsként viselkedik, az hiba.
„A CQRS eseményeket igényel.”
Nem szükségszerű; használható azok nélkül is.
Röviden
Az „eseményvezérelt” négy jelentése: event notification, event-carried state transfer, event sourcing, CQRS.
Az esemény tény, a parancs szándék.
Az event notification kis csatolású, de a folyamat szétszóródik.
Az event-carried state transfer adatot másol, cserébe csökkenti a függést.
Ellenőrző kérdések
Melyik a négy jelentés közül, amelyik nem is igényel eseményeket?
Mi a különbség az esemény-értesítés és az adatot szállító esemény között?
Miért veszélyes, ha az esemény valójában parancsként viselkedik?
Eseményvezérelt architektúra: négy különböző jelentés
Célok
A lecke végére meg tudod különböztetni az „eseményvezérelt” kifejezés négy jelentését, és fel tudod ismerni, melyikről van szó egy konkrét tervben.
Miért kell szétválasztani?
Ha két ember azt mondja, „eseményvezérelt rendszert építenek”, könnyen két különböző dologról beszél. Az egyik arra gondol, hogy a szolgáltatások értesítik egymást, a másik arra, hogy minden állapotváltozást eseménysorként tárolnak. A két megoldás költsége és kockázata nagyon eltér. Martin Fowler ezért négy külön mintát nevez meg.
Mi az esemény?
Az esemény megtörtént tény: „valami megtörtént”. Más, mint a parancs, amely szándékot fejez ki, és amelyet a címzett elutasíthat (részletesen a 6.2 leckében). A termelő nem vár a fogyasztóra, és nem is tud róla; az Azure Architecture Center is úgy írja le, hogy a termelők és a fogyasztók közvetlen függés nélkül, csatornán vagy közvetítőn át kommunikálnak.
A négy jelentés
Fowler hangsúlyozza, hogy a CQRS szigorúan véve nem az eseményekről szól, és használható azok nélkül is.
Event notification
A termelő csak azt közli, hogy valami változott, minimális adattal. A fogyasztó szükség esetén visszakérdez. Így kicsi a csatolás: a termelőnek nem kell tudnia a fogyasztókról. Fowler figyelmeztet: a logikai folyamat szétszóródik, ezért nehéz látni, hibakeresni és módosítani. Az is gyakori hiba, hogy az „esemény” valójában parancs, amelyet a termelő elvár a fogadótól.
Event-carried state transfer
Az esemény magával viszi az adatot is, így a fogadó nem kérdez vissza, hanem saját másolatot frissít. Ez javítja a rugalmasságot (a forrás kiesésekor is van adat) és csökkenti a forrás terhelését, de másolja az adatot, és a fogadónak az állapotot kezelnie kell. A másolat frissessége a szerződés része (4.4, 5.1).
Hogyan viszonyulnak egymáshoz?
A négy minta egymástól függetlenül is használható, és kombinálható. Egy rendszer lehet event notification-alapú event sourcing nélkül, és használhat CQRS-t eseményektől függetlenül. A következő leckék az event sourcingot és a CQRS-t, majd a közös kompromisszumokat tárgyalják.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források