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
0
2
REST, RabbitMQ, Kafka
4
Kafka, REST
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?
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?
2
REST, SQS(kolejka od AWS), Kinesis(stream od AWS), ogólnie to TCP/IP ;)
2
No w zasadzie jak Java to kiedyś jeszcze JMSa wysłałem, ale nie jestem z tego dumny :(
I można na JVMie użyć jeszcze Akka Remote (żyje to jeszcze w ogóle?)
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
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.
1
0MQ, Redis
1
@slsy: SOAP 2.0 xD. Tym razem może będzie lepiej xD ?
0
Ostatnio spotkalem taki tool https://armeria.dev/
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
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.
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.
0
Trzecia stroną watku, ale nie widzę, aby ktoś wyraźnie rozdzielił asynchroniczne od synchronicznych ...
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?
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
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.