#java #queue #programowanie Mirki, czy widzicie jakieś zalety w użyciu kolejki zamiast REST ale w przypadku gdy mamy tylko komunikację synchroniczną (czekamy na odpowiedź). Mam w projekcie takie przypadki i zastanawiam się czy ma to w ogóle jakiś sens
@Patres: w oganiętym systemie: nie. Kiedy to może mieć sens? Jak większość zapytań idzie przez kolejki to przepchanie tych synchronicznych zapytań może mieć sens, bo wtedy system zachowuje się tak samo dla każdego zapytania, więc masz uproszczone debugowanie, logowanie, monitoring itd. Z drugiej strony śledzenie takiej synchronicznej tranzakcji, która jest przepychana przez kolejkę jest dużo bardziej skomplikowane
Inne zalety to load balancing i retry, które masz za darmo (ale to samo
@Patres: Łatwiej można ogarnąć high-availability i o ile jakiś retry po http to pewnie można trwać z minutę to na kolejce może i godzinami/dniami leżeć event aż go przerobi odpowiedni serwis gdy w końcu zacznie działać. Oprócz tego odciąża to zasoby bo jak serwis robi retry po http to normalnie zużywa na to wątek, a tak to wysyła event na kolejkę i elo
@Patres: lepszy decoupling. Jak wysyłasz event to możesz potem dopisać łatwo kolejną reakcję na zdarzenie gdziekolwiek w serwisie lub innym serwisie. Przy "czystym" rest musisz rozszerzać istniejący handler. I zaraz się okaże, że Twój rest musi zrobić 5 rzeczy na raz. Generalnie jest więcej za niż przeciw w przypadku większych rozwiązań.
Nie szkodzi. W takiej sytuacji użycie brokera też zwiększa high availability
kolejka też jedzie na wątkach. Call http nie kosztuje wątku jeśli używasz async/awaitów, reactora lub green threadów. W każdym popularnym języku znajdziesz coś z tej trójki
Ale jest to gorsze rozwiązanie z punktu widzenia high availability. To, że używasz lekkich wątków magicznie nie sprawi, że nie zgubisz eventu, gdy apka ci padnie w
@Saly: przecież masz ją w kodzie. Kolejka tylko zarządza priorytetem, przechowuje i rozsyła zdarzenia. A architektura robi się skomplikowana, serwisy muszą komunikować się ze sobą, po jakimś czasie wszystko zaczyna gadać ze wszystkim. Każda głupia funkcja musi nagle przechowywać kolejkę, robić retry itd. Przerabiałem to, na koniec nie wiadomo co się stało, kto nie dostał albo nie przetworzył.
@LazyInitializationException: @fujiyama @Saly Dzięki za dyskusje! Będąc szczerym nie do końca jestem przekonany czy kolejki w tym przypadku mają sens (co nie oznacza się z Wami nie zgadzam):
Łatwiej można ogarnąć high-availability i o ile jakiś retry po http to pewnie można trwać z minutę to na kolejce może i godzinami/dniami leżeć event
Teoretycznie tak, ale w praktyce consumer raczej nie będzie tyle czekać i też zakończy się to timeoutem. A
ale praca przy kolejkach w Apache Camel sprawia że dostaję migrenę
@Patres: taki już jest camel. Słabe typowanie (wszystko to Message) plus uwspólnianie każdego możliwego protokołu do Map<String, Object> nie jest miłe w developowaniu
Mirki, czy widzicie jakieś zalety w użyciu kolejki zamiast REST ale w przypadku gdy mamy tylko komunikację synchroniczną (czekamy na odpowiedź). Mam w projekcie takie przypadki i zastanawiam się czy ma to w ogóle jakiś sens
Inne zalety to load balancing i retry, które masz za darmo (ale to samo
Jak wysyłasz event to możesz potem dopisać łatwo kolejną reakcję na zdarzenie gdziekolwiek w serwisie lub innym serwisie.
Przy "czystym" rest musisz rozszerzać istniejący handler. I zaraz się okaże, że Twój rest musi zrobić 5 rzeczy na raz.
Generalnie jest więcej za niż przeciw w przypadku większych rozwiązań.
@LazyInitializationException: ale pytanie było o synchroniczne calle.
@LazyInitializationException: kolejka też jedzie na wątkach. Call http nie kosztuje wątku jeśli używasz async/awaitów, reactora lub green threadów.
Nie szkodzi. W takiej sytuacji użycie brokera też zwiększa high availability
Ale jest to gorsze rozwiązanie z punktu widzenia high availability. To, że używasz lekkich wątków magicznie nie sprawi, że nie zgubisz eventu, gdy apka ci padnie w
A architektura robi się skomplikowana, serwisy muszą komunikować się ze sobą, po jakimś czasie wszystko zaczyna gadać ze wszystkim. Każda głupia funkcja musi nagle przechowywać kolejkę, robić retry itd.
Przerabiałem to, na koniec nie wiadomo co się stało, kto nie dostał albo nie przetworzył.
Teoretycznie tak, ale w praktyce consumer raczej nie będzie tyle czekać i też zakończy się to timeoutem. A
@Patres: taki już jest camel. Słabe typowanie (wszystko to
Message) plus uwspólnianie każdego możliwego protokołu doMap<String, Object>nie jest miłe w developowaniu