Definice architektury řízená událostmi a proč na ní záleží

Architektura řízená událostmi je přístup k návrhu softwaru, který umožňuje organizacím okamžitě reagovat na jakoukoli smysluplnou změnu stavu. Představte si, že by podnik mohl reagovat na okamžik, kdy se stane něco důležitého, například zákazník učiní online nákup, senzor označí hrozící selhání, klesne cena akcií nebo se spustí bezpečnostní upozornění. Tyto změny – tzv. události – se dějí neustále, napříč každou organizací, v každém odvětví. Úspěch souvisí s tím, jak rychle může podnik reagovat na události.

Zde přichází architektura řízená událostmi (EDA). Místo čekání na plánované aktualizace nebo spoléhání se na pevné, těsně propojené systémy, architektura řízená událostmi umožňuje aplikacím asynchronně komunikovat prostřednictvím volně spojených komponent. To znamená, že každá část systému může jednat nezávisle – aniž by znala vnitřní fungování ostatních – což usnadňuje škálování, přizpůsobování a inovaci.

Výsledkem je, že moderní systémy využívající architekturu řízenou událostmi umožňují podnikům poskytovat rychlejší, personalizovanější prostředí, automatizovat operace a zůstat agilní, i když požadavky a objemy dat rostou. Přijetím architektury řízené událostmi přecházejí organizace od reaktivní k proaktivní, získávají rychlost, flexibilitu a odolnost potřebnou k prosperitě v dynamickém digitálním světě.

Co je to událost?

Událost je jakákoli akce nebo změna stavu, která má dopad na podnik – například když zákazník přejede kreditní kartou, cestující se přihlásí k letu, uživatel resetuje heslo nebo sklad aktualizuje svůj inventář. Zamyslete se nad tím takto: událost je malá zpráva, která říká „něco, co se právě stalo“, umožňující ostatním částem systému okamžitě reagovat.

Společnosti se stávají hnací silou, když mohou zachytit a reagovat na události tak, jak k nim dochází, což je pořád. Mezi běžné příklady událostí patří:

• Platba selže nebo je úspěšná
• Uživatel se přihlásí nebo se odhlásí
• Pokles zásob pod prahovou hodnotu
• Zásilka opustí sklad nebo dorazí na místo určení
• Porušení zabezpečení spustí výstrahu
• Věrnostní program aktualizuje bodové zůstatky
• Tým podpory vytvoří tiket
• Zákazník aktualizuje svou dodací adresu
• Nový uživatel vytvoří účet
• Nakupující předloží recenzi produktu
• Odběratel prodlouží nebo zruší odběr

Základní komponenty architektury řízené událostmi

Aby byla zachována konzistentní struktura, definují schémata událostí strukturu a formát události včetně polí, která událost obsahuje, datových typů a pravidel pro interpretaci.

V architektuře řízené událostmi fungují aplikace jako producentiudálostí – kteří produkují nebo zachycují události – nebo spotřebiteleudálostí – kteří zpracovávají události a jednají na nich. Výrobci přenášejí události spotřebitelům v reálném čase prostřednictvím zprostředkovatele událostí, což je middleware zaměřený na zprávy. Spotřebitelé pak mohou událost zpracovat a spustit další vlastní akce, workflow nebo události. Tento design umožňuje reagovat v reálném čase a chytřejší rozhodování jako datové toky v.

Zprostředkovatel události spravuje kanály událostí, které propojují výrobce se spotřebiteli, zajišťuje spolehlivé dodání a často poskytuje funkce, jako je filtrování, perzistence a přehrávání. Oddělením výrobců a spotřebitelů činí zprostředkovatel akcí systém odolnějším a škálovatelnějším.

Ve velmi jednoduché architektuře s jediným producentem a jediným spotřebitelem v přímé komunikaci mezi sebou mohou být zprostředkovatelé akcí volitelní. Ve většině podniků však více zdrojů vysílá události více spotřebitelům, takže je potřeba makléř, nebo dokonce síť brokerů – také známá jako „síť událostí“. Při použití event brokeru nebo sítě událostí se vytvoří „volné spojení“ aplikací.

Synchronní vs. asynchronní komunikace

Při synchronní komunikaci v architektuře řízené událostmi čeká producent události na to, až příjemce zpracuje a odpoví, než bude pokračovat. Příkladem může být, když webový klient odešle HTTP požadavek a čeká na odpověď serveru. Synchronní komunikace je obvykle těsně spojena a pomalejší při těžkých zátěžích a „blokuje“ výrobce od provedení svého dalšího úkolu, dokud neobdrží odpověď od spotřebitele.

Při asynchronní komunikaci v architektuře řízené událostmi výrobce nečeká na okamžitou reakci; může pokračovat ve zpracování, zatímco spotřebitel události zprávu zpracuje později. Příkladem může být, když systém publikuje událost zprostředkovateli události a spotřebitelé ji zpracovávají nezávisle. Asynchronní komunikace je neblokující, volně spojená a škálovatelná, takže je lepší pro systémy v reálném čase a distribuované systémy.

Modely řízené požadavky vs. modely řízené událostmi v architektuře řízené událostmi

V modelu řízeném požadavkem začíná interakce požadavkem od spotřebitele události na server a server odpoví. Tento model je založen na tahu – což znamená, že spotřebitel aktivně požaduje data nebo služby ze serveru, když je potřebuje, místo aby přijímal automatické aktualizace – a může být synchronní nebo asynchronní. Modely řízené požadavky jsou běžné v tradičních webových aplikacích a rozhraních API.

V modelu řízeném událostmi začíná interakce událostí – změnou stavu nebo akce, která spouští zpracování – a komponenty reagují automaticky, když dojde k událostem, například publikování/subskripce. Tento model je typicky založený na tlaku – což znamená, že systém automaticky odesílá („push“) události nebo aktualizace spotřebitelům, jakmile k nim dojde, aniž by čekal, až je spotřebitel požádá. Modely řízené událostmi jsou asynchronní, oddělené a ideální pro odezvu v reálném čase.

Přemýšlejte o klíčových rozdílech mezi modely tímto způsobem: v modelech řízených požadavky uživatelé požadují data, když je to potřeba; modely řízené událostmi automaticky reagují, když se něco stane.

Společné vzory architektury řízené událostmi

Architektonické vzory řízené událostmi jsou běžné návrhové přístupy, které definují, jak systém řízený událostmi zachycuje, zpracovává a spotřebovává události. Vzory poskytují opakovaně použitelné strategie pro zpracování komunikace a změny stavu škálovatelným, odděleným způsobem. Organizace aplikují během návrhu a implementace systému vzory architektury řízené událostmi, aby vyřešily společné výzvy. Patří mezi ně distribuce událostí, konzistence dat a škálovatelnost v asynchronních, volně propojených prostředích.

Existují čtyři hlavní vzory pro přenos událostí v architektuře řízené událostmi:

• Publish/subscribe (neboli „pub/sub“): S hospodou/sub se spotřebitelé události přihlašují k odběru zpráv a kanálů zveřejněných producenty událostí. Když je událost publikována, odešle se přímo všem odběratelům pomocí zprostředkovatele události. Aby se zabránilo duplicitě, nelze události přehrát nebo k nim přistupovat, jakmile jsou spotřebovány, protože je broker odstraní.
• Streaming událostí: S streamováním událostí producenti zveřejňují celé proudy událostí makléři. Spotřebitelé si odebírají stream a mohou číst z jakékoli jeho části, spotřebovávají pouze události, které jsou pro ně relevantní. Při streamování událostí si broker uchovává události i poté, co jsou spotřebovány.
• Segregace odpovědnosti za příkazový dotaz (CQRS): Se vzorem CQRS odděluje návrh aplikace a vrstva architektury operace čtení a zápisu do různých modelů. Příkazy aktualizují stav při čtení dotazů. V architektuře řízené událostmi vzor CQRS často pracuje s událostmi na asynchronním šíření změn, což zlepšuje škálovatelnost a výkon pro komplexní systémy.
• Strategický nákup událostí: Při strategickém nákupu událostí systém zaznamená každou změnu stavu jako událost do připojeného protokolu namísto uložení pouze aktuálního stavu entity. Aktuální stav lze obnovit přehráním těchto událostí. To poskytuje kompletní revizní záznam a podporuje scénáře cestování a obnovy.

Styly zpracování událostí

Styly zpracování událostí popisují, jak systém detekuje, interpretuje a působí na události. Definují složitost logiky, načasování a vztahů mezi událostmi, kterým systém rozumí. Existují tři různé přístupy ke zpracování událostí, jakmile se dostanou ke spotřebiteli: jednoduché zpracování událostí, složité zpracování událostí a zpracování proudu událostí.

1. Jednoduché zpracování události: Spotřebitelé zpracují každou událost tak, jak je přijata. Příklady:

• Zákazník zadá objednávku a vyzve systém, aby odeslal potvrzovací e-mail a aktualizoval zásoby.
• Požadavek na resetování hesla spustí okamžitý e-mail se zabezpečeným odkazem.
• Úspěšná platba způsobí, že se vygeneruje stvrzenka a odešle se zákazníkovi.
• Pro sledování zabezpečení je okamžitě zaznamenáno uživatelské přihlášení.

2. Komplexní zpracování událostí: Spotřebitelé zpracovávají řadu událostí k detekci vzorců a provádění akcí na základě výsledku. Příklady:

• Několik transakcí s vysokou hodnotou v rychlém sledu vyvolá upozornění na podvod.
• Rostoucí teplota v kombinaci se zvýšenými vibracemi signalizuje hrozící poruchu zařízení.
• Pokusy o přihlášení z různých zemí během několika minut spustí bezpečnostní varování.
• Opakované opuštění košíku stejným uživatelem vyvolá personalizovanou nabídku slevy.

3. Zpracování toku událostí: Spotřebitelé zpracovávají a pracují na konstantním toku dat (data v pohybu) v reálném čase pomocí platformy pro streamování dat. Příklady:

• Kolísání cen akcií vede k okamžitému provedení obchodu na základě předdefinovaných pravidel.
• Nárůst v sociálních médiích zmiňuje aktualizace řídicích panelů smýšlení za běhu.
• Telemetrie z připojených vozidel dynamicky upravuje dopravní signály.
• Data Clickstream z webu e-commerce podporují doporučení produktů v reálném čase.

Podniky si vybírají styl zpracování událostí v reálném čase na základě jejich individuálních potřeb a případů použití.

Jak funguje architektura řízená událostmi

Architektura řízená událostmi je integrační model vytvořený pro publikování, zachycování, zpracování a reakci na události napříč distribuovanými systémy v reálném čase. Když dojde k události v jedné aplikaci, automaticky se odešle zpráva všem ostatním aplikacím, které o ní potřebují vědět, takže na ni zase mohou reagovat.

Následující příklad ukazuje, jak funguje architektura řízená událostmi krok za krokem:

1. Dochází k události: Dochází ke smysluplné změně stavu, například zákazník zadá objednávku, snímač detekuje teplotní špičku nebo selže platba.
2. Producent události vyzařuje: Žádost, kde k události došlo, působí jako producent a uveřejňuje událost zprostředkovateli události.
3. Zprostředkovatel události nasměruje událost: Zprostředkovatel události spravuje kanály událostí a dodává událost všem spotřebitelům, kteří mají zájem o událost, což pomáhá zajistit spolehlivou, škálovatelnou a oddělenou komunikaci.
4. Spotřebitelé události reagují na událost: Aplikace nebo služby, které se přihlásily k odběru kanálu událostí, událost zpracují a provedou příslušné akce, jako je aktualizace inventáře, odeslání potvrzovacího e-mailu nebo spuštění výstrahy.

Architektury založené na událostech jsou asynchronní a oddělené – to znamená, že aplikace si nemusí být navzájem vědomy, aby sdílely informace a dokončovaly úlohy v reálném čase. Informace o událostech nebo zprávy mohou mezi aplikacemi volně a automaticky proudit. Výsledkem je, že architektonický model řízený událostmi je mnohem rychlejší a odolnější než tradiční modely řízené požadavky a odezvou, kde jedna aplikace musí požadovat konkrétní informace, které potřebuje od druhého, a počkat na odpověď, než přejde k dalšímu úkolu. Vzhledem k oddělené povaze architektury řízené událostmi je také široce považován za osvědčený postup pro komunikaci mikroslužeb.

Případy použití a příklady z reálného světa

Architektura řízená událostmi podporuje moderní digitální zkušenosti napříč odvětvími, od bankovnictví a maloobchodu až po výrobu a logistiku. Aktivací automatizace založené na umělé inteligenci, inteligence o událostech a schopnosti reagovat v reálném čase pomáhá architektura řízená událostmi organizacím modernizovat IT, oddělit starší systémy a hladce pracovat v prostředích s více cloudy.

Následující příklady ukazují, jak architektura řízená událostmi funguje v praxi.

Restaurace

1. Vysokoškolák zadá objednávku na pizzu pomocí aplikace pro rozvoz jídla. Aplikace zachycuje jeho základní informace – jméno, adresu, platební údaje a objednávku – a publikuje událost „objednávka pizzy“.
2. Restaurace na pizzu se přihlásí k odběru akce, splní objednávku a zveřejní svou vlastní „objednávku připravenou“ akci zpět do doručovací služby.
3. Služba pak přidělí řidiči dodávky, naplánuje ETA a upozorní zákazníka, že jeho koláč je na cestě.

E-commerce

1. Internetový nakupující zadá údaje o své kreditní kartě na stránce e-commerce, kde zveřejní událost „odeslaná platba“.
2. Platební systém se přihlásí k odběru události, zpracuje platbu a vydá vlastní událost „zpracovaná platba“, která indikuje úspěch nebo neúspěch, a přesměruje ji zpět do uživatelského rozhraní webové stránky.
3. Uživatelské rozhraní zobrazuje status platby zákazníkovi a vyzývá k dalším krokům.

Některé další příklady architektury řízené událostmi zahrnují:

Telemetrie IoT

• Chytrá továrna streamuje data snímače pro detekci teplotních špiček a zabránění selhání zařízení.
• Propojená vozidla vysílají telemetrii, aby dynamicky optimalizovala dopravní tok.
• Chytrá domácí zařízení zveřejňují události týkající se spotřeby energie, aby se spustila doporučení pro úsporu nákladů.

Analytické funkce a informace o událostech

• Obchodník analyzuje data toku kliknutí v reálném čase a personalizuje doporučení produktů.
• Banka monitoruje vzorce transakcí, aby odhalila podvod předtím, než k němu dojde.
• Logistická společnost využívá streamovaná data k predikci zpoždění dodávek a přesměrování zásilek.

Automatizace

• Personalistický systém automaticky zajišťuje softwarový přístup pro nového zaměstnance, včetně přiřazování licencí a oprávnění.
• Zdravotnický systém spouští automatická upozornění, když pacient překročí kritické prahové hodnoty.
• Cloudová platforma dynamicky škáluje zdroje na základě událostí zatížení systému.

Finanční transakce

• Platební brána uveřejňuje událost „odeslaná platba“, která před schválením spouští kontroly podvodů.
• Obchodní platforma provádí příkazy k nákupu/prodeji okamžitě, když ceny akcií kolísají.
• Banka účtuje vklady a aktualizuje zůstatky na účtu v reálném čase.

Dodavatelský řetězec

• Sklad aktualizuje úrovně zásob a automaticky spustí objednávky doplnění.
• Dodací služba přesměrovává řidiče v reálném čase na základě dopravních a meteorologických událostí.
• Výrobce upravuje plány výroby na základě signálů poptávky v reálném čase.

Modernizace IT a oddělení starších verzí

• Společnost odebírá práci ze své mainframe tím, že publikuje obchodní události do moderních cloudových služeb pro klíčové funkce.
• Organizace vystavuje rozhraní událostí v reálném čase kolem staršího ERP, takže nové aplikace mohou okamžitě reagovat, aniž by se dotkly backendu.
• Podnik zrcadlí události ze starého CRM do moderní platformy SaaS, která udržuje oba systémy synchronizované během postupné migrace.

Oznámení

• Poskytovatel veřejných služeb upozorní zákazníky na okamžik, kdy je zjištěn výpadek proudu v jejich oblasti, a aktualizuje je o pokroku posádky obnovy.
• Cestovní aplikace zasílá cestujícím upozornění v reálném čase, když se změní jejich přiřazení brány, což zajistí, že mohou okamžitě upravit své plány.
• Streamovací služba odesílá personalizovaná doporučení poté, co uživatel dokončí show.
• Bezpečnostní systém odesílá upozornění, když je zjištěna podezřelá činnost přihlášení.

Všeobecné případy použití architektury řízené událostmi zahrnují:

• Online nakupující klikne na produkt a systém reaguje generováním doporučení produktů na základě podobných položek.
• Obchodník zobrazí globální transakce pro podvody a označí podezřelé nákupy vydavateli kreditních karet.
• Zapojení zákazníků v reálném čase využívá streamování dat o chování uživatelů ke spuštění personalizovaných nabídek nebo dynamických cen během nákupní relace.
• Monitorování zdravotní péče zveřejňuje vitální funkce pacientů z připojených zařízení, aby okamžitě upozornil lékaře při překročení prahových hodnot.
• Chytré městské provozy řídí semafory a jízdní řády veřejné dopravy na základě provozu v reálném čase a meteorologických událostí.
• Detekce kybernetických bezpečnostních hrozeb identifikuje podezřelou síťovou aktivitu nebo neoprávněné pokusy o přístup v reálném čase a reaguje na ni.
• Optimalizace cloudových zdrojů automaticky škáluje výpočetní zdroje napříč prostředími s více cloudy, když dojde k nárůstu zatížení.

Výhody architektury řízené událostmi

Organizace mohou uplatnit výhody architektury řízené událostmi na své moderní systémy. Mezi hlavní výhody architektury založené na událostech patří:

1. Reakce v reálném čase a inteligentní pracovní postupy: Architektura řízená událostmi umožňuje systémům okamžitě reagovat na události tak, jak k nim dochází, což spouští automatizované pracovní postupy a rozhodnutí v reálném čase. To je obzvláště důležité v době špičkové poptávky – například během velkých prodejních událostí nebo svátků. Organizace mohou tuto schopnost reakce aplikovat na každodenní provoz, což zlepšuje vše od automatizace dodavatelského řetězce a odhalování podvodů až po personalizované zapojení zákazníků.
2. Rychlost a efektivita pomocí asynchronní komunikace: Aplikace v architektuře řízené událostmi komunikují asynchronně, což znamená, že výrobci publikují zprávy o událostech bez čekání na jejich příjem. Tento neblokující přístup zlepšuje výkon, snižuje latenci a umožňuje systémům zpracovávat masivní objemy událostí bez úzkých míst.
3. Flexibilita a škálovatelnost prostřednictvím oddělení a volného spojení: Komponenty v architektuře řízené událostmi jsou odděleny nebo volně spojeny, takže fungují nezávisle, aniž by se vzájemně spoléhaly na dostupnost nebo vnitřní logiku. Díky tomu je snadné aktualizovat, testovat a nasazovat služby, aniž by došlo k narušení celého systému. Oddělení plateb také usnadňuje podle potřeby přidávat další výrobce a spotřebitele, což umožňuje bezproblémové rozšiřování s rostoucími potřebami podniku.
4. Odolnost a izolace chyb: S oddělenými službami se poruchy v jedné komponentě nekaskádují napříč systémem. Každá služba může selhat nezávisle, díky čemuž je architektura odolnější a odolnější vůči chybám než tradiční těsně spojené modely.
5. Integrace připravená na budoucnost: Volné spojení a asynchronní design činí architekturu řízenou událostmi ideální pro modernizaci IT, odpojení starších systémů a více cloudových operací. Organizace získávají flexibilitu při integraci nových technologií – jako je automatizace založená na umělé inteligenci a informace o událostech – bez přepisování základních systémů.

Výzvy, omezení a osvědčené postupy

Architektury řízené událostmi sice nabízejí silné výhody, ale přinášejí také nové konstrukční a provozní výzvy, které musí organizace plánovat. Při implementaci architektury řízené událostmi zvažte následující výzvy architektury řízené událostmi, omezení a osvědčené postupy k zajištění škálovatelných, odolných a dobře řízených systémů řízených událostmi.

Výzvy

• Složitost distribuovaných systémů: Řízení sítě zprostředkovatelů událostí napříč více prostředími přináší architektonickou složitost. Navrhování toků událostí, zajištění konzistence schématu a zpracování asynchronní komunikace vyžaduje pokročilé plánování a odborné znalosti. Bez náležité kontroly designu mohou organizace zažít chaos událostí, protože objemy událostí, výrobci a spotřebitelé rostou.
• Správa a dodržování předpisů: S událostmi proudícími napříč hybridními a multicloudovými prostředími je prosazování zásad správy – jako je ochrana dat, zabezpečení a dodržování předpisů – problematické. Organizace potřebují robustní řídicí rámce, které zabrání únikům dat a neoprávněnému přístupu a udržují kontrolu nad rychle se rozšiřující infrastrukturou událostí.
• Ladění a pozorovatelnost: Řešení problémů v asynchronním, volně spojeném systému je složitější než u tradičních architektur. Identifikace hlavní příčiny selhání nebo zpoždění vyžaduje pokročilé možnosti monitorování, sledování a přehrávání událostí. To platí zejména tehdy, když týmy řeší problémy vyplývající ze složitých řetězců událostí nebo řeší příznaky chaosu událostí.

Jak zapadá síť událostí

Síť událostí je architektonická schopnost, která propojuje více zprostředkovatelů událostí napříč různými hyperškálovači a v soukromých, hybridních a multicloudových prostředích. Síť událostí nabízí kompletní sadu pokročilých služeb pro vytváření událostí, včetně streamování událostí, správy událostí, monitorování, dynamického směrování zpráv a jemného filtrování. Propojením zprostředkovatelů událostí s distribuovanou sítí mohou organizace:

• Snižte složitost centralizovaným směrováním a správou událostí.
• Podporujte správu katalogů událostí, vynucování schémat a monitorování.
• Zlepšete pozorovatelnost prostřednictvím sledování událostí, přehrávání a pokročilých analytických nástrojů.
• Umožněte škálovatelnost a odolnost napříč hybridními a multicloudovými prostředími.

Jako páteř moderních systémů je síť událostí základní vrstvou pro škálovatelné architektury řízené událostmi v reálném čase. Pomáhá zajistit schopnost reagovat v reálném čase a zároveň zjednodušuje integraci, snižuje chaos při událostech a posiluje možnosti řešení problémů napříč distribuovanými prostředími.

Omezení architektury řízené událostmi

• Provozní režie: Systémy řízené událostmi vyžadují specializované nástroje pro správu událostí, validaci schémat a monitorování, což může zvýšit provozní složitost.
• Požadavky na dovednosti: Implementace a údržba sítě událostí a vzorů architektury založených na událostech vyžadují odborné znalosti v distribuovaných systémech, zprostředkovatelích událostí a integračních platformách.
• Rizika zpoždění: Zatímco architektura řízená událostmi je navržena pro odezvu v reálném čase, špatně nakonfigurované směrování událostí nebo přetížené brokery mohou zavést latenci.

Osvědčené postupy architektury řízené událostmi

• Standardizace schémat a smluv o událostech: Používejte registry schémat a vynucujte validaci, abyste zachovali konzistenci mezi výrobci a spotřebiteli.
• Implementujte silné řízení: Definujte jasné zásady pro vlastnictví událostí, zabezpečení a dodržování předpisů. Využívejte nástroje pro audit a řízení přístupu.
• Zlepšení pozorovatelnosti: Nasazení monitorovacích a sledovacích řešení pro sledování toků událostí, detekci anomálií a zjednodušení ladění.
• Návrh pro škálovatelnost a odolnost: Používejte funkce sítě událostí, jako je dynamické směrování a jemné filtrování pro optimalizaci výkonu a tolerance poruch.
• Automatizujte pomocí umělé inteligence a informací o událostech: Začleňte analýzy a automatizaci založené na umělé inteligenci, abyste mohli předvídat problémy, optimalizovat směrování a zlepšovat rozhodování v reálném čase.

Charakteristiky architektury řízené událostmi

Architektura řízená událostmi se ve svém jádru opírá o několik definujících charakteristik, díky nimž je ideální pro distribuované, hybridní a multicloudové prostředí.

• Asynchronní komunikace: Základní charakteristika architektury řízené událostmi. Místo toho, aby aplikace čekaly na přímou odpověď jako v tradičních modelech řízených žádostmi, publikují události a pokračují v bezodkladném provozu. Tento styl neblokování umožňuje interakce v reálném čase napříč distribuovanými systémy a zlepšuje odezvu i při silném zatížení.
• Volné spojení: Aplikace nepotřebují znát vzájemnou dostupnost, strukturu API nebo interní logiku; jednoduše komunikují prostřednictvím událostí směrovaných zprostředkovatelem událostí nebo sítí událostí. Tím, že zajistí, aby výrobci a spotřebitelé událostí fungovali nezávisle, mohou týmy přidávat, aktualizovat nebo nahrazovat služby, aniž by došlo k narušení širšího systému, zvýšení agility a tolerance chyb.
• Nezávislé škálování: Vzhledem k tomu, že komponenty jsou odděleny, mohou jednotlivé služby škálovat nahoru nebo dolů na základě poptávky – bez nutnosti změn v předřazených nebo následných aplikacích. Společnost SAP to zdůrazňuje jako základní přínos integrace řízené událostmi, zejména v hybridních a multicloudových prostředích, kde je třeba efektivně řídit špičková zatížení a distribuovaná pracovní zatížení.

Díky těmto charakteristikám je architektura řízená událostmi výkonným přístupem pro budování systémů, které jsou v reálném čase, odolné, přizpůsobivé a připravené k růstu – ať už podporujete mikroslužby, integrujete cloudové prostředí nebo umožníte aplikace podnikových procesů řízené událostmi.

Časté otázky