Część wszystkim,
czego zazwyczaj używacie do komunikacji między microservices, które leżą w kontenerach?
Kafka? RabbitMQ?
(Powiedzmy, że microservices napisane w Spring Boot.)
Pozdrawiam
- Rejestracja:prawie 4 lata
- Ostatnio:około 3 godziny
- Postów:381
0
Apache Kafka 
RabbitMQ 
Kubernetes 
Docker - Rejestracja:ponad 4 lata
- Ostatnio:około 2 lata
- Lokalizacja:Warszawa
- Postów:1092
4
Kafka, REST
- Rejestracja:ponad 6 lat
- Ostatnio:8 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
7
still.still napisał(a):
czego zazwyczaj używacie do komunikacji między microservices, które leżą w kontenerach?
BTW zastanawia mnie ten dopisek że akurat w kontenerach leżą. Czy jakby nie leżały w kontenerach to miałbym użyć czegoś innego?
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:1268
1
No i pytanie, co te microservices robią. Bo ładownie Rabbita może być grubo nadmiarowe.
KamilAdam napisał(a):
still.still napisał(a):
czego zazwyczaj używacie do komunikacji między microservices, które leżą w kontenerach?
BTW zastanawia mnie ten dopisek że akurat w kontenerach leżą. Czy jakby nie leżały w kontenerach to miałbym użyć czegoś innego?
I czy jakby były napisane w C#, czy Scali lub Rust miałoby to znaczenie?
edytowany 1x, ostatnio: cerrato
- Rejestracja:około 7 lat
- Ostatnio:8 minut
- Postów:866
6
Z alternatyw polecam jeszcze gRPC. W porównaniu do Resta:
- używamy protobufów, ciężko powiedzieć, czy to zaleta czy nie. Protobuf to bardzo głupi format, który jest zaprojektowany pod maksymalną kompatybilność pomiędzy wersjami np. nie da się zrobić czegoś takiego jak wymagane pole. Z drugiej strony jest całkiem szybki i zajmuje bardzo mało miejsca
- wygenerowany kod jest bardzo prosty w użyciu
- nie ma bullshitu jak w Rescie, że coś nie jest po restowemu (jak np. że GET nie może mieć body). Projektowanie czegokolwiek jest dużo prostsze
- jest server reflection dzięki której można bawić się API za pomocą aplikacji i wysyłarki, nie jest potrzebny swagger lub dokumentacja z zewnątrz
- strumienie, jeśli ktoś potrzebuje
- całkiem wydajne bebechy
- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
3
still.still napisał(a):
czego zazwyczaj używacie do komunikacji między microservices, które leżą w kontenerach?
Kafka, JSON via HTTP, Azure Service Bus
slsy napisał(a):
- nie ma bullshitu jak w Rescie, że coś nie jest po restowemu (jak np. że GET nie może mieć body)
To nie jest kwestia RESTa tylko HTTP. GET ignoruje body, a serwer ma nawet prawo odrzucić takie żądanie.
Zobacz pozostałe 2 komentarze
Jeżeli serwer odrzuca body w get, to nie jest to poprawny serwer HTTP. To co najczęściej robi takie niespodzianki to frameworki, niestety często pisane przez ludzi, którzy nie przeczytali dokładnie specyfikacji HTTP.
Co konkretnie jest nieprawdą?
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1
Odczytałem "odrzuca" jako "wywala http error 400" albo coś takiego; a nie że "ignoruje". Niemniej, cytujesz stary standard. Z nowego to usunięto.
Ach, faktycznie w tym miesiącu wyszedł nowy. A w nim:
content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack No to tak nie do końca usunięto jak dla mnie.
No i moim zdaniem odrzucenie requestu jak najbardziej może się objawić 400 albo 405.
- Rejestracja:prawie 7 lat
- Ostatnio:ponad rok
- Lokalizacja:Wrocław
- Postów:159
0
Ostatnio spotkalem taki tool https://armeria.dev/
- Rejestracja:około 7 lat
- Ostatnio:8 minut
- Postów:866
1
Schadoow napisał(a):
@slsy: SOAP 2.0 xD. Tym razem może będzie lepiej xD ?
W SOAPie najbardziej przeszkadza mi fakt, że używa XMLa i nie jest tak simple jak to wskazuje nazwa. gRPC nie ma tych problemów
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:1268
0
slsy napisał(a):
Schadoow napisał(a):
@slsy: SOAP 2.0 xD. Tym razem może będzie lepiej xD ?
W SOAPie najbardziej przeszkadza mi fakt, że używa XMLa i nie jest tak simple jak to wskazuje nazwa.
A co ma do tego format, w jakim się dane. Pewnie jak by to samo był w JSON co jest w tym XMLu to tez by było mało czytelne inie intuicyjne.
moze chodzi o szybkosc przetwarzania .xml a innych formatow
https://techcommunity.microsoft.com/t5/sql-server-blog/json-parsing-10x-faster-than-xml-parsing/ba-p/385700
tu masz na przykladzie innego formatu, ktory jest szybszy jeszcze od .json : https://stormit.pl/protocol-buffers/
- Rejestracja:prawie 11 lat
- Ostatnio:około godziny
- Postów:1473
1
S4t napisał(a):
slsy napisał(a):
Schadoow napisał(a):
@slsy: SOAP 2.0 xD. Tym razem może będzie lepiej xD ?
W SOAPie najbardziej przeszkadza mi fakt, że używa XMLa i nie jest tak simple jak to wskazuje nazwa.
A co ma do tego format, w jakim się dane. Pewnie jak by to samo był w JSON co jest w tym XMLu to tez by było mało czytelne inie intuicyjne.
Głównie chyba to, że jest JSON jest szybszy i mniej zasobożerny od xmla.
Co jest łatwo osiągnąć, jeśli mowa o wariancie uboższym (i nie jest to ubóstwo pomijalne)
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:2310
0
Trzecia stroną watku, ale nie widzę, aby ktoś wyraźnie rozdzielił asynchroniczne od synchronicznych ...
- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
1
ZrobieDobrze napisał(a):
Trzecia stroną watku, ale nie widzę, aby ktoś wyraźnie rozdzielił asynchroniczne od synchronicznych ...
Więc czemu Ty tego nie zrobisz zamiast narzekać na innych?
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:2310
0
somekind napisał(a):
ZrobieDobrze napisał(a):
Trzecia stroną watku, ale nie widzę, aby ktoś wyraźnie rozdzielił asynchroniczne od synchronicznych ...
Więc czemu Ty tego nie zrobisz zamiast narzekać na innych?
Trzeba by wstecznie przerobić 70% wypowiedzi. Sync/async zupełnie zmienia wszystko: umiejscowienie w projekcie, sposób kodowania, architekturę, i na koniec "banalne" protokoły/produkty do tego użyte
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:1268
0
@S4t: "co te microservices robią." <-- Pobieraly by dane cyklicznie z innych zewnetrznych systemow/servicow i zapisywaly by w bazie danych. Za pomoca aplikacji mozna by dodawac i zmieniac zapisane dane. Mozliwe bylo tez z aplikacji wysylanie wiekszej ilosci danych (np. upload na server jednego pliku, ktory wazy do 30GB. W przyszlosci ma byc duzo wiecej niz 30GB.). Co uzyl bys w takim wypadku Apache Kafka/RabbitMQ + REST?
Ale tu za bardzo nie ma komunikacji między micorserwisami. Jeżeli tych serwisów/ źródeł, z których będziesz pobierał dane ma być dużo to postawiłbym rabbita gdzie trzymałbym kolejkę zadań dla tych serwisów. Wówczas łatwo byłoby to zeskalować - dosatwić kolejne serwisy do pobierania danych. Jak jedne serwis da rade z obsługą to po co komplikować. Po drugiej stronie masz API do bazy i jakąś apkę frontową. Trzeba by się wgłębić w temat co to za dane, ile tych danych, jak często i dużo danych bedzie modyfikowane itp itd. Jak dużo użytkowników i serwisów źródłowych będzie do obsłużenia.
@S4t: Zaciaganie danych (do kilkudziesieciu MB) z 20 zewnetrznych services np. co godzine, uzytkownikow ma byc do 20 tysiecy. Dlaczego uzyl bys Rabitta, a nie Kafki?
"Wówczas łatwo byłoby to zeskalować - dosatwić kolejne serwisy do pobierania danych." - skalowanie zrobilbys np. w Kubernetes?
@S4t: Danych nie trzeba jakos specjalnie przetwarzac. Po prostu sa zaciagane z 20 zewnetrznych servicow i zapisywane w bazie danych. Pozniej uzytkownik moze je w aplikacji recznie i troche automatycznie (za pomoca algorytmow) przetwarzac/dostosowywac. Wiekszej ilosc wysylanych danych do 30 GB nie trzeba obrabiac.
Redis jest MQ, MemDB, i protocol w jednym i ultra wydajny.
S4t