Microservice architektura pre real-time aplikaciu

[schwantner.peter]

Ahojte,
vymyslam si vlastny projekt na domace hranie sa s technologiami, ktore v praci nepouzivame, a rad by som si ich osahal. Islo by konkretne o real-time votovaciu aplikaciu postavenu na springovych mikrosluzbach a UI napr. vo Vue, ktoru by som postupne rozsiroval o nejake blbostky ktore by ma postupom casu napadli.

Moja otazka:
Potreboval by som poradit s navrhom, kedze som podobnu aplikaciu neriesil, chcel by som od vas feedback ci nasledujuci design je ok, alebo by ste to riesili inac.

Moja predstava je asi takato. Existovala by poll-microservice ktora by ponukala REST api nad anketami. Takze ak by uzivatel chcel hlasovat, vznikol by POST request prave na tuto sluzbu. Zaznam s hlasom by bol ulozeny do DB, a nasledne propagovany napr. do RabbitMQ.

Na zobrazovanie real-time zmien by bola druha druha sluzba notification-microservice, ktora by pocuvala na spravy z RabbitMQ, a nasledne jednotlive spravy posielala na FE. Postupne ak by pribudli ine featury ktore by mali byt propagovane uzivatelom v realnom case, tak by fungovali obdobne pomocou tejto sluzby.

Este neviem aky protokol na tie real-time spravy z backendu pouzit, rozmyslam nad server-sent events a websocketmi. Vzhladom na design ktory som uviedol, kde existuje samostatna mikrosluzba pre specificku oblast, a nasledne spravy zo servera su posielane inou sluzobou, mi dava vacsi zmysel SSE.

Samozrejme nad sluzbami by som chcel pouzit este zuul a oauth2 securitu. Nejake rady / pripomienky? Dikes.

[Reklama]

[Filip Jirsák]

Je divné nejprve něco zapisovat do databáze a pak to odsud propagovat do fronty. Fronta se používá pro oddělení producenta a konzumenta, takže logický postup by byl opačný – zapsat do fronty, a jedním konzumentem zpráv z fronty může být i databáze.

Spring a mikroslužby nejde moc dohromady, síla Springu je naopak v tom, že můžete mít vše v jednom. Vím, že se Spring snaží tlačit i tímhle směrem, protože je to moderní, ale Spring pro to není a v nejbližší době nebude vhodný nástroj. Buď bych zvolil Spring, a pak bych se z toho nesnažil dělat za každou cenu mikroslužby, nebo bych zvolil mikroslužby, a pak bych si vybral Micronaut (já osobně), nebo třeba Helidon nebo Quarkus.

[schwantner.peter]

Je divné nejprve něco zapisovat do databáze a pak to odsud propagovat do fronty. Fronta se používá pro oddělení producenta a konzumenta, takže logický postup by byl opačný – zapsat do fronty, a jedním konzumentem zpráv z fronty může být i databáze.

Spring a mikroslužby nejde moc dohromady, síla Springu je naopak v tom, že můžete mít vše v jednom. Vím, že se Spring snaží tlačit i tímhle směrem, protože je to moderní, ale Spring pro to není a v nejbližší době nebude vhodný nástroj. Buď bych zvolil Spring, a pak bych se z toho nesnažil dělat za každou cenu mikroslužby, nebo bych zvolil mikroslužby, a pak bych si vybral Micronaut (já osobně), nebo třeba Helidon nebo Quarkus.

Takze poll-mikrosluzba by mala teda mat aj listennera, ktorym tiez tu spravu precita a az vtedy ulozi?

Dalsou z mikrosluzieb mal byt chatovaci modul pod anketou, a ten flow som si predstavoval tak, ze pouzivatel-a posle spravu chat-microservice, ta sa ulozi, uzivatelovi-a viem v tom momente odpovedat na request 200, a vie ze spravu sa podarilo odoslat. Ak by som imeplementoval sposob ktory odporucate, ako informujem uzivatela ze jeho sprava bola odoslana v poriadku?

Tuto technologiu som zvolil preto, ze vsetky projekty u nas mame v springu, takze ak by sa mi podarilo dostat na projekt kde su MS, tak urcite by boli v nom. Kazdopadne urcite pozriem aj odporucane technologie.

[Ondrej Nemecek]

Koncepce, kdy data probublají od uživatele přes brokera až do persistentního storage (databáze) je v pořádku. Pokud by zpracování požadavku selhalo (a bylo to pro uživatele zásadní), musí se to dozvědět taky asynchronně. Mailem, notifikací v prohlížeči, smskou... Ale pokud máte message brokera nastaveného aby byl fail safe, nemělo by k tomu běžně dojít - i při selhání databáze se po jejím nahození zprávy dodatečně obslouží. Na ty mikroframeworky určitě koukněte (Javalite, Microunaut, Quarkus... je jich moc), je to opravdu dost přímočaré na použití a poznáte alternativu.

[schwantner.peter]

Koncepce, kdy data probublají od uživatele přes brokera až do persistentního storage (databáze) je v pořádku. Pokud by zpracování požadavku selhalo (a bylo to pro uživatele zásadní), musí se to dozvědět taky asynchronně. Mailem, notifikací v prohlížeči, smskou... Ale pokud máte message brokera nastaveného aby byl fail safe, nemělo by k tomu běžně dojít - i při selhání databáze se po jejím nahození zprávy dodatečně obslouží. Na ty mikroframeworky určitě koukněte (Javalite, Microunaut, Quarkus... je jich moc), je to opravdu dost přímočaré na použití a poznáte alternativu.

Ok, asynchronne informovanie uzivatela, cize nejak takto? Uzivatel posle spravu na sluzbu-x, vygeneruje sa pre spravu korelacne ID, odpovie sa vrati uzivatelovi. Posle sa sa event do brokera s danym ID, odchyti ho listenner sluzby-x ktora ho ulozi, a posle event, ze sprava s danym korelacnym id bola ulozena, moze sa nasledne o tom informovat aj uzivatel na FE. Ako ale vyhodnotit ze sa spravu ulozit nepodarilo? Ak ziadnu spravu listenner nezachyti, tak ani nemozem o tom uzivatela informovat. Co ak sa napr. z nejakeho dovodu restartuje broker, a uzivatel o tu spravu pride, pretoze nebola pred tym ulozena do DB?

[Reklama]

[alex6bbc]

jak casto se musi notifikovat dalsi strana?
pokud je to jednou za nekolik sekund, tak bych se vyprdl na extra notifikace a staci hlidat databazi.
kdyby si poll strana jednou za cas udelal treba select kolik je novych zaznamu, nebo nejakou hodnotu z tabulky
tak to muze taky v pohode fungovat i bez extra oznamovaciho mechanismu. pokud nejde o mikrosekundy.

[schwantner.peter]

jak casto se musi notifikovat dalsi strana?
pokud je to jednou za nekolik sekund, tak bych se vyprdl na extra notifikace a staci hlidat databazi.
kdyby si poll strana jednou za cas udelal treba select kolik je novych zaznamu, nebo nejakou hodnotu z tabulky
tak to muze taky v pohode fungovat i bez extra oznamovaciho mechanismu. pokud nejde o mikrosekundy.

Chcel by som okamzitu notifikaciu (asi do 1s). To co popisujes je short polling ak sa nemylim?

[alex6bbc]

jde o to kolik technologii chces zapojit, jak to mit co nejjednodussi.
zasadni je synchronizacni mechanismus, zda to bude nejaka async fronta, db, cokoliv.
ale pouzij hvezdici at nemas v grafu sluzeb kruhy.

[schwantner.peter]

jde o to kolik technologii chces zapojit, jak to mit co nejjednodussi.
zasadni je synchronizacni mechanismus, zda to bude nejaka async fronta, db, cokoliv.
ale pouzij hvezdici at nemas v grafu sluzeb kruhy.

O jednoduchost mi velmi nejde, uz teraz mikrosluzby, broker, a pod. na votovaci system je trosku kanon na vrabca. Ide mi len o to pohrat sa s technologiami a architekturou aka by bola pouzita na realnom vacsom projekte.

[Ondrej Nemecek]

Já bych to viděl tak, že pokud chcete mít 100% spolehlivost, potřebujete distribuované transakce. A to je samostatné téma.

Pokud nechcete 100% spolehlivost, končíte s tím, že se požadavek předal systému a že máte brokera nastaveného tak, aby nic neztratil.

[schwantner.peter]

Já bych to viděl tak, že pokud chcete mít 100% spolehlivost, potřebujete distribuované transakce. A to je samostatné téma.

Pokud nechcete 100% spolehlivost, končíte s tím, že se požadavek předal systému a že máte brokera nastaveného tak, aby nic neztratil.

Dakujem, tak co sa tyka toho tak skusim si to nastudovat, a zatial by som to uzavrel s tym, ze ten flow bude nasledovny:

request uzivatela z FE -> poll-microservice (publisher) -> broker -> notfication service (subscriver) -> FE

A to posielanie notifikacii uzivatelovi na FE, pouzili by ste skor SSE alebo websockety? Ak by som uz mal otvoreny ws kanal, tak by zrejme bolo vhodne posielat cez neho aj spravy z FE smerom na server.

[alex6bbc]

stackowerflow:



You app is C/S structure. X app is client, and app manager is Server. You can use DataBase, SendMessage and Socket to communication between S and C.

1. SendMessage/Mailslots/Pipes/File Mapping/Shared Memory

    Advantages: easy to implement
    Disadvantages: C and S should be in the same environment(PC). C and S should be implemented at Windows. And there is no communication history recording.

2. DataBase

    Advantages: C and S can be deployed at different environment and can be implemented by different programming languages. And you communication history can be tracked.
    Disadvantages: need more effort to implement.

3. Socket

    Advantages: C and S can be deployed at different environment and can be implemented by different programming languages.

    Disadvantages: need more effort to implement.

Usually, DB & Socket is for complex communication/logic software design which need history recording. And you can choose SendMessage if your communication is not much complex.

[alex6bbc]

https://en.wikipedia.org/wiki/Inter-process_communication

[Filip Jirsák]

Já bych to viděl tak, že pokud chcete mít 100% spolehlivost, potřebujete distribuované transakce. A to je samostatné téma.

Pokud nechcete 100% spolehlivost, končíte s tím, že se požadavek předal systému a že máte brokera nastaveného tak, aby nic neztratil.

Distribuované transakce nezajistí 100% spolehlivost. Naopak dost zvyšují komplexnost systému. U takhle triviálního systému je jednoduchý způsob, jak zvyšovat spolehlivost – prostě přidávat další uzly a hlas považovat za zapsaný teprve tehdy, když zápis potvrdí víc uzlů.

[tomas88]

Dle meho jsou microservices je velmi komplikovane tema a nemam s tim zadne velke zkusenosti. Myslim, ze neexistuje zadny univerzalni navrh. Jedine mit sirsi prehled o moznostech a pak je pouzit v danem momente. Pokud nemas zkusenosti s RabbitMQ, tak to co navrhujes je asi dobre na seznameni s message brokery, ale o microservices se toho moc nedovis.

Doporucil bych investovat nekolik desitek hodin ke shlednuti prednasek na internetu, napr. youtube - goto conferences. A tam hledat temata jako distribuovane systemy, distrubuovane transakce, message broker, event-driven arch., streamovaci platformy, microservice failures, orchestrace microservices, workflow engines a mnoho dalsiho.