Architektura sterowana zdarzeniami (EDA) to sposób budowania oprogramowania, w którym części systemu komunikują się, ogłaszając, że coś się wydarzyło, zamiast wywoływać się nawzajem bezpośrednio. Jeden komponent publikuje zdarzenie, na przykład „faktura opłacona” lub „umowa podpisana”. Każdy inny komponent, którego to dotyczy, na nie reaguje. Żadna ze stron nie musi wiedzieć o istnieniu drugiej.

Dla firmy SaaS ma to znaczenie znacznie szersze niż tylko dla inżynierii. Ta sama idea stoi za czystym przekazywaniem danych z CRM do finansów, niezawodną automatyzacją i agentami AI działającymi na aktualnych danych. Ten przewodnik wyjaśnia, jak działa EDA, czym magistrala zdarzeń różni się od kolejki, jak uniknąć typowych błędów oraz gdzie to podejście pasuje, a gdzie nie.

W skrócie

Spis treści

Czym jest architektura sterowana zdarzeniami

Wytyczne architektoniczne Microsoftu opisują ten styl jako producentów zdarzeń, którzy generują strumień zdarzeń, konsumentów zdarzeń, którzy ich nasłuchują, oraz kanały zdarzeń, które przenoszą zdarzenia od jednych do drugich. Ten trzyczęściowy model to cała idea. Cała reszta to szczegóły dotyczące tego, jak niezawodnie i jak szybko działa kanał.

Przeciwieństwem jest model żądanie/odpowiedź. W projekcie opartym na żądaniach i odpowiedziach Twój serwis rozliczeń wywołuje CRM i czeka na odpowiedź. Jeśli CRM działa wolno lub nie działa, rozliczenia stoją. W projekcie sterowanym zdarzeniami serwis rozliczeń publikuje „płatność otrzymana” i idzie dalej. CRM, raport przychodów i pulpit customer success odbierają to zdarzenie, gdy są gotowe.

Wynikają z tego dwie właściwości:

Co jest zdarzeniem

Zdarzenie to stwierdzenie faktu w czasie przeszłym. Red Hat opisuje je jako niezmienny zapis tego, że coś się wydarzyło, często ze znacznikiem czasu, który zachowuje kolejność względem systemu, który je wytworzył. Zdarzenia nie edytuje się po fakcie. Jeśli coś się zmieni, zmianę rejestruje nowe zdarzenie.

AWS zauważa, że zdarzenia mogą być zmianą stanu lub aktualizacją i mogą albo przenosić stan, albo być identyfikatorami. Dwa przykłady:

Styl Przykład Co otrzymuje konsument
Zdarzenie przenoszące stan Subskrypcja podniesiona do wyższego planu, z planem, ceną, datą wejścia w życie i identyfikatorem konta Wszystko, co potrzebne do działania bez drugiego zapytania
Zdarzenie jako identyfikator Zamówienie wysłane, wyłącznie z identyfikatorem zamówienia Sygnał. Konsument pobiera szczegóły z systemu źródłowego

Pierwsze podejście jest wygodne, ale wiąże konsumentów z kształtem zdarzenia. Drugie utrzymuje małe zdarzenia, ale odsyła konsumentów z powrotem do systemu źródłowego, co rodzi pytanie, który system jest wiarygodnym źródłem. Wrócimy do tego poniżej, ponieważ właśnie z tym najczęściej mają problem stosy operacyjne w SaaS.

Polecenie nie jest zdarzeniem. „Wyślij fakturę” to instrukcja dla konkretnego odbiorcy. „Faktura wysłana” to fakt, na który może zareagować każdy. Mieszanie tych dwóch to częsty błąd projektowy, który po cichu odtwarza ścisłe powiązania, które chciano usunąć.

Jak działa system sterowany zdarzeniami, krok po kroku

Dokumentacja Google Cloud opisuje ten przepływ następująco: producenci generują zdarzenia, router lub broker przyjmuje je i filtruje, a następnie rozsyła do konsumentów na podstawie subskrypcji lub wyzwalaczy. W praktyce wygląda to tak:

  1. Coś się dzieje. Szansa sprzedaży w CRM zmienia status na „Closed Won”.
  2. Producent publikuje zdarzenie. Zdarzenie podaje fakt oraz rekord, którego dotyczy.
  3. Broker kieruje zdarzenie. Filtruje je i dostarcza każdemu subskrybentowi.
  4. Konsumenci reagują niezależnie. Dział finansów tworzy projekt faktury. Customer Success otwiera plan wdrożenia klienta. Proces provisioningu przygotowuje dostęp.
  5. Każdy konsument potwierdza odbiór. Broker wie, że zdarzenie zostało obsłużone, i może ponowić próbę, jeśli tak się nie stało.

IBM opisuje ten sam wzorzec jako publikowanie, przechwytywanie, przetwarzanie i przechowywanie zdarzeń i zwraca uwagę, że wartość zdarzenia może zmieniać się w czasie. Na zdarzenie „nowy lead” warto zareagować w ciągu kilku minut. Rok później przydaje się głównie do analizy.

Architektura sterowana zdarzeniami a mikroserwisy

Często traktuje się te pojęcia jako to samo. Tak nie jest. Mikroserwisy opisują, jak podzielić aplikację na małe, niezależnie wdrażane usługi. EDA opisuje, jak te usługi się komunikują. Mikroserwisy mogą wywoływać się nawzajem synchronicznie, a monolit może wewnętrznie publikować zdarzenia.

Oba podejścia dobrze ze sobą współpracują. Wytyczne Google zauważają, że mikroserwisy mogą reagować na zdarzenia asynchronicznie i muszą znać tylko format zdarzenia, a nie logikę biznesową innych usług. Ten wspólny format jest kontraktem. Wszystko, co za nim stoi, może się zmieniać.

Dokumentacja Microsoft opisuje typowy wzorzec jako mikroserwisy, które publikują zdarzenie, gdy dzieje się coś istotnego, a inne mikroserwisy je subskrybują.

Magistrala zdarzeń, kolejka i strumień

Te trzy pojęcia budzą najwięcej nieporozumień, a wybór między nimi zmienia sposób działania Twojego systemu.

Magistrala zdarzeń (publish/subscribe). Magistrala zdarzeń to mechanizm, w którym wydawcy ogłaszają zdarzenia, a subskrybenci je odbierają. Microsoft wyjaśnia, że można ją zaimplementować na infrastrukturze komunikatów, takiej jak kolejka lub magistrala usług obsługująca asynchroniczny model publish/subscribe. Kolejka może więc być jednym z elementów magistrali. Magistrala jest zamierzeniem. Kolejka to jeden ze sposobów jego realizacji.

Kolejka. Kolejka przechowuje komunikaty, dopóki nie pobierze ich worker. Każdy komunikat obsługuje zwykle jeden konsument. Kolejki sprawdzają się do rozdzielania pracy między workery i do absorbowania nagłych skoków obciążenia. Wytyczne Azure dotyczące integracji wymieniają kolejkowanie komunikatów, gdy backend jest niedostępny, jako jeden z powodów użycia brokera.

Strumień zdarzeń. Azure odróżnia publish/subscribe od streamingu. W modelu publish/subscribe po odebraniu zdarzenia nie jest ono przechowywane w trwałym dzienniku, więc nowi subskrybenci nie widzą wcześniejszych zdarzeń. W streamingu zdarzenia są zapisywane w dzienniku, który jest trwały i ściśle uporządkowany w obrębie partycji, a klienci czytają z dziennika, mogą dołączyć w dowolnym momencie i odtwarzać zdarzenia.

Kolejka Magistrala publish/subscribe Strumień zdarzeń
Dostarczanie Jeden konsument na komunikat Każdy subskrybent Dowolny czytelnik, od dowolnego punktu
Przeszłe zdarzenia Usuwane po przetworzeniu Niedostępne dla nowych subskrybentów Przechowywane i możliwe do odtworzenia
Typowe zastosowanie Rozdzielanie pracy, buforowanie Powiadamianie kilku systemów Historia, analityka, odbudowa stanu

Praktyczna zasada: jeśli kilka systemów ma zareagować na ten sam fakt, użyj publish/subscribe. Jeśli jeden worker ma wykonać zadanie, użyj kolejki. Jeśli potrzebujesz historii lub możliwości odbudowy systemu docelowego, użyj strumienia. Red Hat dodaje, że nie ma jednego rozwiązania pasującego do wszystkiego, więc technologię należy dobierać do typu zdarzenia.

Czy Kafka to architektura sterowana zdarzeniami?

Nie. Kafka to technologia, za pomocą której można taką architekturę zbudować. Dokumentacja Apache Kafka opisuje ją jako platformę do streamingu zdarzeń: przechwytywania zdarzeń w czasie rzeczywistym, trwałego ich przechowywania, przetwarzania i kierowania do innych systemów. W powyższej tabeli jest to więc strumień zdarzeń.

Architektura to zbiór decyzji projektowych: czym są zdarzenia, kto jest ich właścicielem, jak izolowani są konsumenci, co dzieje się w razie awarii. Te decyzje można podjąć i uruchomić na zarządzanej magistrali w chmurze, w usłudze kolejek lub w Kafce. Można też używać Kafki i mimo to mieć silnie sprzężony system, jeśli każda usługa zależy od wewnętrznych zdarzeń innej usługi. Narzędzie wybierz po zdefiniowaniu zdarzeń i wolumenu, którego faktycznie się spodziewasz.

Integracja i automatyzacja sterowane zdarzeniami

Tu EDA staje się istotna dla liderów operacyjnych, a nie tylko dla inżynierów.

Integracja

Większość firm SaaS łączy dane z CRM, rozliczeń, wsparcia i produktu za pomocą synchronizacji punkt-punkt. Każde nowe narzędzie dodaje kolejne połączenie do utrzymania. Azure zaleca komunikację asynchroniczną przez broker komunikatów zamiast bezpośrednich wywołań synchronicznych z czterech powodów: rozdzielenia aplikacji, rozsyłania do wielu konsumentów, niezawodnego śledzenia długotrwałych przepływów pracy oraz kolejkowania komunikatów, gdy backend jest niedostępny.

Korzyść widać, gdy dodajesz system. W usłudze publish/subscribe nowych subskrybentów można dodawać bez aktualizowania nadawcy. Dodanie nowego narzędzia analitycznego nie wymaga zmian w Twoim CRM.

Automatyzacja

Automatyzacja oparta na zdarzeniach oznacza, że proces biznesowy rusza, ponieważ coś się wydarzyło, a nie dlatego, że ktoś kliknął przycisk albo uruchomiło się nocne zadanie. Przewodnik po przepływach ServiceNow podaje praktyczną metodę: określ wyzwalacz, zaplanuj logikę, wybierz akcje i wskaż logikę nadającą się do ponownego użycia. Zaleca też, by przepływy były wąsko ukierunkowane, a każda akcja miała jeden czasownik.

Gdy proces obejmuje kilka usług, Microsoft zauważa, że systemy oparte na zdarzeniach zwykle stosują wzorce choreografii i orkiestracji sag do koordynowania przepływu. W choreografii każda usługa reaguje na zdarzenia i emituje własne. W orkiestracji koordynator mówi każdemu krokowi, co ma zrobić, i śledzi cały proces. W pierwszym projekcie przepływ zorkiestrowany jest zwykle łatwiejszy do czytania i audytu.

Prosty przykład z branży SaaS:

Dobre praktyki i typowe wyzwania

Azure wymienia główne wyzwania: spójność ostateczna, asynchroniczna obsługa błędów, utrata danych, obserwowalność i testowanie, zbyt wiele lub zbyt silnie skonsolidowanych zdarzeń oraz ewolucja schematów. Do każdego z nich istnieje odpowiednia praktyka.

  1. Zaplanuj spójność ostateczną. Systemy będą się na krótko różnić. Zdecyduj, który system jest wiarygodnym źródłem dla każdego faktu, a pozostałe niech za nim podążają.
  2. Dodaj dedykowaną obsługę błędów. Zdarzenia zakończone niepowodzeniem potrzebują miejsca, do którego trafią, i kogoś, kto je sprawdzi.
  3. Przechowuj zdarzenia do czasu potwierdzenia odbioru. Chroni to przed utratą danych, gdy odbiorca jest niedostępny.
  4. Używaj identyfikatorów korelacji. Jeden identyfikator przenoszony przez każdy krok pozwala prześledzić pojedyncze działanie klienta w różnych systemach.
  5. Zadbaj o właściwą szczegółowość zdarzeń. Jedno zdarzenie na każdą zmianę pola tworzy szum. Jedno gigantyczne zdarzenie dla wszystkiego na nowo tworzy silne powiązania.
  6. Wersjonuj schematy od początku. Formaty zdarzeń będą się zmieniać. Ustal, jak to robić, zanim będziesz mieć dwudziestu odbiorców.

Do tego dodalibyśmy trzy nawyki operacyjne: nazywaj zdarzenia w czasie przeszłym, przypisz każdemu typowi zdarzenia jednego właściciela i zapisz, którzy odbiorcy od niego zależą.

Gdzie projektowanie sterowane zdarzeniami nie pasuje

EDA nie jest odpowiedzią na każdy problem. Zanim się zdecydujesz, jasno określ jej ograniczenia:

Ta sama logika dotyczy AI. Asystent AI, który odczytuje dane z Twoich systemów i na nich działa, jest zarówno odbiorcą, jak i producentem zdarzeń. Jeśli czyta niespójne dane lub działa bez granic uprawnień, to jest to szybszy sposób na popełnianie błędów.

Gdzie spotyka się to z agentami AI i zgodnością z przepisami

Agenci AI, którzy pobierają dane (pytają, raportują, wyszukują) i wysyłają dane (aktualizują rekord, uruchamiają proces, przydzielają dostęp), zachowują się jak uczestnicy systemu opartego na zdarzeniach. Potrzebują zaufanego źródła do odczytu, jasnego zestawu dozwolonych działań, zatwierdzenia wrażliwych kroków i zapisu tego, co zrobili. Dziennik zdarzeń jest naturalnym miejscem na taki zapis.

Operator przeglądający dziennik zdarzeń agenta AI

W przypadku europejskich firm GDPR, NIS2 i EU AI Act wpływają na sposób projektowania takich systemów. Ogólnie dotyczą one tego, jakie dane osobowe przepływają przez zdarzenia, jak zorganizowane są bezpieczeństwo i obsługa incydentów oraz jak zarządza się systemami AI i jak się je dokumentuje. Traktuj je jako założenia projektowe od samego początku i zasięgnij porady prawnej u radcy w sprawie ich zastosowania w Twoim konkretnym przypadku. Sam wybór architektury nie sprawia, że system jest zgodny z przepisami.

Nasz punkt widzenia

Większość firm SaaS, z którymi rozmawiamy, nie ma problemu ze zdarzeniami. Mają problem z odpowiedzialnością. Kilka zespołów korzysta z AI, kilka narzędzi przechowuje własną wersję klienta, a nikt nie odpowiada za to, która wersja jest właściwa.

Dlatego pracujemy w ustalonej kolejności. Najpierw fundament danych: dane z CRM i systemu finansowego jako uzgodnione źródło prawdy. Potem warstwa AI, łącząca te dane z asystentem, z którego Twój zespół już korzysta. Następnie agenci działowi dla finansów, sprzedaży i Customer Success. Zdarzenia przydają się we wszystkich trzech warstwach, ale pomagają dopiero wtedy, gdy fakty, które niosą, zostały uzgodnione.

Wdrażamy też jeden proces naraz, zaczynając od najkosztowniejszego. Proces odnowienia lub przekazanie od faktury do płatności to lepszy pierwszy projekt oparty na zdarzeniach niż przebudowa całej firmy. Widzisz efekt, Twoi ludzie uczą się wzorca, a kolejny proces jest tańszy.

Ponieważ nie tylko projektujemy systemy, ale też prowadzimy operacje, dbamy o te mniej efektowne elementy: uprawnienia, zatwierdzenia, ścieżki audytu oraz przekazanie, w którym to Ty jesteś właścicielem kodu, dokumentacji i infrastruktury.

Claus Nielsen

Jak zacząć we własnej firmie

Nie musisz najpierw wybierać brokera. Zacznij od tych pytań:

  1. Który proces kosztuje Cię najwięcej w postaci pracy ręcznej, opóźnień lub błędów?
  2. Jakie są dwa lub trzy zdarzenia, które go uruchamiają (na przykład zamknięta transakcja, zaległa faktura, zbliżające się odnowienie)?
  3. Który system jest źródłem prawdy dla danych w tych zdarzeniach?
  4. Kto jest właścicielem każdej definicji zdarzenia?
  5. Które kroki wymagają zatwierdzenia przez człowieka?

Jeśli nie potrafisz odpowiedzieć na trzecie pytanie, najpierw potrzebny jest fundament danych. Jeśli potrafisz, mały pilotaż na jednym procesie pokaże, czy podejście oparte na zdarzeniach się opłaca.

Jak możemy pomóc

Jeśli Twój zespół korzysta z AI, ale nikt za nią nie odpowiada, możemy pomóc Ci zdecydować, gdzie to się opłaca, i zbudować rozwiązanie we właściwej kolejności. Nasz AI Readiness Assessment jest dostępny od €4,500 i analizuje Twoje dane, systemy i procesy, zanim cokolwiek zostanie zbudowane. Jeśli potrzebujesz stałego przywództwa, abonament Fractional Chief AI Officer zaczyna się od €1,500 miesięcznie.

Wdrożenia wyceniamy na 30% zmierzonej i potwierdzonej oszczędności w pierwszym roku lub według stałej ceny uzgodnionej przed rozpoczęciem prac. Możesz też umówić bezpłatną 30-minutową rozmowę wstępną przez naszą stronę. Nasi agenci AI dla działów finansów, sprzedaży i Customer Success pokazują, jak wygląda warstwa działowa, gdy fundament jest już gotowy.

FAQ

Czym jest architektura zdarzeniowa w prostych słowach?

To podejście do projektowania, w którym komponenty oprogramowania ogłaszają, że coś się wydarzyło, a inne komponenty na to reagują. Nadawca nie wie, kto nasłuchuje. Dzięki temu można dodawać lub zmieniać systemy bez przepisywania tych, które generują zdarzenia.

Jaka jest różnica między magistralą zdarzeń a kolejką komunikatów?

Kolejka zwykle dostarcza każdy komunikat do jednego procesu roboczego. Magistrala zdarzeń dostarcza każde zdarzenie do każdego subskrybenta. Magistralę można zbudować na infrastrukturze kolejek, więc różnica tkwi w zamyśle i wzorcu dostarczania, a nie zawsze w produkcie.

Czy architektura zdarzeniowa to to samo co mikroserwisy?

Nie. Mikroserwisy dotyczą tego, jak aplikacja jest podzielona na usługi. Architektura zdarzeniowa dotyczy tego, jak komunikują się jej części. Często stosuje się je razem, ale każde z nich może istnieć bez drugiego.

Kiedy firma SaaS powinna stosować automatyzację opartą na zdarzeniach?

Warto po nią sięgnąć, gdy proces biznesowy ma się rozpoczynać od faktu, takiego jak zamknięta transakcja lub zbliżające się odnowienie, a zareagować musi kilka zespołów lub systemów. Zacznij od jednego kosztownego procesu i najpierw upewnij się, że dane źródłowe zostały uzgodnione.

Źródła