Czym jest architektura oparta na zdarzeniach?
Architektura sterowana zdarzeniami (EDA) to model integracji, który wykrywa ważne „zdarzenia” w biznesie – takie jak transakcja lub porzucony koszyk zakupów – i działa na nich w czasie rzeczywistym.
Przegląd architektury opartej na zdarzeniach
Prawie każde wydarzenie w biznesie jest czasochłonne. Gdy klient dokonuje zakupu online, czujnik oznacza zbliżające się nieprawidłowe działanie, spadek ceny akcji lub naruszenie bezpieczeństwa – należy podjąć natychmiastowe działania. Tutaj pojawia się architektura sterowana zdarzeniami (EDA). EDA może tworzyć, wykrywać i reagować na wydarzenia w miarę ich rozwoju, pomagając firmom poprawić wszystko, od doświadczeń klienta po wydajność operacyjną i elastyczność.
Co to jest zdarzenie?
Po pierwsze, niektóre podstawy. Zdarzenie to każda czynność lub zmiana stanu, która jest ważna dla firmy. Na przykład, gdy ktoś przesunie kartę kredytową, zaewidencjonuje lot lub zresetuje hasło – lub gdy zapasy są aktualizowane w magazynie. Wydarzenia odbywają się cały czas, w każdej organizacji, w każdej branży. Firmy stają się „oparte na zdarzeniach”, gdy mogą rejestrować zdarzenia i reagować na nie w miarę ich występowania.
Czym jest architektura oparta na zdarzeniach?
Architektura sterowana zdarzeniami (EDA) to model integracji stworzony w celu publikowania, rejestrowania, przetwarzania i reagowania na zdarzenia w systemach rozproszonych w czasie rzeczywistym. Gdy zdarzenie wystąpi w jednej aplikacji, wiadomość jest automatycznie wysyłana do wszystkich innych aplikacji, które muszą o nim wiedzieć, aby mogły na nim działać z kolei.
Architektury oparte na zdarzeniach są rozłączone – co oznacza, że aplikacje nie muszą być świadome siebie nawzajem, aby dzielić się informacjami i wykonywać zadania. Informacje o zdarzeniach lub komunikaty mogą przepływać swobodnie i automatycznie między aplikacjami. W rezultacie model EDA jest znacznie szybszy niż tradycyjny model zapytań/odpowiedzi, w którym jedna aplikacja musi poprosić o konkretne informacje, których potrzebuje, i czekać na odpowiedź przed przejściem do następnego zadania. Również ze względu na oddzielony od produkcji charakter EAO, są one powszechnie uważane za najlepszą praktykę w zakresie komunikacji mikrousług.
Jak działa EDA?
W architekturze sterowanej zdarzeniami aplikacje działają jako producenci zdarzeń (aplikacje wytwarzające lub rejestrujące zdarzenia) lub odbiorcy zdarzeń (aplikacje, które przetwarzają zdarzenia i działają na ich podstawie). Producenci przesyłają zdarzenia do konsumentów za pośrednictwem pośrednika, czyli oprogramowania pośredniczącego zorientowanego na wiadomości, w czasie rzeczywistym. Następnie odbiorcy końcowi mogą przetwarzać zdarzenie i wyzwalać inne czynności, procesy workflow lub własne zdarzenia.
W bardzo prostej architekturze – kiedy jest jeden producent i jeden konsument, którzy są w bezpośredniej komunikacji ze sobą – brokerzy mogą być opcjonalni. Jednak w większości przedsiębiorstw istnieje wiele źródeł wysyłających wydarzenia do wielu konsumentów, więc potrzebny jest broker, a nawet sieć brokerów (znana również jako „siatka zdarzeń”). Gdy wykorzystywany jest broker lub siatka zdarzeń, tworzy to „luźne sprzężenie” aplikacji.
Wzorce architektury oparte na zdarzeniach
Istnieją dwa główne wzorce przesyłania zdarzeń w architekturze opartej na zdarzeniach: publikowanie/subskrybowanie i przesyłanie strumieniowe zdarzeń.
Publikuj/subskrybuj (czyli „pub/sub”) – dzięki pubie/sub konsumenci wydarzenia subskrybują wiadomości i kanały publikowane przez producentów wydarzeń. Po opublikowaniu zdarzenia jest ono wysyłane bezpośrednio do wszystkich subskrybentów za pośrednictwem brokera. Aby uniknąć duplikacji, zdarzenia nie mogą być ponownie odtwarzane lub dostępne po wykorzystaniu – są one usuwane przez brokera.
Strumieniowanie zdarzeń – dzięki strumieniowi zdarzeń producenci publikują całe strumienie zdarzeń do brokera. Konsumenci subskrybują strumień i mogą odczytywać go z dowolnej części, wykorzystując tylko zdarzenia, które są dla nich istotne. Dzięki temu wzorowi zdarzenia są zachowywane przez brokera nawet po ich zużyciu.
3 podejścia do przetwarzania zdarzeń
Istnieją trzy różne podejścia do przetwarzania zdarzeń po dotarciu do konsumenta: proste przetwarzanie zdarzeń, złożone przetwarzanie zdarzeń i przetwarzanie strumienia zdarzeń.
- Proste przetwarzanie zdarzenia: Konsumenci przetwarzają każde zdarzenie w momencie jego otrzymania.
- Złożone przetwarzanie zdarzeń: Konsumenci przetwarzają serię zdarzeń w celu wykrycia wzorców i wykonania czynności na podstawie wyniku.
- Przetwarzanie strumieni zdarzeń: Konsumenci przetwarzają i działają na stałym przepływie danych (danych w ruchu) w czasie rzeczywistym za pomocą platformy przesyłania strumieniowego danych.
Firmy wybierają swoje podejście do przetwarzania zdarzeń na podstawie indywidualnych potrzeb i przypadków użycia.
Przypadki użycia architektury oparte na zdarzeniach i przykłady
Istnieje wiele różnych zastosowań architektury opartej na zdarzeniach w każdej branży — od bankowości po handel detaliczny. Oto przykład z branży restauracyjnej:
Student uczelni składa zamówienie na pizzę za pośrednictwem aplikacji do dostarczania żywności, takiej jak Uber Eats. Aplikacja rejestruje jego podstawowe informacje (imię i nazwisko, adres, informacje o płatności i zamówienie) i publikuje wydarzenie „pizza order”.
Restauracja pizza subskrybuje wydarzenie, realizuje zamówienie i publikuje własne wydarzenie „gotowe do zamówienia” z powrotem do usługi dostawy żywności
Następnie usługa przydziela kierowcę dostawy, planuje ETA i ostrzega klienta, że jego koło jest w drodze
Przykład EDA z handlu elektronicznego:
Kupujący online wprowadza dane swojej karty kredytowej na stronie e-commerce, która publikuje zdarzenie „płatność przesłana”
System płatności subskrybuje zdarzenie, przetwarza płatność i wydaje własne zdarzenie „płatności przetworzone”, wskazując na powodzenie lub niepowodzenie – i kieruje je z powrotem do iu strony internetowej
Interfejs użytkownika przedstawia klientowi status płatności i monituje o kolejne kroki
Inne przykłady EDA obejmują:
Gdy kupujący online kliknie produkt, a system odpowie, generując rekomendacje produktów na podstawie podobnych pozycji
Gdy odbiorca zdeponuje czek w banku, a system automatycznie zaksięguje depozyt na swoim koncie
Gdy sprzedawca detaliczny przeszukuje globalne transakcje pod kątem oszustw i zaznacza wszelkie podejrzane zakupy do firmy obsługującej karty kredytowe
Gdy producent monitoruje przesyłanie strumieniowe danych IoT ze swojego urządzenia i jest powiadamiany o wszelkich potencjalnych problemach z konserwacją lub awariach
Korzyści płynące z architektury opartej na zdarzeniach
Istnieje wiele korzyści płynących z architektury opartej na zdarzeniach. 3 pierwsze to:
- Przepływy pracy w czasie rzeczywistym i szybkość reakcji. EDA może monitorować i szybko reagować na zdarzenia w miarę ich występowania, często za pomocą zrobotyzowanej automatyzacji procesów (RPA), aby przyspieszyć przepływy pracy i uruchomić kolejne kroki w czasie rzeczywistym. Jest to szczególnie istotne w okresach szczytowego popytu – na przykład podczas dużych wydarzeń sprzedażowych lub świąt. Taka responsywność może być również stosowana na co dzień (tj. nieszczytowe) przepływy pracy, usprawniające wszystko, od automatyzacji łańcucha dostaw po wykrywanie oszustw.
- Asynchroniczna wymiana wiadomości. Aplikacje w EDA komunikują się asynchronicznie – czyli producenci publikują wiadomości o zdarzeniach bez czekania, aż konsumenci je otrzymają. Nie tylko pozwala to aplikacjom przejść do innych zadań bez czekania, ale upraszcza integrację.
- Sprzężenie rozruchowe i luźne. Aplikacje w EDA są odłączone lub luźno sprzężone i nie są zależne od wzajemnej dostępności. Można je aktualizować, testować i wdrażać niezależnie. Mogą również zawieść niezależnie – dlatego architektura jest trwalsza i trwalsza niż tradycyjne modele. Oddzielenie płatności od produkcji ułatwia również dodawanie w razie potrzeby dodatkowych wydawców i konsumentów, eliminując konieczność przepisywania kodu za każdym razem, gdy następuje zmiana.
Podsumowanie
Siatka zdarzeń oferuje opcje wdrożenia w różnych hiperskalerach i w środowiskach chmury prywatnej. Można ją skonfigurować tak, aby tworzyła rozproszoną siatkę brokerów zdarzeń wdrażanych w środowiskach w chmurach prywatnych lub publicznych. Siatka zdarzeń oferuje pełny zestaw usług zdarzeniowych, w tym przesyłanie strumieniowe zdarzeń, zarządzanie zdarzeniami i monitorowanie, a także zaawansowane funkcje, takie jak dynamiczne przekazywanie wiadomości i precyzyjne filtrowanie.
Poznaj funkcje sap event mesh
Korzystaj z aplikacji dzięki architekturze opartej na zdarzeniach pakietu SAP Integration Suite.
Pomysłów nie znajdziesz nigdzie indziej
Zarejestruj się, aby uzyskać dawkę business intelligence dostarczoną bezpośrednio do skrzynki odbiorczej.