Jak skalować websockety?

0

Mój pomysł na pracę dyplomową na podyplomówce Big Data o streamowaniu danych zaczyna się komplikować.
Nie pomyślałem wcześniej o tym jak będę skalował tę aplikację, a o to przecież chodzi w tym całym Big Data.

W skrócie aplikacja będzie robić to:

O ile Apache Kafka czy Postgres umie działać na klastrach, więc się skaluje o tyle Springowe Websockety nie.
Potrzebuję jakiegoś brokera STOMP? ActiveMQ? RabitMQ z biblioteką do STOMP?
No, bo na front streamować z Kafki to chyba słabe rozwiązanie?

1

Jakiś broker wiadomości, może być RabbitMq albo Redis. Chociaż masz już tam Kafkę, to nie wiem po co dokładać.

A dlaczego websocket, a nie np. HTTP/2 push albo SSE? Jak będziesz skalowalnoć websockety na load balancerze?

I co robi tam ten biedny Postgres w świecie Big Data? :)

Ogólnie też bez konkretów nt. wolumenu danych, liczby użytkowników, wymagań odnośnie latency ciężko coś zaproponować sensownego. Może dałoby radę to opazdzierzyć na postgresie i zrobić zwykły polling. Wyjdź od czegoś prostego.

1

Musisz utworzyć zdalny rejestr MultiServerUserRegistry i zrobić load balancing

0
Charles_Ray napisał(a):

Jakiś broker wiadomości, może być RabbitMq albo Redis. Chociaż masz już tam Kafkę, to nie wiem po co dokładać.

Kafka nie obsługuje protokołu STOMP...

A dlaczego websocket, a nie np. HTTP/2 push albo SSE? Jak będziesz skalowalnoć websockety na load balancerze?

no właśnie nie wiem jak...

I co robi tam ten biedny Postgres w świecie Big Data? :)

A jaką inną bazę proponujesz?
Dane będą ustrukturyzowane. Postgres skaluje się elegancko i ma dedykowaną wersję do szeregów czasowych: timescaledb

1

Co tu jest chyba fundamentalnie nie tak, wyglada jakby było mega scouplowane. Na Kafce masz eventy, które konsumenci pushują do websocketa i dopiero tam mówimy o stompie.

Nie znam tej bazy i nie wiem co tam chcesz trzymać - może to być use case na Cassandrę, może na Influxa, ale nie znam wymagań :)

Ogólnie poczytaj o Lambda/Kappa Architecture, nie musisz wynajdywać koła od nowa.

1

Z ciekawostek to jest coś takiego jak CockroachDB i jest to rozproszona baza danych dość dobrze udająca Postgresa (na poziomie protokołu i SQL).
Udawanie postgresa na pewno działa dobrze. Co do skalowania to niestety poza "marketingiem" wiem niewiele więcej - mam za małe (na razie) aplikacje na tym.

0

Pisałeś tu websocket do notowań kryptowalut że będziesz dane z sieci zasysać. Rozumiem, że w jakiś sposób przetworzysz te dane i wyslesz na swój front. Sorry, jeżeli coś upraszczam, ale po co w ogóle Ci w takim razie jest Postgress, znaczy właściwie DB w ogólności? Co Ty w tej DB chcesz trzymać?

0
Charles_Ray napisał(a):

Nie znam tej bazy i nie wiem co tam chcesz trzymać - może to być use case na Cassandrę, może na Influxa, ale nie znam wymagań :)

PanamaJoe napisał(a):

Pisałeś tu websocket do notowań kryptowalut że będziesz dane z sieci zasysać. Rozumiem, że w jakiś sposób przetworzysz te dane i wyslesz na swój front. Sorry, jeżeli coś upraszczam, ale po co w ogóle Ci w takim razie jest Postgress, znaczy właściwie DB w ogólności? Co Ty w tej DB chcesz trzymać?

np. tak o:

To DB to w sumie kij z nim, może go nie być, ale kafka ma connectory, więc to mam za darmo.** Problem jest w tym, że z Apache Kafka Streams nie wiem jak wysłać na front.**

0

Problem jest w tym, że z Apache Kafka Streams nie wiem jak wysłać na front.

Pierwszy wynik w Google https://www.confluent.io/blog/webify-event-streams-using-kafka-connect-http-sink/

Jak pisałem wcześniej, nie tylko websockety są na świecie, tym bardziej, że nie potrzebujesz komunikacji w 2 strony.

1

@NamingException: W Quarkusie np, możesz zmapować kafkowy topic na reactive Publisher, a następnie wystawić taki publisher jako SSE endpoint.

0

Czyli co ma od razu z kafki na front słać?


kafka -> Quarkus -> SSE
brzmi dobrze

1

Przykładowy kod:

    @Incoming("sseIncoming")
    @Outgoing("sseChannel")
    @Acknowledgment(Acknowledgment.Strategy.PRE_PROCESSING)
    public SpecificRecord toSSE(Message<SpecificRecord> message) {
        return message.getPayload();
    }

    @Inject
    @Channel("sseChannel")
    private Publisher<SpecificRecord> events;

    @GET
    @Path("/stream")
    @Produces(MediaType.SERVER_SENT_EVENTS)
    @SseElementType("text/plain")
    public Publisher<SpecificRecord> stream(String param) {
        return events;
    }

Sse-incoming jest zmapowany na kafka topic. Jak zaatakujesz ten endpoint z przeglądarki dostaniesz SSE eventy z każdym kafka eventem na topicu.

0

A jak to skalować? On na Kafce robi endpoint SSE, tak? Czy robi endpoint z kafki do SSE

1

Pobiera eventy z kafki i publikuje je ze swojego reactive Publishera (akurat w tym przypadku na tego publishera jest zmapowany topic kafkowy bo pasuje do Twojego use-casu, równie dobrze możesz utworzyć swojego publishera ze statycznych danych).
Jeśli chciałbyś mieć więcej takich serwisów, musiałbyś tworzyć każdy z inną kafka-consumer-grupą.

0

Ludzie przecież jaki kolega framework zastosuje jest absolutnie wtórne :D zmiana pakietu, z którego pochodzą adnotacje nie pomoże architekturze

0

@Charles_Ray: To była raczej kontynuacja Twojej myśli, żeby wykorzystać SSE by na biężaco updatować front.
Twój komentarz sugeruje, że websockety trudniej skalować niż SSE. Możesz rozwinąć dlaczego?

1

Utrzymywanie stałego dedykowanego połączenia websocketowego (pierwotne połączenie http + TCP) wymaga więcej zasobów na load balancerze. Hardkorowych detali nie znam, można doczytać na blogu haproxy.

0

Pytanie co tak naprawdę to ma robić. Zakładając, że UC jest taki - dane lecą z live-feedów i powinny trafiać zarówno do frontu, jak i na dysk - to pomiędzy Kafką i frontem potrzebujesz jakiegoś skalowalnego cache'a.
To może być albo taki faktyczny skalowalny cache (Ignite, Redis), albo timeseries database (to zależy od scenariusza - ja korzystałem tylko z InfluxDB, KDB+ i Azure TS Insights).
Jeśli chodzi o zapis na dysku to sky is the limit. Podobno nawet Kafka daje radę do trzymania danych, ale nigdy nie korzystałem - ale to by znaczyło, że stack technologiczny ładnie się redukuje do Kafka + cache + ewentualnie coś jako bramka do cache'u.

1 użytkowników online, w tym zalogowanych: 0, gości: 1