Korzyści z migracji do architektury sterowanej zdarzeniami

Dwie powszechne opcje tworzenia aplikacji to architektura na żądanie i oparta na zdarzeniach.

W architekturze żądanie-odpowiedź komponenty aplikacji komunikują się za pośrednictwem wywołań API. Klient wysyła żądanie i oczekuje odpowiedzi przed wykonaniem kolejnego zadania. W architekturze sterowanej zdarzeniami klient generuje zdarzenie i może natychmiast przejść do kolejnego zadania. W razie potrzeby różne części aplikacji reagują na zdarzenie.

Za pośrednictwem tego artykułu poznasz powody, dla których warto rozważyć przejście z architektury typu żądanie-odpowiedź na architekturę sterowaną zdarzeniami.

Wyzwania dotyczące architektury żądanie-odpowiedź

Rozpoczynając tworzenie nowej aplikacji, wielu programistów domyślnie stosuje architekturę żądanie-odpowiedź. Architektura żądanie-odpowiedź może ściśle integrować komponenty, a komponenty te komunikują się za pośrednictwem wywołań synchronicznych. Chociaż podejście żądanie-odpowiedź jest często łatwiejsze na początku, może stać się problematyczne, gdy aplikacja staje się coraz bardziej złożona.

W tym artykule autor opisuje przykładową aplikację e-commerce typu żądanie-odpowiedź i przedstawia wyzwania związane ze ściśle powiązanymi integracjami. Następnie przedstawi, jak budowanie tej samej aplikacji z architekturą sterowaną zdarzeniami może zapewnić większą skalowalność, odporność na błędy i szybkość programistów.

Jeśli dodasz usługę realizacji i usługę prognozowania, usługa zamówień ma więcej obowiązków i staje się bardziej złożona. Usługa zamówienia musi posiadać informacje o tym, jak wywołać API każdej usługi, od struktury wywołania API po semantykę ponawiania API. Jeśli istnieją jakiekolwiek niezgodne zmiany w interfejsach API, zespół obsługi zamówień musi je zaktualizować. System przekazuje skoki dużego ruchu do zależności usługi zamówień, która może nie mieć takich samych możliwości skalowania. Ponadto usługi zależne mogą przesyłać błędy z kopii zapasowej stosu do klienta.

Rozwiązywanie błędów i ponawianie prób

Teraz możesz dodać do aplikacji e-commerce nowe usługi niższego szczebla służące do realizacji i wysyłki zamówień.

Na „szczęśliwej ścieżce” wszystko działa zgodnie z oczekiwaniami: usługa zamówień uruchamia fakturowanie, systemy płatności i prognozowanie aktualizacji. Po rozliczeniu płatności uruchamia to realizację i pakowanie zamówienia, a następnie informuje firmę wysyłkową, aby zażądała informacji o śledzeniu.

Jeśli jednak centrum realizacji nie może znaleźć produktu, ponieważ nie ma go w magazynie, może być konieczne powiadomienie działu obsługi faktur, a następnie cofnięcie płatności lub dokonanie zwrotu pieniędzy. Jeśli realizacja się nie powiedzie, system, który uruchamia wysyłkę, również może zawieść. Prognozy również muszą zostać zaktualizowane, aby odzwierciedlić zmianę. Ten przepływ pracy naprawczej ma na celu zajęcie się jedną z wielu potencjalnych „nieszczęśliwych ścieżek”, które mogą wystąpić w tej aplikacji e-commerce opartej na interfejsie API.

Ścisła koordynacja między zespołami programistycznymi

W synchronicznie zintegrowanej aplikacji zespoły muszą koordynować wszelkie nowe usługi dodawane do aplikacji. Może to spowolnić zdolność każdego zespołu programistów do wydawania nowych funkcji. Wyobraź sobie, że Twój zespół pracuje nad usługą płatności, ale nie powiedziano Ci, że inny zespół dodał nową usługę nagród. Co się teraz dzieje, gdy usługa realizacji jest błędna?

Realizacja zamówień może organizować wszystkie inne usługi. Twój zespół ds. płatności otrzymuje wiadomość i cofasz płatność, ale możesz nie wiedzieć, kto obsługuje ponawianie prób i logikę błędów. Jeśli usługa nagród zmienia dostawców i ma nowy interfejs API, a nie informuje o tym Twój zespół, możesz nie wiedzieć o nowej usłudze.

Ostatecznie koordynacja tych orkiestracji i przepływów pracy może być trudna, ponieważ systemy stają się bardziej złożone, a zarządzanie dodaje więcej usług. To jeden z powodów, dla których migracja do architektury sterowanej zdarzeniami może być korzystna.

Korzyści architektury sterowanej zdarzeniami

Architektura sterowana zdarzeniami może pomóc w rozwiązaniu problemów związanych ze ścisłą koordynacją mikrousług, obsługą błędów i ponawiania prób oraz koordynacją między zespołami programistycznymi.

Ścisła koordynacja między mikroserwisami

W architekturze sterowanej zdarzeniami wydawca emituje zdarzenie, które jest potwierdzane przez magistralę zdarzeń. Magistrala zdarzeń kieruje zdarzenia do subskrybentów, którzy przetwarzają zdarzenia z niezależną logiką biznesową. Nie ma bezpośredniej komunikacji między wydawcami a subskrybentami.

Aplikacje oddzielone pozwalają zespołom działać bardziej niezależnie, co może zwiększyć ich prędkość. Na przykład w przypadku integracji opartej na interfejsie API, jeśli Twój zespół chce wiedzieć o zmianie, która nastąpiła w mikroserwisie innego zespołu, może być konieczne poproszenie tego zespołu o wywołanie interfejsu API do Twojej usługi. W związku z tym może okazać się konieczne rozliczenie się z uwierzytelnianiem, koordynacją z innym zespołem nad strukturą wywołania API. Powoduje to ruch tam i z powrotem między zespołami, co spowalnia czas tworzenia. Dzięki aplikacji sterowanej zdarzeniami możesz subskrybować zdarzenia wysyłane z mikrousługi, a magistrala zdarzeń (na przykład Amazon EventBridge) zajmuje się routingiem zdarzenia i obsługą uwierzytelniania.

Rozwiązywanie błędów i ponawianie prób

Innym powodem migracji do architektury sterowanej zdarzeniami jest obsługa nieprzewidywalnego ruchu. Witryny e-commerce, takie jak Amazon.com, mają zmienne natężenie ruchu w zależności od dnia. Mianowicie po złożeniu zamówienia dzieje się kilka rzeczy.

Najpierw Amazon sprawdza Twoją kartę kredytową, aby upewnić się, że środki są dostępne. Następnie musi zapakować towar i załadować na ciężarówki. To wszystko dzieje się w centrum realizacji Amazon. Nie ma synchronicznego wywołania API dla zaplecza Amazon w celu pakowania i wysyłania produktów. Po potwierdzeniu płatności przez system, interfejs zbiera informacje opisujące wydarzenie i umieszcza numer Twojego konta, dane karty kredytowej oraz to, co kupiłeś w pakiecie, a następnie umieszcza je w chmurze i w kolejce. Później inny program usuwa zdarzenie z kolejki i rozpoczyna pakowanie oraz wysyłkę.

Kluczową kwestią w tym procesie jest to, że wszystkie te czynności mogą działać w różnym tempie. Zwykle tempo, w jakim klienci składają zamówienia i tempo, w jakim magazyny mogą zapakować zamówienia, są w przybliżeniu równoważne. Jednak w ruchliwe dni, takie jak Prime Day, klienci składają zamówienia znacznie szybciej niż magazyny są w stanie działać.

Aplikacje e-commerce, takie jak Amazon.com, muszą być w stanie skalować w górę, aby obsłużyć nieprzewidywalny ruch. Gdy klient składa zamówienie, event bus, taki jak Amazon EventBridge, odbiera zdarzenie, a wszystkie mikrousługi podrzędne są w stanie wybrać zdarzenie zamówienia do przetworzenia. Ponieważ każda z mikrousług może zakończyć się niepowodzeniem niezależnie, nie ma pojedynczych punktów awarii.

Swobodna koordynacja między zespołami programistycznymi

Architektury sterowane zdarzeniami promują niezależność zespołu programistów ze względu na swobodne powiązanie między wydawcami a subskrybentami. Aplikacje mogą subskrybować zdarzenia z wymaganiami dotyczącymi routingu i logiką biznesową, które są niezależne od wydawcy i innych subskrybentów. Pozwala to wydawcom i subskrybentom zmieniać się niezależnie od siebie, zapewniając większą elastyczność ogólnej architektury.

Rozdzielone aplikacje umożliwiają również szybsze tworzenie nowych funkcji. Dodawanie nowych funkcji lub rozszerzanie istniejących może być prostsze dzięki architekturze opartej na zdarzeniach, ponieważ albo dodajesz nowe zdarzenia, albo modyfikujesz istniejące. Ten proces eliminuje złożoność aplikacji.

Wnioski

Dzięki temu artykułowi poznajesz wyzwania związane z tworzeniem aplikacji z architekturą żądanie-odpowiedź. W architekturze żądanie-odpowiedź klient musi wysłać żądanie i czekać na odpowiedź przed przejściem do następnego zadania. Wraz ze wzrostem złożoności aplikacji ta ściśle powiązana architektura może powodować problemy. Architektury sterowane zdarzeniami mogą zwiększyć skalowalność, odporność na błędy i szybkość działania programistów poprzez oddzielenie komponentów aplikacji.

źródło: AWS