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
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
REST, RabbitMQ, Kafka
Kafka, REST
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?
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?
REST, SQS(kolejka od AWS), Kinesis(stream od AWS), ogólnie to TCP/IP ;)
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?)
Z alternatyw polecam jeszcze gRPC. W porównaniu do Resta:
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.
0MQ, Redis
@slsy: SOAP 2.0 xD. Tym razem może będzie lepiej xD ?
Ostatnio spotkalem taki tool https://armeria.dev/
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
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.
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.
Trzecia stroną watku, ale nie widzę, aby ktoś wyraźnie rozdzielił asynchroniczne od synchronicznych ...
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?
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
@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.