Čo je Event-Driven Architecture?
Event-Driven Architecture je spôsob návrhu aplikácií, v ktorom jednotlivé komponenty komunikujú prostredníctvom udalostí (events).
Udalosť informuje systém, že sa niečo stalo. Môže ísť napríklad o:
- vytvorenie objednávky,
- dokončenie platby,
- registráciu používateľa,
- zmenu stavu objednávky,
- naskladnenie produktu.
Predstavme si e-shop. Po vytvorení objednávky systém vytvorí udalosť:
OrderCreated
Na túto udalosť môže reagovať platobná služba, sklad aj notifikačný systém. Služba, ktorá objednávku vytvorila, pritom nemusí každú z nich priamo volať.
Request-response vs. event-driven
Pri klasickom request-response modeli môže komunikácia vyzerať takto:
Order Service → Payment Service → Warehouse Service → Notification Service
Každá služba čaká na odpoveď predchádzajúcej. Ak je jedna z nich pomalá alebo nedostupná, môže to ovplyvniť celú požiadavku.
V event-driven modeli môže byť tok:
Order Service → OrderCreated
A následne:
OrderCreated → Payment Service
OrderCreated → Warehouse Service
OrderCreated → Notification Service
Rozdiel je v tom, že služba iba oznámi, čo sa stalo. Ostatné komponenty sa rozhodnú, či a ako na udalosť zareagujú.
Výsledkom je voľnejšie prepojenie medzi jednotlivými časťami systému.
Message queues a event brokers
Pri väčších aplikáciách sa udalosti často neposielajú priamo medzi službami. Medzi nimi môže fungovať message broker, ktorý prijíma a distribuuje správy.
Zjednodušene:
Producer → Message Broker → Consumers
Broker môže zabezpečiť napríklad doručovanie správ, ich dočasné uloženie, opakované spracovanie alebo distribúciu viacerým consumerom.
Často sa v tejto súvislosti stretávame s technológiami RabbitMQ a Apache Kafka.
RabbitMQ vs. Kafka
RabbitMQ je message broker vhodný najmä na klasické spracovanie správ, queues a background tasks. Môže byť užitočný napríklad pri spracovaní objednávok alebo generovaní dokumentov na pozadí.
Kafka je distribuovaná event streaming platforma navrhnutá na prácu s veľkým množstvom udalostí. Hodí sa napríklad tam, kde potrebujeme spracovávať veľké objemy dát a umožniť viacerým systémom pracovať s rovnakým tokom udalostí.
Nejde však o otázku, ktorá technológia je „lepšia“. Výber závisí od konkrétneho problému, objemu dát, požiadaviek na spracovanie a spôsobu škálovania.
Ako vyzerá event-driven objednávka?
Predstavme si jednoduchý e-shop:
- Vytvorenie objednávky
Order Service vytvorí objednávku a publikuje OrderCreated. - Platba
Payment Service zachytí udalosť a po úspešnom zaplatení vytvorí PaymentCompleted. - Sklad
Warehouse Service na udalosť zareaguje a aktualizuje stav zásob. - Notifikácia
Notification Service odošle zákazníkovi potvrdenie objednávky.
Výsledkom je reťazec:
OrderCreated → PaymentCompleted → InventoryUpdated → NotificationSent
Každá služba pritom rieši vlastnú úlohu a nie je pevne závislá od ostatných.
Čo ak jedna služba nefunguje?
Jednou z výhod event-driven architektúry je možnosť asynchrónneho spracovania.
Ak je napríklad Notification Service dočasne nedostupná, udalosť môže zostať uložená v message brokri a služba ju spracuje neskôr.
To však prináša aj nové výzvy. Vývojári musia riešiť napríklad duplicity udalostí, retry mechanizmy, poradie správ, monitoring alebo situácie, keď spracovanie zlyhá.
Kedy sa Event-Driven Architecture oplatí?
EDA môže byť vhodná najmä pre:
- e-commerce platformy,
- platobné a logistické systémy,
- IoT aplikácie,
- analytické platformy,
- real-time monitoring,
- notifikačné systémy,
- aplikácie s množstvom background procesov.
Výhodou môže byť jednoduchšie škálovanie jednotlivých komponentov. Ak napríklad Payment Service spracováva výrazne viac požiadaviek ako ostatné časti systému, môžeme škálovať práve ju.
Naopak, pri malej a jednoduchej aplikácii môže byť event-driven architektúra zbytočne komplikovaná. Prináša totiž ďalšie komponenty, ktoré treba monitorovať a spravovať.
Záver
Event-Driven Architecture umožňuje aplikáciám reagovať na udalosti bez toho, aby jednotlivé komponenty museli byť navzájom pevne prepojené. Vďaka tomu môže byť systém flexibilnejší, škálovateľnejší a odolnejší.
Nie každá aplikácia však potrebuje Kafka, RabbitMQ alebo komplexný event-driven systém. Najdôležitejšie je najskôr pochopiť, aký problém chceme vyriešiť, a až potom vybrať architektúru a technológie, ktoré tomu najlepšie zodpovedajú.