Kafka Msg VS REST Calls

Question

Kafka Msg VS REST Calls

Obecnie w świecie mikroserwisów widzę wiele projektów w moim miejscu pracy, które wykorzystują wiadomości kafka, gdy można osiągnąć podobne wyniki za pomocą wywołań rest api między mikroserwisami. Technicznie można całkowicie przestać używać wywołań rest api i zamiast tego korzystać z wiadomości kafka. Naprawdę chcę znać najlepsze praktyki, wady i zalety, kiedy używać wywołań api między mikrourządzeniami, kiedy używać wiadomości kafka.

Przykład z prawdziwego życia:

Mam spis serwis i serwis sprzedawcy. Codziennie usługa dostawcy wywołuje API dostawcy, aby uzyskać nowe produkty, które muszą zostać przeniesione do usługi inwentaryzacji. Liczba przedmiotów może wynosić do 10 000 obiektów.

W tym przypadku użycia, czy lepiej:

Po pobraniu nowych danych z interfejsu API dostawcy, wywołaj REST API usługi inventory, aby zapisać nowe elementy.
Po otrzymaniu nowych danych z API dostawcy, wyślij je jako wiadomość do tematu kafka, aby zostały zużyte przez usługę inwentaryzacji

Którą drogę byś wybrał i jaka jest ocena

26

rest apache-kafka microservices kafka-consumer-api spring-kafka

Author: user1955934, 2019-09-09

Source

4 answers

Architektura mikroserwisów opowiada się za niezależnymi i autonomicznymi usługami, które mogą działać samodzielnie. Pozwala zrozumieć, dlaczego potrzebujemy kolejek wiadomości?

Protokół HTTP to sync

Istnieje bardzo szerokie błędne przekonanie, że HTTP jest asynchroniczny. Http jest protokołem synchronicznym, ale twój Klient może sobie z tym poradzić asynchronicznie. Np. gdy wywołujesz jakąkolwiek usługę za pomocą http, twój Klient http schedule znajduje się w wątku backend (asynchronicznym). Jednak wywołanie http będzie czekać aż albo będzie to timeout lub odpowiedź powraca, przez cały ten czas łańcuch połączeń http czeka synchronicznie. Teraz, jeśli masz setki żądań na raz, możesz sobie wyobrazić, ile połączeń http jest zaplanowanych synchronicznie i możesz uruchamiać gniazda.

AMQP

W architekturze mikroserwisów preferujemy AMQP (Advance message queue protocol). Co oznacza, że usługa opuszcza wiadomość w kolejce i zapomina o niej. Jest to prawdziwy protokół transportu asynchronicznego, ponieważ usługa jest wykonywana po jej zakończeniu wiadomość w kolejce i zainteresowane serwisy wybiorą te.

Ten typ protokołu jest preferowany, ponieważ można skalować bez obaw, nawet gdy inne usługi są wyłączone, ponieważ w końcu otrzymają wiadomość/Zdarzenie / dane.

Więc to naprawdę zależy od konkretnego przypadku. HTTP są łatwe do wdrożenia, ale nie można ich dobrze skalować. Usługi wiadomości mają własne wyzwania, takie jak kolejność wiadomości i pracowników, ale które sprawiają, że architektura jest skalowalna i jest preferowany sposób. Do zapisu operacja zawsze preferuj kolejkę, do operacji odczytu możesz użyć HTTP, ale upewnij się, że nie robisz długiego łańcucha, w którym jedna usługa wywołuje inną, a ta wywołuje inną.

Mam nadzieję, że to pomoże !

3

Author: Imran Arshad,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-09-09 23:58:07

Jest kilka postów, które ułatwiają zrozumienie roli Kafki w Mikroserwisach.

Mikroserwisy-apache-kafka-domain-driven-design

Journey-to-event-driven

Budowanie-a-mikroserwisów-ekosystemu-z-Kafką

Build-services-backbone-events

Jeśli potrzebujesz pomocy, daj mi znać. Cieszę się, że mogę pomóc.

0

Author: Ashish Bhosle,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-09-09 14:30:26

Główne korzyści z kafka:

Z bezpośrednimi połączeniami REST do każdej usługi - Jeśli masz N usług, które wszystkie muszą ze sobą rozmawiać, to jest około N^2/2 połączeń. Może być też konieczne zbudowanie load balancer przed niektórymi usługami, które otrzymują wiele żądań, a może system kolejkowania / buforowania w usłudze, aby ustawić w kolejce swoje żądania (lol)

Z Kafką wystarczy N tematów. Z definicji zapewnia już swój system kolejkowy.

Główna wada z kafka:

Usługi nie czekają na odpowiedź żądania. Trudniej jest powiązać odpowiedź z żądaniem, gdy odpowiedź pojawi się w temacie.

0

Author: gunit,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-06-25 10:02:56

score 22 · Accepted Answer

Gist (dla tych, którzy chcą tylko gist)

- Kafka - Publikuj i Subskrybuj (po prostu przetworz rurociąg, powiadomi gdy zadanie zostanie wykonane)
- REST - Request & wait response (on-demand)

- Kafka - Publikuj raz-Subskrybuj N razy (przez N).
- REST - Prośba raz, odpowiedź raz. Umowa skończona.

- Kafka - Dane są przechowywane w temacie. Poszukaj tam i z powrotem (offsety) kiedy tylko chcesz, dopóki temat nie zostanie zachowany.
- REST - gdy Odpowiedź się skończy, to koniec. Ręcznie wykorzystaj bazę danych do przechowywania przetworzonych danych.

- Kafka - podziel przetwarzanie, przechowuj dane pośrednie w pośrednich topics (for speed and fault-tolerance)
- REST - weź dane, przetworz je wszystkie na raz lub jeśli chcesz je rozbić, nie zapomnij zadbać o swoje własne pośrednie magazyny danych.

- Kafka - ten, który składa prośbę typowo nie interesuje mnie odpowiedź (z wyjątkiem odpowiedzi, że jeśli wiadomość jest wysłane)
- REST - składam prośbę czyli I typowo oczekuj odpowiedzi (nie tylko odpowiedzi, że otrzymałeś prośbę, ale coś, co jest dla mnie znaczące, jakiś wynik obliczeniowy na przykład!)

Q&A style

Czy Twoje dane są przesyłane strumieniowo?
jeśli dane wciąż napływają i masz rurociąg do wykonania, Kafka jest najlepsza.

Do you need a request-response modelka?
jeśli użytkownik prosi o coś i czeka na odpowiedź, najlepiej jest odpocząć.

Kafka (lub jakakolwiek inna platforma strumieniowa) jest zwykle używana dla potoków, tj. gdzie mamyprzepływ do przodu danych.

Dane docierają do Kafki i stamtąd przechodzą przez component1, component2 i tak dalej, a na koniec (zazwyczaj) ląduje w bazie danych.

Aby uzyskać informacje na żądanie potrzebujemy magazynu danych (bazy danych) gdzie możemy to sprawdzić i zdobyć. W takim przypadku zapewniamy interfejs REST, który użytkownik może wywołać i uzyskać żądane dane.

Odnośnie Twojego przykładu,

Codzienna usługa dostawcy wywołuje API dostawcy, aby uzyskać nowe elementy i należy je przenieść do usługi inwentaryzacji

Pytania I Odpowiedzi

Czy twój API dostawcy korzysta z REST?

Następnie musisz wyciągnąć DANE i wcisnąć do Kafki. Stamtąd Twoja usługa inwentaryzacji (lub każda inna usługa po) zapisze się do tego tematu i wykona ich logikę przetwarzania.

Zaletą jest to, że możesz dodać dowolną inną usługę, która wymaga danych Sprzedawcy jako konsumenta do tematu sprzedawcy.

Ponadto dane sprzedawcy są zawsze dostępne nawet po przetworzeniu ich przez serwis zapasów.

jeśli używasz do tego celu REST, musisz wywołać API dostawcy dla każdego komponentu, który wymaga dostawcy dane, które stają się trywialne, gdy są używane z Kafka

czy chcesz, aby inwentarz został zapytany?

Przechowuj go w bazie danych po przetworzeniu przez Kafkę i zapewnij odpoczynek nad tym. Jest to potrzebne, ponieważ Kafka jest zwykle logiem, aby zapytanie danych-stanie potrzebowałbyś jakiejś bazy danych.