Az eseményvezérelt megoldások kompromisszumai

Célok

A lecke végére meg tudod mondani, mikor előnyös az eseményvezérelt szerkezet, milyen költségekkel jár a hét szempont szerint, és mikor érdemes szinkron hívást megtartani.

Miért kell külön?

Az események csábítóak: lazán kapcsoltnak és rugalmasnak látszanak. A költségük viszont nem a termelő oldalán jelentkezik, hanem a rendszer egészének megértésében, az adatok frissességében és az ismétlődő, késő vagy rossz sorrendű üzenetek kezelésében.

Mikor erős?

Az Azure Architecture Center szerint az eseményvezérelt stílus ott kiemelkedő, ahol kis késleltetésű, közel valós idejű feldolgozás kell (például eszközadatok, tőzsdei rendszerek, nagy adatfolyamok), és kitűnő skálázhatóságot és hibaizolációt ad. A termelők és a fogyasztók függetlenül fejleszthetők és skálázhatók, és a közvetítő pufferelése segíthet az átmeneti hibáknál.

Mik a költségei?

Ugyanez a leírás kihívásként említi a kézbesítési garanciát, az események sorrendjét és az elosztott komponensek közötti végső konzisztenciát.

Szempont	Hatás
Csatolás	Kisebb futásidejű függés, de az esemény szerződése (típus, azonosító, verzió, jelentés) közös függés marad
Deployolhatóság	Termelő és fogyasztó külön kiadható, ha a séma kompatibilis
Skálázás	A fogyasztók külön skálázhatók
Adatkezelés	Adatmásolatok keletkeznek, és gondozásuk a fogyasztó dolga
Konzisztencia	Végső konzisztencia; a felhasználó saját módosítását is késve láthatja
Hibakezelés	Ismétlés, duplikáció, késői és sorrenden kívüli üzenetek (8. fejezet)
Költség	A folyamat követése, a megfigyelés és a hibakeresés nehezebb

Követhetőség

Event notification esetén a teljes folyamat nem látható egyetlen helyen. Egy új fogyasztó látszólag ártatlan feliratkozása új üzleti visszacsatolást is létrehozhat. Ezért a folyamat követéséhez azonosítókra, megfigyelésre és dokumentált eseményszerződésre van szükség (5.2, 8. fejezet).

Az esemény szerződése

Az eseménynek stabil típusa, azonosítója, sémaverziója és üzleti jelentése legyen. Az időbélyeg nem garantál globális sorrendet. Az adatgazda ne a teljes belső tábláját küldje automatikusan minden változáskor: a publikus esemény az együttműködés szerződése, nem a belső adatbázis tükre. Az esemény vihet teljes adatot (kisebb függés, nagyobb séma) vagy csak azonosítót (kisebb séma, visszakérdezés, vagyis szinkron függés).

Mikor tartsuk meg a szinkron hívást?

Ha azonnali döntés kell (jogosultság, foglalás eredménye), a közvetlen válasz természetes. Az események jól illenek a hosszú feldolgozáshoz és a több önálló reakcióhoz. Nem minden szolgáltatáshívást kell eseményre cserélni, mert az aszinkron működés ára a függő állapot, a késői eredmény és a több helyen követett folyamat (6.2).

flowchart TD
  Q{"Azonnali válasz kell<br/>a hívónak?"} -->|"Igen"| S["Szinkron kérés–válasz"]
  Q -->|"Nem"| R{"Több független<br/>reakció kell?"}
  R -->|"Igen"| E["Esemény"]
  R -->|"Nem"| K["Parancs, sor"]

Gyakori tévhitek

Állítás	Pontosítás
„Az eseményekkel a rendszer automatikusan lazán kapcsolt.”	A csatolás az eseményszerződésbe költözik.
„Az aszinkron mindig gyorsabb.”	Az eredmény késhet; a felhasználó oldalán függő állapot keletkezik.
„Minden hívást eseményre kell cserélni.”	Az azonnali döntéseknél a szinkron hívás természetes.

Röviden

• Az eseményvezérelt szerkezet erős valós idejű feldolgozásnál és független fogyasztóknál.
• Költsége: követhetőség, séma, végső konzisztencia, ismétlés és sorrend.
• Az esemény szerződés, nem a belső adat tükre.
• Azonnali döntéshez a szinkron hívás természetes.

Ellenőrző kérdések

1. Hol jelentkezik a költség egy eseményvezérelt szerkezetben, ha a termelő oldala egyszerűnek látszik?
2. Mikor érdemesebb az eseményben teljes adatot küldeni, és mikor csak azonosítót?
3. Mely helyzetben maradnál szinkron hívásnál?

Források

• Architecture styles (Azure Architecture Center) — az eseményvezérelt stílus előnyei és kihívásai.
• What do you mean by “Event-Driven”? (Martin Fowler) — a követhetőség és az álcázott parancsok problémája.