Już dostępny

Program Szkoleniowy Java Developer dostępny 🔥💪 tylko TERAZ za 999 zł  Sprawdź szczegóły i agendę

Zakres

Monitoring • Apache Kafka • Clean Code Testowanie • Hibernate • Systemy kolejkowe Sprawdź szczegóły i agendę

Zakres

14 modułów  /  ponad 40h nagrań  /  230 lekcji  /  dożywotni dostęp  /  Sprawdź szczegóły i agendę

Komunikacja po REST czy systemie kolejkowym?

utworzone przez Java, Mikroserwisy i Integracje

[Szybkie info]: Startujemy z II edycją Programu Szkoleniowego Java Developera 🚀. To MEGA piguła wiedzy o Java 🔥💪

  • 14 tygodniowy program szkoleniowy online,
  • 230 lekcji w formie video (40 godzin materiału)
  • z dożywotnim dostępem
  • Case Studies, masz dostęp do kodu i obrazów Dockerowych
  • zamknięta grupa mentorzy + uczestnicy i webinary na żywo

W agendzie znajdziesz: Mikroserwisy, Systemy kolejnowe, Apache Kafka, Caching, Hibernate/MyBatis/Spring Data, techniki efektywnych Testów kodu, Clean Code i Maven.

Tylko teraz dołączysz z 63% rabatem to 2699 zł 999 zł (+VAT). I nigdy już nie będzie taniej. Poniżej dowiesz się więcej:

Zobacz więcej

A teraz przechodzimy do artykułu:

W świecie mikroserwisów pojawia się temat sposobu ich integracji, aby wymienić wiedzę i udostępnić usługi pomiędzy domenami. Dwa popularne podejścia to komunikacja synchroniczna (np. HTTP, REST) oraz integracja przez system kolejkowy typu Apache Kafka, RabbitMQ czy JMS (Java Message Service np. Tibco).

Każde podejście ma szereg wad i zalet, dlatego przed podjęciem decyzji należy zrozumieć przypadek użycia, poznać kontekst biznesowy i wymagania niefunkcjonalne oraz przeprowadzić analizę za i przeciw cechom każdego z rozwiązań.

W tym artykule dowiesz się:

  • Jak działa integracja synchroniczna HTTP/REST
  • Jak działa integracja przy użyciu systemów kolejkowych
  • Jakie heurystyki pomogą Ci podjąć decyzję, który sposób integracji wybrać, np.:
    • Sposób komunikacji (orkiestracja vs choreografia)
    • Szybki dostęp do informacji
    • Asynchroniczne przetwarzanie
    • Dostępność aplikacji
    • Pewność wykonania operacji

HTTP/REST, komunikacja synchroniczna

Komunikacja za pomocą HTTP/REST należy do kategorii komunikacji synchronicznej. Oznacza to, że komponent inicjujący komunikację (Klient) wysyła żądanie, a następnie utrzymuje połączenie, czekając na odpowiedź zdalnej usługi (Serwera). Jest to stosunkowo prosty schemat komunikacji. Obie strony komunikacji muszą być dostępne w tym samym czasie, kiedy zachodzi wywołanie żądania. Serwer powinien odpowiedzieć Klientowi na żądanie w akceptowalnym czasie. Oznacza to, że wynik dla żądania również musi być dostępny w akceptowalnym czasie.

Komunikacja synchroniczna HTTP/REST
Komunikacja synchroniczna HTTP/REST

Gdy wystąpi błąd obsługi żądania, połączenie jest zrywane, a operacja nie powiedzie się. Podobnie w sytuacji, gdy wystąpi timeout, czyli osiągnięcie maksymalnego czasu odpowiedzi.

Komunikacja synchroniczna doskonale spisuje się dla operacji odczytu (typu read). Gdy potrzebna jest informacja na temat stanu w systemie w konkretnym czasie, otrzymujemy odpowiedź w danej chwili.

Jeżeli żądanie jest operacją sygnalizującą istotną zmianę w systemie (operacja typu write) i występuje błąd, to po stronie Klienta inicjującego komunikację spoczywa odpowiedzialność obsługi błędnej sytuacji.

  • Można ją ponawiać w razie krótkotrwałych awarii stosując Retry Pattern (czytaj więcej).
  • W przypadku długotrwałych awarii można z góry przerwać złożenie żądania stosując Circuit Breaker Pattern (czytaj więcej).
  • Jeżeli błąd pozostaje, należy albo poinformować użytkownika o nieudanej operacji, albo zaimplementować mechanizm dłuższego ponawiania procesu. Komplikuje to nieco kod Klienta.
Błąd w komunikacji synchronicznej HTTP/REST
Błąd w komunikacji synchronicznej HTTP/REST

Klient musi znać konkretny adres usługi Serwera, do której się łączy: adres instancji aplikacji. Jeżeli Serwer jest wdrożony jako wiele instancji aplikacji, zazwyczaj Klient korzysta z usługi proxy – Load Balancer’a – który przekazuje żądania do konkretnych instancji usług.

Komunikacja HTTP przy użyciu Load Balancer'a
Komunikacja HTTP przy użyciu Load Balancer’a

Komunikacja przez Systemy Kolejkowe

Architektury zintegrowane przez Systemy Kolejkowe zakładają aplikacje komunikujące się poprzez wymianę komunikatów (Messages). Z jednej strony są Producenci wiadomości (Producers), a drugiej Konsumenci (Consumers). Wiadomości wysyłane są na szynę danych (zwaną Message Broker / Message Bus).

Producenci nie znają bezpośrednio Konsumentów, komunikują się tylko z szyną danych. Producenci i Konsumenci nie muszą być dostępni w czasie zlecania i przetwarzania operacji. Wiadomości są gromadzone na szynie danych i buforowane.

Komunikacja asynchroniczna przy użyciu systemu kolejkowego
Komunikacja asynchroniczna przy użyciu systemu kolejkowego

Integracja tego typu nie gwarantuje wykonania operacji, a jedynie przekazanie wiadomości. Producent może otrzymać jedynie potwierdzenie przyjęcia (ACK – acknowledge) wiadomości przez szynę danych. Konsument może odesłać potwierdzenie przyjęcia wiadomości (ACK – acknowledge – w momencie konsumowania lub po poprawnym przetworzeniu) lub odrzucić wiadomość (NACK – not acknowledged – w przypadku błędu przetwarzania).

Potwierdzanie nadania i odbierania wiadomości w systemie kolejkowym
Potwierdzanie nadania i odbierania wiadomości w systemie kolejkowym

Jeżeli Producent jest zainteresowany otrzymaniem statusu wykonania operacji przez Konsumenta, ten musi wysłać wiadomość zwrotną.

Zaletą rozwiązania jest asynchroniczne przetwarzanie – Konsument może wykonywać operacje w swoim tempie, nie obciążając Producenta. Nieprzetworzone wiadomości wciąż pozostają na szynie danych. Jeżeli wiadomość musi być przetworzona w danym czasie, istnieje możliwość ustawienia tzw. TTL (time-to-live), czyli okresu przydatności wiadomości.

Potencjalną wadą może być to, że awaria szyny danych może doprowadzić do uszkodzenia całej architektury. Nie jest to do końca dyskwalifikująca obiekcja – istnieją wysoko dostępne szyny danych takie jak Apache Kafka, czy Tibco EMS.

Jakiego typu integrację wybrać?

Podjęcie decyzji powinno być przemyślane w danym kontekście użycia. Poniżej skupię się na paru heurystykach, które pomogą Ci podjąć decyzję lub będą zaczątkiem do dyskusji na ten temat w zespole.

Psst… Interesujący artykuł?

Jeżeli podoba Ci się ten artykuł i chcesz takich więcej – dołącz do newslettera. Nie ominą Cię materiały tego typu.

.

1. Sposób komunikacji (orkiestracja vs choreografia)

Zastanów się, jakiego typu komunikacja będzie potrzebna:

  • jeden-do-jeden
  • jeden-do-wielu (rozgłaszanie komunikatu)

Dla prostych integracji można rozważyć zarówno komunikację synchroniczną, jak i przez systemy kolejkowe uwzględniając to, co możesz zrobić w przypadku błędu obsługi żądania oraz tego czy wyniku operacji potrzebujesz natychmiast, czy może to być informacja zwrotna „za jakiś czas”.

W systemie mogą następować pewne rozgłaszane zdarzenia biznesowe. Wtedy masz do czynienia z komunikacją jeden-do-wielu. Przykład: należy poinformować kilka systemów o przyjęciu zamówienia od klienta:

  • System obsługujący dostawy, aby zlecić zaplanowanie dostawę.
  • System stanu magazynowego, aby zarezerwować ilości magazynowe.
  • System obsługujący punkty lojalnościowe, aby naliczyć punkty za zamówienie.

W takim przypadku zamiast wywołując wszystkie serwisy po kolei (oraz obsługiwać cały proces za pomocą sagi w przypadku pojedynczych błędów, co komplikuje nieco system) możesz zastosować komunikację przez szynę danych i rozgłosić wiadomość o zaistniałym zdarzeniu.

Wielu Konsumentów w integracji z użyciem systemu kolejkowego
Wielu Konsumentów w integracji z użyciem systemu kolejkowego

Istnieje zasadnicza różnica pomiędzy imperatywnym instruowaniem co i kto ma zrobić od zgłoszenia zdarzenia i pozwolenia systemowi samemu na nie zareagować.

Pierwsze podejście to orkiestracja. Przypomina dyrygenta, który wskazuje, kiedy ma zagrać orkiestra. Z podejściem masz do czynienia, gdy wywołujesz poszczególne serwisy w procesie, zlecając operacje po kolei.

Innym jest choreografia, kiedy na dane zdarzenie system sam odpowiada reakcją. Możesz wyobrazić sobie zespół tancerzy, w którym lider rozpoczyna jakiś ruch, a reszta tancerzy, bacznie obserwując lidera, kontynuuje figury. Akcja-reakcja w kompozycji tworzy pełną harmonię (bez dyrygenta!).

Obrazek posiada pusty atrybut alt; plik o nazwie dyrygent2.jpg

Psst… Interesujący artykuł?

Jeżeli podoba Ci się ten artykuł i chcesz takich więcej – dołącz do newslettera. Nie ominą Cię materiały tego typu.

.

2. Szybki dostęp do informacji

Jeżeli potrzebujesz bardzo szybkiego dostępu do informacji (odczyt), zdecydowanie skorzystaj z integracji synchronicznej. Musisz jednak zapewnić bardzo szybki dostęp do danych (np. przechowywane w pamięci lub bazie danych).

Przykłady:

  1. Status przesyłki, zwracany bezpośrednio z bazy danych
  2. Status obróbki pliku video, zwracany bezpośrednio z bazy danych, ale przetwarzanie następuje już asynchronicznie. Operacja odczytuje tylko status w bazie danych. Asynchroniczne przetworzenie zmienia status.

Antywzorce:

  1. Pytanie o status operacji przez system kolejkowy. W przypadku zwolnienia działania Konsumenta, żądania zlecone Producentowi i tak są zawieszone, a Konsument po czasie może odpowiadać na wiadomości, na które już nikt nie czeka.

3. Asynchroniczne przetwarzanie

Do systemu zlecane są pewne operacje. Jeżeli spójność systemu na to pozwala, mogą być przetworzone od razu, a zmiany zapisane – wtedy wybierz prostą komunikację synchroniczną.

Jeżeli natomiast wykonanie operacji wymaga długiego przetwarzania, warto wysłać taką operację na system kolejkowy. Konsument przetworzy ją w swoim czasie i odeśle odpowiedź. Jednocześnie nieprzetworzone operacje będą oczekiwały na szynie danych.

W przypadku podejścia synchronicznej integracji, dla długo trwających operacji musisz zlecić jej wykonanie, a następnie periodycznie (co jakiś czas) odpytywać się o status wykonania. Wymaga to po stornie Klienta implementacji mechanizmu odpytywania. Po stronie Konsumenta wymagane jest zapisania zadania, przetwarzania zadań zapisanych w kolejce i implementację mechnizmu zwracania statusu odpowiedzi. W protokole HTTP zwykle przyjęcie zadania zwraca status 202 Accepted, a następnie Klient odpytuje się o status wykonania.

Rozważ uproszczenie integracji swoich aplikacji po prostu przez system kolejkowy, jeżeli to możliwe, a oszczędzisz pracy na implementowanie podobnego mechanizmu w aplikacji.

4. Dostępność aplikacji

Z pewnych względów może być tak, że zintegrowany system może być niedostępny w momencie zlecania operacji lub z jakiegoś powodu nie może jej teraz wykonać. A operacja musi być zrobiona, prędzej czy później.

W przypadku użycia systemów kolejkowych istnieje możliwość wysłania wiadomości na szynę danych, na której zostanie ona zbuforowana, a Konsument w odpowiednim czasie podejmie operację.

Oznacza to, że Producent i Konsument nie muszą być obaj dostępni w momencie przetwarzania operacji, co jest niemożliwe w przypadku komunikacji synchronicznej. W przypadku niedostępności Serwera w komunikacji synchronicznej operacja nie powiedzie się, a zastosowanie mają Retry Pattern i Circuit Breaker Pattern.

5. Pewność wykonania operacji

Systemy kolejkowe dają możliwość otrzymania:

  • Gwarancji opublikowania wiadomości na szynie danych – wtedy możemy wysłać potwierdzenie do klienta o przyjęciu operacji do realizacji (jeszcze nie wyniku tej operacji).
  • Potwierdzenia przyjęcia wiadomości przez Konsumenta – decyduje on, kiedy potwierdza przyjęcie, czy na początku przetwarzania, czy na końcu. Jeżeli na końcu przetwarzania to mamy pewność, że przed wykasowaniem wiadomości z szyny danych, operacja została przetworzona. Jeżeli podczas przetwarzania wystąpił błąd, wiadomość trafia z powrotem na szynę.

Daje to pewność, że komunikacja nie jest przerwana i zagubiona, co mogłoby wystąpić podczas przetwarzania synchronicznego – stracone połączenie, podczas gdy Serwer kończy pracę nad przetwarzaniem operacji.

Podsumowanie

Wybór metody integracji aplikacji nie powinien być przypadkowy. Przed podjęciem decyzji rozważ wszystkie za i przeciw komunikacji synchronicznej po HTTP/REST oraz systemem kolejkowym. Mam nadzieję, że zaprezentowane heurystyki Ci w tym pomogą.

Wpis który czytasz to zaledwie fragment wiedzy zawartej w Programie szkoleniowym Java Developera od SoftwareSkill. Mamy do przekazania sporo usystematyzowanej wiedzy z zakresu kluczowych kompetencji i umiejętności Java Developera. Program składa się z kilku modułów w cotygodniowych dawkach wiedzy w formie video.

Podoba Ci się ten artykuł? Weź więcej.

Jeżeli uważasz ten materiał za wartościowy i chcesz więcej treści tego typu – nie przegap ich i otrzymuj je prosto na swoją skrzynkę. Nawiążmy kontakt.

.

Gdybyś potrzebował jeszcze więcej:

Jesteś Java Developerem?

Przejdź na wyższy poziom wiedzy 
„Droga do Seniora” 🔥💪

Jesteś Team Leaderem? Masz zespół?

Podnieś efektywność i wiedzę swojego zespołu 👌

Dyskusja