Po co stosować jakieś RabbitMQ albo Kafka

Hej

Sory jeśli pytanie jest głupie, ale po co stosować jakieś systemy kolejek typu RabbitMq albo Apach Kafka w aplikacji mikroserwisowej.
Na bootcampie robiliśmy apkę, gdzie moduły komunikowały się protokołem REST i JSON, a potem jeszcze dodawaliśmy jakiś RabbitMq który dostawał wiadomości typu działalność usera na stronie i mikroserwis który zbierał dane o aktywności i zapisywał w bazie najpierw brał je z tych kolejek.
Dlaczego ten mikroserwis po prostu nie wystawi RESTa i tak będziemy wrzucać dane?

Bez sensu uczyć się tylu narzędzi i technologii....

A jak to zrobisz "po prostu" w przypadku gdy mikroserwisy się dynamicznie skalują, gdy mają dynamiczne adresy, lub nawet gdy masz po prostu dwie instancje takiego serwisu i chcesz zlecić to temu który w obecnej chwili jest wolny lub najwcześniej ukończy swoje obecne zadania? Jest kilka alternatywnych rozwiązań ale każde wymaga nauki nowego narzędzia.
Możesz napisać własne ale prawie na pewno nie będzie łatwiejsze niż użycie "po prostu" gotowych rozwiązań.

Ostatnie zdanie brzmi dość baitowo. "Dla człowieka, który zna tylko młotek, wszystko, co napotyka, zaczyna wyglądać jak gwóźdź" - Paulo Coelho

Te wiadomości mogą też być buforowane przez co cały system może działać wydajniej, bo microservice nie czeka na przetworzenie wiadomości, ot wrzuca ją do kolejki, dalej dzieje się magia i z punktu widzenia użytkownika dzieje się to szybko. O powtórzeniach w przypadkach niedostępności jakiegoś serwisu nie wspominając ;) Owszem, można by to sobie samemu napisać, tylko po co skoro już są do tego rozwiązania.

AbsolwentPolonistyki napisał(a):

Bez sensu uczyć się tylu narzędzi i technologii....

Bo?

Bez sensu to jest ilość g**no-kodu z NPM'a potrzebnego aby uruchomić najprostszą aplikację w przeglądarce.

Nie wiem czy studiujesz czy nie, ale to są zagadnienie z zakresu architektury oprogramowania. Ja miałem taki przedmiot na PJATK. Poza tym elementy architektury oprogramowania pojawiają się w certyfikatach chmurowych dla architektów chmurowych np. AWS Certified Solutions Architect – Associate.

Poniżej moja lista zalet kolejek:

• decoupling - polega to na tym, że wysyłając komunikat do kolejki mikroserwis A nie musi wiedzieć, że istnieje mikroserwis B. Możesz w przyszłości zamienić mikroserwis B na C, albo B rozdzielić jeszcze na D i E, a mikroserwis A nie musi o tym wiedzieć i nie musisz zmieniać kodu w tym mikroserwisie gdy pozostałe się zmienią.
• skalowalność - polega na tym, że możesz łatwo postawić sobie np. 10 mikroserwisów do obsługi zamówień przed Black Friday, a kolejka automatycznie zajmie się przekazaniem strumienia zamówień, ich blokowaniem gdy któryś z 10 mikroserwisów podejmie się wykonania i usuwaniem gdy zamówienie zostało przetworzone. Dzięki temu masz pewność, że mikroserwisy do obsługi zamówień nie przetwarzają np. tego samego zamówienia wiele razy.
• odporność na błędy - gdy mikroserwis do obsługi zamówień się jednak wywali w Black Friday z jakiegoś powodu, to zamówienia wciąż leżą na kolejce i czekają aż wstanie, dzięki temu nie tracimy zamówień
• równomierne rozłożenie obciążeń - unikasz sytuacji w której któraś z instancji mikroserwisu jest nadmiernie obciążona w stosunku do pozostałych.
• chroniczność - niektóre systemy kolejkowe nawet w przypadku awarii kolejki mają trwałą pamięć wiadomości, które do niej dotarły
• ograniczenie "kuli śnieżnej" - kolejka może działać jako bufor chroniąc mikroserwisy przed nadmiernym obciążeniem
• transakcyjność - niektóre systemy kolejkowe wspierają transakcje czyli np. chronią przed sytuacją gdy jakaś wiadomość zostanie przetworzona, a nie ma do niej jakiegoś brakującego elementu.

Haskell napisał(a):

Nie wiem czy studiujesz czy nie, ale to są zagadnienie z zakresu architektury oprogramowania. Ja miałem taki przedmiot na PJATK. Poza tym elementy architektury oprogramowania pojawiają się w certyfikatach chmurowych dla architektów chmurowych np. AWS Certified Solutions Architect – Associate.

Nie prościej odpowiedzieć - bo BitTorrent jest powszechniejszy od FTP?