Witam,
jak pewnie wiecie na topie sa teraz microserwisy, w zasadzie niezaleznie od jezyka. Chcialem zapytac Was o wasze doswaidczenia w tym temacie. Szczegolnie interesuje mnie kwestia Bus'u komunikacyjnego. Jakie rozwiazania i pomysly macie na realizacje takiego Busu?
0
1
RabbitMQ albo ZeroMQ
0
Czyli po prostu kolejki? Nawet w obrebie tej samej VM?
0
tibco rendezvous. albo sam sobie napisz, daje to duzo frajdy :)
java nio twoim przyjacielem, imo najlepiej sprawdza sie push notifications i jakis minimalistyczny protokol.
co te twoje mikroserwisy maja robic?
0
Co masz na myśli pisząc "w obrębie tego samego VM" ?
Tym pytaniem, zniszczyłeś największą zajebistość mikroserwisów, mianowicie technologiczną niezależność.
0
niezdecydowany napisał(a):
Co masz na myśli pisząc "w obrębie tego samego VM" ?
Tym pytaniem, zniszczyłeś największą zajebistość mikroserwisów, mianowicie technologiczną niezależność.
Ja wstępnie myślałem właśnie o wykorzystaniu kolejek na BUS komunikacyjny, ale z drugiej strony sobie pomyślałem, że być może w obrębie tej samej VM nie ma potrzeby komunikowania się po kolejkach. Sytuacja jest następująca, że w przypadku gdy dwa serwisy musza się skomunikować i są na jeden VM/w jednym kontenerze to byc moze nie trzeba jeszcze udezac do np. Active MQ. To tylko takie moje luzne przemyslenia na ten temat :).
0
RabbitMQ jest ok ale słabo sie skaluje. Z javopodobnych obadaj Kafke, jak coś prostego i do wielu technologii RedisQ dziala fajnie i ma mega prosty w implementacji pubsub.
1
Pierwsze pytanie czy opierając swoją architekturę na mikro serwisach potrzebujesz jakiegoś rodzaju szyny komunikacyjnej? IMO, nie, ponieważ w 95% przypadków można zastąpić taką szynę odpowiednio skonfigurowaną infrastrukturą. Wołając jakiś serwis po URLu możesz spokojnie stworzyć własny routing w urządzeniach (wersja prosta z wykorzystaniem /etc/hosts) sieciowych tak by odpowiednio kierowały ruchem.
Takie rozwiązanie ma tą zaletę, że poszczególne serwisy są od siebie naprawdę całkowicie niezależne technologicznie. Wywołania odbywają się "po nazwie", a jedynym wspólnym mianownikiem dla wszystkich elementów jest konfiguracja DNSów :)
Jeżeli z jakiś powodów bezpośrednie kierowanie ruchem sieciowym nie jest wskazane np. nie zarządzasz infrastrukturą to ActiveMQ jest całkiem dobrym rozwiązaniem, ale znowuż. Trzeba przyjrzeć się temu jakie protokoły chcesz używać i jakie dane przesyłać.
1
Koziołek napisał(a):
Pierwsze pytanie czy opierając swoją architekturę na mikro serwisach potrzebujesz jakiegoś rodzaju szyny komunikacyjnej? IMO, nie, ponieważ w 95% przypadków można zastąpić taką szynę odpowiednio skonfigurowaną infrastrukturą.
Tak i nie, wszystko "zależy". Przykładowo, w dobie apek SPA można postawic front na websocketach i zaimplementować event sourcing do komunikacji między komponentami systemu. Microservisy po http sa fajne, ale czasem push/pull nie wystarcza i event sourcing ma tą przewage, że moge np: z serwisu backendowego wysłac komunikat, który niemal natychmiast zostanie zrenderowny przez przeglądare na froncie.