Porównywarka - strategie pobierania danych z mikroserwisów.

0

Cześć,

Potrzebuję pomocy w doborze najbardziej optymalnego rozwiązania.
Chciałbym żebyście sobie wyobrazili prostą architekturę opartą na mikroserwisach. Case to porównywarka ubezpieczeń. Wszystko jest w klastrze kubernetesowym. Mamy jedno wyjście na świat - REST Api, która wrzuca requesty o przeliczanie składek do Kafki. Kafkę nasłuchują mikroserwisy odpowiedzialne za obliczanie składek per towarzystwo. Mikroserwisów per towarzystwo będzie kilka, wszystkie w tej samej consumer group. Po przeliczeniu wyniki wrzucają się na inny topic w Kafce.

W jaki sposób najlepiej przeprowadzić pobieranie wyników? Stworzyć jakąś bazę, utworzyć ID i pullować co jakiś czas? Otworzyć połączenie websocketem i przesyłać tam dane? Może są jakieś inne, fajne strategie do rozwiązywania tego typu problemów? Mam dowolność jeśli chodzi o dobór technologii więc mogę sobie wrzucić dowolną rzecz do tego stacku.

Pozdrawiam, z góry dzięki za pomoc ;)

0

Na Kafce jest ograniczona retencja, więc jeśli wyniki maja być persystentne (historia, wersjonowanie), to powinieneś je wrzucać do bazy. Jeśli masz mikroserwis pod konkretnego ubezpieczyciela, to musisz w jakiś sposób agregować wyliczenia (process manager) - tutaj lepszy będzie event sourcing zamiast mutowania stanu.

Druga sprawa to prezentacja wyników użytkownikowi - jeśli ma być „real time”, to potrzebujesz pusha do klienta (websocket, http2).

BTW. dobry case pod event storming

0

Dzięki wielkie za pomysły o SSE i HTTP2 nie pomyślałem, zbadam temat.
Odniosę się może w nowym komentarzu, żeby rzucić więcej światła na temat.

@marian pazdzioch - szukam rozsądnego kompromisu pomiędzy wydajnością a łatwością implementacji

@Shalom wspomniał o long pullingu - nie wszystkie obliczenia (chociaż wolałbym...) będą oparte o szybki web service. Niektóre mikroserwisy będą musiały trochę dłużej popracować, żeby dostać wynik ;) Jak rozumiem - przez long pulling będę musiał czekać na wyniki z ostatniego towarzystwa... co będzie średnią opcją. Chyba, że źle o tym myślę...

@Charles_Ray - wstępnie myślałem, żeby wszystkie wyniki wrzucać do ElasticSearcha, ewentualnie później dorzucę jeszcze do tego jakąś bazę. Nie korzystałem jeszcze z ElasticSearch - myślisz że się nada?

0

Ad. ElasticSearch - nie myśl gotowym rozwiązaniem, tylko problemem jaki chcesz rozwiązać. Zacznij od wypisania sobie, jakie warunki musi spełniać storage - czy ważniejsze są zapisy czy odczyty, jakiego typu to będą zapytania, poczytaj o CAP theorem.

0

Jak rozumiem - przez long pulling będę musiał czekać na wyniki z ostatniego towarzystwa... co będzie średnią opcją. Chyba, że źle o tym myślę...

Nikt ci nie broni puścić kilka osobnych równoległych query z klienta do różnych serwisów. Wtedy możesz czekać długo tylko na tego jednego, a reszta już dawno pokaże się userowi. Pytanie tylko ile masz czekać, bo możesz trafić na jakiś timeout ;)

0

Oprócz podanych wyżej rozwiązań:
Są dostępne serwisy "pushujące" dane do klientów. Mają różną kompatybilność (problemem może np być Safari i iOs. Możesz też użyć Firestore od Google. Zwykle SDK jest przyjazne. Z Firestore to zapisujesz dane w bazie i... po prostu każdy połączony klient je dostanie. (kwestia autoryzacji i dostępu do konkretnych informacji pozostaje do zaimplementowania). Z serwisami zwykle jest dostępne SDK które pozwoli Ci wysłać dane do nich i osobne SDK dla klienta, dzięki czemu dostaną te dane. Niestety nazw już nie pamiętam...

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