Architektura mikroserwisów znacznie usprawnia zarządzanie aplikacją zespołom, które są za nią odpowiedzialne w firmie. Architektura sterowana zdarzeniami (event-driven architecture, EDA) stanowi wzmocnienie odporności systemu informatycznego. Wielu z was może rozważać migrację do EDA, ale nie każdy na niej skorzysta. Aby odróżnić pragnienie od potrzeby i sprawdzić, czy jest się gotowym do przejścia na architekturę sterowaną zdarzeniami, najlepiej zasięgnąć porady i wsparcia. W naszym artykule przedstawiamy specyfikę EDA, którą koniecznie trzeba znać.  

 

Co to jest architektura sterowana zdarzeniami? 

Architektura sterowana zdarzeniami (EDA) jest architekturą zorientowaną na zdarzenia, które są trzonem jej działania. Zdarzenie należy rozumieć jako coś, co wynika ze zmiany stanu w aplikacji i jest najczęściej generowane przez użytkowników aplikacji, zespół zarządzający lub wewnętrznie przez samą aplikację.


Specyfiką tej architektury jest oparcie jej na asynchronicznym systemie komunikacji, który pozwala m.in. na słabe sprzężenie. W ten sposób wiadomości (zdarzenia) mogą być wysyłane jednocześnie, bez potrzeby natychmiastowej odpowiedzi lub przetwarzania. Ta asynchroniczność, wzmocniona zasadą „Fire and Forget”, która polega na tym, że bez względu na swój charakter i objętość zdarzenie zostaje wysłane i zapomniane, sprawia, że zdarzenie nigdy nie blokuje się podczas przetwarzania. Natomiast komunikacja synchroniczna wymaga bezpośredniej i natychmiastowej odpowiedzi na każde zgłoszone żądanie.

 

Kolejkowanie komunikatów jest również istotnym elementem działania architektury sterowanej zdarzeniami. Komponent ten umożliwia komunikację między mikroserwisami poprzez umieszczenie każdego zdarzenia w kolejce. Następnie oczekujące zdarzenia zostaną podzielone, aby ułatwić ich przetwarzanie.

 
Producent tworzy zdarzenie i wysyła je. Jest ono bezpośrednio zintegrowane z kolejką, a następnie dystrybuowane do każdego z mikroserwisów subskrybowanych do kolejki (jeśli są subskrybowane, są zainteresowane przetwarzaniem tego typu zdarzeń). Ci abonenci zwani są konsumentami. Następnie broker (pośredniczący agent komunikatu) zarządza kolejką i dystrybucją komunikatów, umożliwiając w ten sposób płynność i asynchroniczność charakterystyczne dla EDA.

 
Kafka i RabbitMQ to najbardziej znane brokery w tej dziedzinie, pierwszy ze względu na sprawdzoną wydajność i solidność, drugi ze względu na łatwość użycia.


Dla optymalnego wykorzystania architektury sterowanej zdarzeniami istnieje zestaw wzorców projektowych, które gwarantują jej poprawne działanie. Oto niektóre z nich:
 

 

  • CQRS (Command and Query Responsibility Segregation). implementacja tego wzorca projektowego umożliwia oddzielenie żądań odczytu od żądań zapisu. Dane są przechowywane w dwóch różnych bazach danych, aby zoptymalizować działanie aplikacji, ale także aby rejestrować każdą akcję (wszystkie zdarzenia systemowe są rejestrowane), by w razie potrzeby można było je odtworzyć;
  • Event Sourcing: każde nowe zdarzenie jest zapisywane w bazie danych, co pozwala na zestawienie wszystkich zdarzeń. Na przykład w aplikacji bankowej, jeśli użytkownik dokonuje przelewu, do bazy danych jest dodawany nowy wpis; jest to przelew, więc wpis jest operacją odejmowania (–200 EUR). Dzięki Event Sourcing „kompilacja” pomiędzy aktualnym saldem a przelewem zapewnia, że żadna informacja nie zostanie utracona. Cała sekwencja zdarzeń prowadzących do uzyskania aktualnego salda jest rejestrowana, a wszystkie zdarzenia można odtworzyć. Oczywiście oznacza to istotny problem z przechowywaniem - używana baza danych może szybko ulec przepełnieniu;
  • Event Notification odpowiadające zasadzie „Fire and Forget”. Nadawca wysyła wiadomość, nie oczekując odpowiedzi.

 

Architektura sterowana zdarzeniami odpowiada dziś na rosnące zapotrzebowanie aplikacji na wymianę dużych ilości danych. Złożona implementacja tej architektury może wymagać wsparcia eksperckiego dla firm, które sobie tego życzą.

 

Jak broker ułatwia działanie architektury sterowanej zdarzeniami? 

Implementacja architektury sterowanej zdarzeniami wymaga zastosowania brokera. Aby przedsiębiorstwo mogło w pełni korzystać z efektywności tego systemu, konieczne jest:

  

  • opanowanie wszystkich funkcji brokera;
  • upewnienie się, że broker jest integralną częścią implementacji EDA i że umożliwia zarządzanie kolejką w celu ułatwienia przekazywania zdarzeń.

W procesie tym broker otrzymuje zdarzenie od producenta i przekazuje je w wymianie. W przypadku oprogramowania takiego jak RabbitMQ może to przybierać wiele form:

  • Direct: komunikat jest wysyłany do kolejki za pośrednictwem kluczy asocjacyjnych w celu przesłania do konsumenta;
  • Topic: komunikat jest przetwarzany przez wzorzec routingu tak, aby trafił do kolejek spełniających określone warunki;
  • Fanout: komunikat zostanie wysłany do wszystkich kolejek.

W zależności od wybranego brokera można ustawić czas retencji komunikatu (godzina, kilka lat, nieskończoność itp.) za pomocą narzędzia administracyjnego brokera, przy czym zaletą jest możliwość odtworzenia zdarzeń przez wcześniej ustawiony czas.
 
Celem brokera jest ułatwienie wymiany zdarzeń i uniknięcie blokad pomiędzy mikroserwisami. Nie tylko mikroserwisy wymagają szybkiego rozpowszechniania, ale dotyczy to bardzo dużych ilości danych (miliony). Procesy zapewniane przez brokery prowadzą do wysokiego poziomu wydajności i niezawodności.

 

Jakie są wady architektury sterowanej zdarzeniami?

Wdrożenie architektury sterowanej zdarzeniami nie jest proste, a na drodze do jej właściwego wykorzystania stoją przeszkody, które mogą sprawić, że zadanie to będzie mało przyjemne dla firm, które zdecydują się na ten model.


Niezbędne jest zatem dokładne poznanie grupy odbiorców, do których skierowana jest aplikacja, oraz potrzeb, jakie wiążą się z ich zachowaniami. Bez tego złożoność przejścia na EDA nie uzasadnia migracji. Następnie należy ocenić zasoby infrastruktury: czy przejście na architekturę sterowaną zdarzeniami jest technicznie wykonalne?


Broker jest również kluczowym elementem w skutecznym zarządzaniu EDA. Niezależnie od tego, czy będzie to Kafka, RabbitMQ czy inne rozwiązanie, odpowiedzialne zespoły będą musiały opanować system zarządzania kolejkami.


Następnie należy wziąć pod uwagę i ocenić ilość przechowywanych danych, o czym już wspominaliśmy – przechowywanie w chmurze stanowi znaczny koszt, który jednak trudno zmniejszyć w przypadku EDA. Zapisane zdarzenia mogą zajmować dużo miejsca. Ponieważ jednak zdarzenia te będą prawdopodobnie odtwarzane w celu analizy i debugowania, należy je zachować.


Wreszcie, rozłączenie zdarzenia obsługiwanego przez brokera w kolejce zwiększa stopień złożoności. Chociaż poprawia i przyspiesza komunikację asynchroniczną, utrudnia debugowanie i konserwację.


To wszystko są kwestie, z którymi firma będzie się musiała zmierzyć, myśląc o architekturze sterowanej zdarzeniami. 

 

 

Co architektura sterowana zdarzeniami może wnieść dla Twojej firmy?

Firmy mają dziś coraz większe zapotrzebowanie na architektury takie jak EDA, ponieważ większość z nich prowadzi działalność, która wymaga zarządzania coraz większą ilością danych w coraz krótszym czasie. EDA zaspokaja tę potrzebę (jeśli uda się pokonać przeszkody wymienione powyżej).


Zastosowanie architektury sterowanej zdarzeniami zapewnia skalowalność aplikacji i poprawia odporność firm. Mogą one same debugować swoją aplikację, a nawet przewidzieć pogarszającą się sytuację. Mogą szybko ograniczyć błąd do danego mikroserwisu i w ten sposób zachować dostępność i responsywność swojej aplikacji (niedostępny staje się tylko wadliwy mikroserwis). Ta odporność zapewnia im prawdziwą autonomię. 
  
Architektura sterowana zdarzeniami poprawia również solidność przedsiębiorstwa, ponieważ może ono obsługwać jednocześnie znacznie więcej żądań, co oznacza większe ilości informacji. Dzięki architekturze sterowanej zdarzeniami czas odpowiedzi jest krótszy, a dzięki kolejkowaniu komunikatów Twoja firma nie traci żadnych danych.


Czy jesteś gotowy, aby przejść na architekturę sterowaną zdarzeniami? W Alter Solutions zapewniamy doradztwo i wsparcie niezbędne do powodzenia Twoich projektów transformacji cyfrowej. Nasza firma doradcza oferuje audyty, których celem jest poprawa solidności i odporności systemów, nie zapominając przy tym o niezbędnej identyfikacji czynników technicznych, potrzeb dotyczących umiejętności i kontroli kosztów.


Dodatkowo posiadamy certyfikat PASSI, który jest gwarancją pewności w zakresie audytów bezpieczeństwa. Przyznana przez ANSSI (francuską Narodową Agencję Bezpieczeństwa Systemów Informatycznych) kwalifikacja pozwala nam wspierać naszych klientów w obliczu wyzwań związanych z cyberbezpieczeństwem. Podatności to trwałe zagrożenia dla normalnego funkcjonowania firmy. Komplementarność naszych kompetencji pozwala zachować równowagę w zakresie „złożoność – koszt – korzyść”.


Skorzystasz z bezproblemowego wsparcia dla optymalnego wdrożenia i zarządzania.
Udostępnij ten artykuł