Az eseményvezérelt architektúra az eseménystreamet létrehozó eseménykészítőkből és az eseményeket figyelő eseményfeldolgozókból áll.
Az események kézbesítése közel valós időben történik, így a feldolgozók azonnal reagálhatnak rájuk, amint bekövetkeznek. A termelők el vannak választva a fogyasztóktól – a gyártó nem tudja, hogy mely fogyasztók figyelnek. A feldolgozók szintén el vannak választva egymástól, és minden feldolgozó minden eseményt lát. Ez eltér a versengő felhasználók mintától, amelyben a feldolgozók egy üzenetsorból kérik le az üzeneteket, és az üzenetek feldolgozására csak egyszer kerül sor (amennyiben nem történik hiba). Bizonyos rendszerekben, amilyen például az IoT, az események betöltése nagyon nagy mennyiségben történik.
Az eseményvezérelt architektúra használhat közzétételi /előfizetési (más néven pub/sub) modellt vagy eseménystream-modellt.
Közzétevői/előfizetői modell: Az üzenetkezelési infrastruktúra nyomon követi az előfizetéseket. Esemény közzétételekor az eseményt minden előfizetőnek elküldi. Az esemény fogadása után az nem játszható vissza, és az új előfizetők nem látják az eseményt.
Eseménystreamelés: Az eseményeket egy naplóba írja. A rendszer szigorú sorrendben tárolja az eseményeket (egy partíción belül), és meg is őrzi őket. Az ügyfelek nem fizetnek elő a streamre, hanem a stream bármelyik részét beolvashatják. Az ügyfél felelőssége, hogy továbbhaladjon a streamen belül. Ez azt jelenti, hogy az ügyfél bármikor csatlakozhat, és visszajátszhatja az eseményeket.
A feldolgozói oldalon több gyakori változat áll rendelkezésre:
Egyszerű eseményfeldolgozás. Az esemény azonnali műveletet aktivál a feldolgozónál. Az Azure Functions és egy Service Bus-trigger használatával például kiválthatja egy függvény végrehajtását, amikor közzétesznek egy üzenetet egy Service Bus-témakörben.
Alapvető eseménykorreláció. A fogyasztónak kis számú különálló üzleti eseményt kell feldolgoznia, amelyek általában valamilyen azonosítóval vannak összefüggésben, és megőriznek bizonyos információkat a korábbi eseményekből, amelyeket a későbbi események feldolgozásakor használnak fel. Ezt a mintát olyan kódtárak támogatják, mint az NServiceBus és a MassTransit.
Összetett eseményfeldolgozás. A fogyasztó események sorozatát dolgozza fel, mintákat keresve az eseményadatokban egy olyan technológiával, mint az Azure Stream Analytics. Összesíthet például beágyazott eszközből származó adatokat egy adott időtartamra vonatkozóan, és értesítést hozhat létre, ha a mozgó átlag átlép egy bizonyos küszöbértéket.
Eseménystream-feldolgozás. Egy adatstreamelési platformot (például az Azure IoT Hubot vagy az Apache Kafkát) folyamatként használva olvashatja be az eseményeket, és továbbíthatja azokat a streamfeldolgozóknak. A streamfeldolgozók feldolgozzák vagy átalakítják a streamet. Több streamfeldolgozó is használható az alkalmazás különböző alrendszereihez. Ez a megközelítés jó megoldás lehet IoT számítási feladatokhoz.
Az események forrása lehet a rendszeren kívüli is, ilyenek például egy IoT-megoldás fizikai eszközei. Ebben az esetben a rendszernek képesnek kell lennie az adatoknak olyan mennyiségben és átviteli sebességen történő beolvasására, amelyet az adatforrás megkövetel.
A fenti logikai ábrán az egyes feldolgozótípusok külön dobozként jelennek meg. A gyakorlatban sokszor előfordul, hogy egy feldolgozó több példánya fut is annak érdekében, nehogy a feldolgozó hibaérzékeny ponttá váljon a rendszerben. Több példányra a nagy mennyiségű vagy gyakori események kezeléséhez is szükség lehet. Emellett egy adott feldolgozó több szálon is feldolgozhat eseményeket. Ez kihívást jelenthet, ha az eseményeket sorrendben kell feldolgozni, vagy pontosan egyszer szemantika szükséges. Lásd: A koordináció minimalizálása.
Számos eseményvezérelt architektúrában két elsődleges topológia található:
Közvetítői topológia. Az összetevők eseményekként közvetítik az eseményeket a teljes rendszer számára, és más összetevők vagy az eseményre reagálnak, vagy egyszerűen figyelmen kívül hagyják az eseményt. Ez a topológia akkor hasznos, ha az eseményfeldolgozási folyamat viszonylag egyszerű. Nincs központi koordináció vagy vezénylés, így ez a topológia nagyon dinamikus lehet. Ez a topológia nagymértékben leválasztva van, ami segít a méretezhetőség, a válaszképesség és az összetevők hibatűrésének biztosításában. Egyetlen összetevő sem rendelkezik többhelyes üzleti tranzakció állapotával, és a műveletek aszinkron módon lesznek végrehajtva. Ezt követően az elosztott tranzakciók kockázatosak, mert nincs natív eszköz az újraindításra vagy az újrajátszásra. A hibakezelést és a manuális beavatkozási stratégiákat körültekintően kell figyelembe venni, mivel ez a topológia az adatinkonzisztencia forrása lehet.
Mediátortopológia. Ez a topológia a közvetítői topológia néhány hiányosságát kezeli. Van egy eseményt közvetítő, amely kezeli és szabályozza az események áramlását. Az esemény mediátora fenntartja az állapotot, és kezeli a hibakezelési és újraindítási képességeket. A közvetítői topológiával ellentétben az összetevők parancsként és csak a kijelölt csatornákon, általában üzenetsorokként közvetítik az előfordulásokat. Ezeket a parancsokat a felhasználók várhatóan nem hagyják figyelmen kívül. Ez a topológia több vezérlést, jobb elosztott hibakezelést és potenciálisan jobb adatkonzisztenciát kínál. Ez a topológia megnöveli az összetevők közötti összekapcsolást, és az eseményközvetítés szűk keresztmetszetté vagy megbízhatósági problémává válhat.
Mikor érdemes ezt az architektúrát használni?
- Több alrendszernek ugyanazokat az eseményeket kell feldolgoznia.
- Valós idejű feldolgozásra van szükség, minimális időbeli késés mellett.
- Összetett eseményfeldolgozásra van szükség, például mintaegyeztetésre vagy időtartamokra vonatkozó összesítésre.
- Nagy mennyiségű vagy gyakoriságú adatról van szó, például IoT esetén.
Juttatások
- A létrehozók és a feldolgozók el vannak választva egymástól.
- Nincs pont–pont integráció. Az új feldolgozók egyszerűen adhatók hozzá a rendszerhez.
- A feldolgozók az érkezésükkor azonnal reagálhatnak az eseményekre.
- Hatékonyan méretezhető és elosztható.
- Az alrendszerek az eseménystream önálló nézetével rendelkeznek.
Problémák
Garantált kézbesítés.
Egyes rendszerekben, különösen IoT-forgatókönyvek esetén, alapvető fontosságú az események kézbesítésének garantálása.
Események feldolgozása sorrendben vagy pontosan egyszer.
Általában minden feldolgozótípus több példányban fut a rugalmasság és a méretezhetőség érdekében. Ez kihívást jelenthet, ha az eseményeket sorrendben kell feldolgozni (egy fogyasztói típuson belül), vagy az idempotens üzenetfeldolgozási logika nincs implementálva.
Üzenetek koordinálása a szolgáltatások között.
Az üzleti folyamatok gyakran több szolgáltatás közzétételét és az üzenetekre való feliratkozást foglalják magukban, hogy egységes eredményt érjenek el egy teljes számítási feladatban. Az olyan munkafolyamat-minták, mint a koreográfiai minta és a Saga Vezénylés, megbízhatóan kezelhetők a különböző szolgáltatások üzenetfolyamai.
Hibakezelés.
Az eseményvezérelt architektúra főként aszinkron kommunikációt használ. Az aszinkron kommunikáció egyik kihívása a hibakezelés. A probléma megoldásának egyik módja egy külön hibakezelő processzor használata. Így amikor az eseményfelhasználó hibát tapasztal, azonnal és aszinkron módon elküldi a hibás eseményt a hibakezelő processzornak, és továbblép. A hibakezelő processzor megpróbálja kijavítani a hibát, és visszaküldi az eseményt az eredeti betöltési csatornára. Ha azonban a hibakezelő processzor meghibásodik, akkor elküldheti a hibás eseményt egy rendszergazdának további vizsgálat céljából. Ha hibakezelő processzort használ, a rendszer a hibás eseményeket sorozaton kívül dolgozza fel az újraküldéskor.
További szempontok
- Az eseménybe belefoglalandó adatok mennyisége jelentős szempont lehet, amely hatással van a teljesítményre és a költségekre is. Ha az eseményben a feldolgozáshoz szükséges összes releváns információt elhelyezi, azzal leegyszerűsítheti a feldolgozási kódot, és további kereséseket menthet. Ha a minimális mennyiségű információt egy eseménybe helyezi, például néhány azonosítót, azzal csökkentheti az átviteli időt és a költségeket, de a feldolgozási kódnak szüksége van a további információk keresésére. Erről további információt ebben a blogbejegyzésben talál.
- Bár a kérések csak a kérelemkezelő összetevő számára láthatók, az események gyakran láthatók a számítási feladat több összetevője számára, még akkor is, ha ezek az összetevők nem vagy nem arra szolgálnak, hogy felhasználják őket. A "vélelmezéssel" kapcsolatos gondolkodásmóddal való működés során ügyeljen arra, hogy milyen információkat tartalmaz az eseményekben, hogy megelőzze a nem szándékos információexpozíciót.
Kapcsolódó erőforrások
- Közösségi vitavideó a koreográfia és a vezénylés közötti választás szempontjairól.