Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: schwantner.peter 01. 05. 2020, 18:17:33

Název: Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 01. 05. 2020, 18:17:33
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Filip Jirsák 01. 05. 2020, 19:16:03
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 01. 05. 2020, 19:34:14
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Ondrej Nemecek 01. 05. 2020, 19:55:45
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 01. 05. 2020, 20:04:04
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?
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 01. 05. 2020, 20:32:18
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 01. 05. 2020, 21:02:27
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?
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 01. 05. 2020, 21:09:51
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 01. 05. 2020, 21:32:17
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Ondrej Nemecek 01. 05. 2020, 23:13:03
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 01. 05. 2020, 23:42:42
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 01. 05. 2020, 23:46:11
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 01. 05. 2020, 23:54:31
https://en.wikipedia.org/wiki/Inter-process_communication
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Filip Jirsák 02. 05. 2020, 09:49:13
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ů.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: tomas88 02. 05. 2020, 13:06:54
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.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Ondrej Nemecek 02. 05. 2020, 13:10:48
Distribuované transakce nezajistí 100% spolehlivost.

Měl jsem za to, že transakce zajistí transakční chování, tj. jistotu o stavu (+ jeho granularitu).  To je +- to, na co se tazatel ptal. Zda je to 100% spolehlivost nevím, protože nejsme dohodnuti na tom, co se tím výrazem myslí.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 02. 05. 2020, 16:48:03
Co poviete na tento model?

Pouzivatel bude POSTom posielat requesty na konkretne mikrosluzby, ci uz to bude chat, poll, alebo cokolvek ine. Budu to jednoduche requesty ktore ulozia data do DB, takze nebude problem na zaklade response status notifikovat uzivatela o tom, ci sprava bola v poriadku prijata. Po ulozeni dat do DB, sa posle event o prijati novych dat, ktory odchyti notifikacna mikrosluzba, na ktoru budu pouzivatelia napojeni cez WS alebo SSE, a posle spravu FE aplikacii. Po tom ako FE obdrzi event ze su k dispozicii nove data, spravi FE klasicky GET.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 18:57:20
Myslím, že zbytečně vymýšlíš složitosti.

Použij redundantní Kafku (3 nody) a soustřeď se na to, abys do ní data dostal co nejdřív - tj. na začátku pajplajny budeš mít co nejjednodušší službu, která bude data jenom přehazovat do Kafky. Tím se sníží možnost selhání na minimum. A jakmile máš data v Kafce, s naprosto dostatečnou* jistotou už o ně nepřijdeš. Čili žádný potvrzování nemusíš řešit, pokud vyloženě nechceš (třeba abys uživateli ukázal ticker "doručeno").

Všechny další komponenty systému budou komunikovat přes Kafku, takže je můžeš beze strachu restartovat jak je libo. Že se nic neztratí, ti už Kafka zabezpečí (pokud ji správně použiješ).

Ke komunikaci s FE použij jenom websockety. Oznámit přes websockety událost a pak data načítat klasicky nedává žádný smysl. Datový kanál už máš, tak ho použij, ne? :)

Pro napojení Kafky na websockety řešení existují, programovat to nemusíš.

* nebavíme se o službě, na které závisí lidské životy apod., žejo ;)
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Google CTCCTCGGCGGGCACGTAG 02. 05. 2020, 19:04:01
Amazon SQS nebo Yandex Message Queue
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Google CTCCTCGGCGGGCACGTAG 02. 05. 2020, 19:07:25
Ke komunikaci s FE použij jenom websockety. Oznámit přes websockety událost a pak data načítat klasicky nedává žádný smysl. Datový kanál už máš, tak ho použij, ne? :)

dává to smysl, je to bezestavové. Websockety na notifikace, data tahat přes API.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 02. 05. 2020, 19:11:10
Citace
A jakmile máš data v Kafce, s naprosto dostatečnou* jistotou už o ně nepřijdeš. Čili žádný potvrzování nemusíš řešit, pokud vyloženě nechceš (třeba abys uživateli ukázal ticker "doručeno").

Všechny další komponenty systému budou komunikovat přes Kafku, takže je můžeš beze strachu restartovat jak je libo. Že se nic neztratí, ti už Kafka zabezpečí (pokud ji správně použiješ).

1) Co ak sa restartuje Kafka? Nepride o data ktore definovali komu ma aka sprava ist?

2) Kde v tomto modeli by si riesil ukladanie dat do db aby bolo mozne prehliadanie historie?

Dik
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 02. 05. 2020, 19:12:18
Ke komunikaci s FE použij jenom websockety. Oznámit přes websockety událost a pak data načítat klasicky nedává žádný smysl. Datový kanál už máš, tak ho použij, ne? :)

dává to smysl, je to bezestavové. Websockety na notifikace, data tahat přes API.

Trosku som sharlockoval a podobny mechanizmus vraj pouziva FB
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 19:18:32
1) Co ak sa restartuje Kafka?
Proto je jich tam víc. Můžeš se sám rozhodnout, pád kolika z nich budeš chtít přežít. Je to stejné jako RAID u disků.

2) Kde v tomto modeli by si riesil ukladanie dat do db aby bolo mozne prehliadanie historie?
Stejně, jak to psal nějaký kolega výš: jeden z Kafka clientů je zapisovač do DB.

Trosku som sharlockoval a podobny mechanizmus vraj pouziva FB
Já bych byl velmi opatrný s tím, používat nějakou technologii nebo postup, protože ji používá [nějaký velký hráč]. Ten [velký hráč] pro to má nějaké důvody, které můžou být velmi specifické a v podmínkách [jakýkoliv menší hráč] nesplnitelné. (just my 2c)
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 19:20:11
dává to smysl, je to bezestavové. Websockety na notifikace, data tahat přes API.
A v čem je výhoda oproti tomu, když data přímo přilepím k tomu eventu?

Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Google CTCCTCGGCGGGCACGTAG 02. 05. 2020, 19:21:05
Ke komunikaci s FE použij jenom websockety. Oznámit přes websockety událost a pak data načítat klasicky nedává žádný smysl. Datový kanál už máš, tak ho použij, ne? :)

dává to smysl, je to bezestavové. Websockety na notifikace, data tahat přes API.

Trosku som sharlockoval a podobny mechanizmus vraj pouziva FB

používá se to často, pokud máte odladěné API není důvod implementovat stejné funkce přes websockety
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 19:21:41
pokud máte odladěné API
Což tazatel nemá.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 02. 05. 2020, 19:35:45
Citace
2) Kde v tomto modeli by si riesil ukladanie dat do db aby bolo mozne prehliadanie historie?
Stejně, jak to psal nějaký kolega výš: jeden z Kafka clientů je zapisovač do DB.

Moze byt microservice ktora posiela spravu do kafky zaroven klientom ktory spravu precita a ulozi? Snazim sa si to predstavit na priklade ako som spominal (napr. chat-microservice).

1. Pride POSTom nova sprava do mikrosluzby chat-service
2. Ihned sa sprava preposle do kafky na spracovanie.
3. Az pride sprava v kafka na rad, precita si ju chat-service, a ulozi do DB. Po ulozeni sa posle do kafky sprava v novom evente urcenom pre notification-service, ktora posle websocketom spravu na FE.

Ten medzikrok mi dava zmysel v tom, ze prijemcovi by mala ist iba ulozena sprava, a nestalo sa to, ze nahodou mu bola dorucena sprava, ktora pri ulozeni zlyhala, takze az si refreshne prehliadac, tak uz ju tam neuvidi. Je to takto ok?

Ak ano, tak stale sa neviem uplne stotoznit s tym, preco je zly pristup spravu klasicky ulozit do Db, a nasledne propagovat brokerom dalej. Pride mi to ako zbytocny krok.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: tomas88 02. 05. 2020, 20:24:39
Ak ano, tak stale sa neviem uplne stotoznit s tym, preco je zly pristup spravu klasicky ulozit do Db, a nasledne propagovat brokerom dalej. Pride mi to ako zbytocny krok.

Ono zalezi na tom jak si jednotlive services definujes. Co bude jejich zodpovednost. Pokud se o historii chatu bude starat ta sama service, co prijala novou zpravu, tak je sumak, co se stane prvni. Jestli nejdrive ulozis do database nebo posles event do brokera. Jestli se o historii bude starat samostatna service, tak ani jinou moznost, nez to nejdrive poslat na brokera nemas. Jednotlive services by si nemeli sahat vzajemne na data.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 02. 05. 2020, 20:33:43
Ak ano, tak stale sa neviem uplne stotoznit s tym, preco je zly pristup spravu klasicky ulozit do Db, a nasledne propagovat brokerom dalej. Pride mi to ako zbytocny krok.

Ono zalezi na tom jak si jednotlive services definujes. Co bude jejich zodpovednost. Pokud se o historii chatu bude starat ta sama service, co prijala novou zpravu, tak je sumak, co se stane prvni. Jestli nejdrive ulozis do database nebo posles event do brokera. Jestli se o historii bude starat samostatna service, tak ani jinou moznost, nez to nejdrive poslat na brokera nemas. Jednotlive services by si nemeli sahat vzajemne na data.

Presne ako hovoris, ak by sa o historiu a ukladanie starala ina sluzba, vedel by som si to predstavit ze konzumuje spravy z kafky a uklada. Ale ak bude dana mikrosluzba obstaravat danu domenu, cize chat, nedava mi velmi zmysel posielat ju do Kafku aby som si ju potom aj v tej istej sluzbe odchytil.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: luvar 02. 05. 2020, 21:43:18
Na zaklade mojich skusenosti odporucam:

Moj hruby navrh by bol nasledovny (CQRS pristup):

PS: Pocitat s tym, ze kazda nova technologia ma nejaku krivku ucenia; ma nejake pouzitie a nejake charakteristiky... Napriklad RabbitMQ nie je vhodny na klonovanie sprav (jedna queue a na nu zavesene stovky fanout kanalov). Kafka nie je vhodna ako nahrada vseobecnej databazy, aj ked nou moze byt (a za istych predpokladou aj efektivna).
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 21:45:53
Presne ako hovoris, ak by sa o historiu a ukladanie starala ina sluzba, vedel by som si to predstavit ze konzumuje spravy z kafky a uklada. Ale ak bude dana mikrosluzba obstaravat danu domenu, cize chat, nedava mi velmi zmysel posielat ju do Kafku aby som si ju potom aj v tej istej sluzbe odchytil.
Jak rika Tomas, sluzby maji nejake zodpovednosti, maji neco za ukol. A ty ukoly by mely byt rozdelene tak, aby to cely davalo nejaky smysl. Microservices jsou "micro" prave proto, ze se ty zodpovednosti udrzuji male a dobre definovane. Tj. pokud k tomu neni zadny zavazny duvod, nemely by se kombinovat tak, jak o tom pises.

Konkretni priklad: neni "chat-service, ktera zpravu ulozi do DB", je service "db writer", ktera zpravy z Kafky cte a zapisuje do DB, nic jineho nedela. Jina service muze treba zpravy cist a routovat ke spravnemu uzivateli.

Proste, predstav si to jako nekolik lidi, kazdy dela neco konkretniho, jasne definovaneho, zpravy si predavaji pres Kafku a dohromady cely ten system dela to, co po nem chces.

Jak rika okridlena veta, "as simple as it can be but not simpler".
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: BoneFlute 02. 05. 2020, 22:23:51
dává to smysl, je to bezestavové. Websockety na notifikace, data tahat přes API.
A v čem je výhoda oproti tomu, když data přímo přilepím k tomu eventu?
Push versus Pull ?

Eventem mi přijde maličká zpráva se stavem, že se to podařilo. A já se (jako konzument) mohu rozhodnout kdy, jaké a jak chci data získat. Nemusím mu to říkat předem. Natož aby to bylo zadrátované do protokolu.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 22:32:02
Eventem mi přijde maličká zpráva se stavem, že se to podařilo. A já se (jako konzument) mohu rozhodnout kdy, jaké a jak chci data získat. Nemusím mu to říkat předem. Natož aby to bylo zadrátované do protokolu.
To ale nemluvíš o tom, na co se tazatel ptá, ne? Páč u chatu je asi celkem jasné, že chci dostávat všechny zprávy z místností, kde jsem, ne? Tam moc není prostor si nějak vybírat, co chci a nechci pullnout.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: BoneFlute 02. 05. 2020, 22:41:47
Eventem mi přijde maličká zpráva se stavem, že se to podařilo. A já se (jako konzument) mohu rozhodnout kdy, jaké a jak chci data získat. Nemusím mu to říkat předem. Natož aby to bylo zadrátované do protokolu.
To ale nemluvíš o tom, na co se tazatel ptá, ne? Páč u chatu je asi celkem jasné, že chci dostávat všechny zprávy z místností, kde jsem, ne? Tam moc není prostor si nějak vybírat, co chci a nechci pullnout.
Pochopil jsem to tak, že experimentuje, tak jsem si říkal, že Pull je obecnější. Na začátku to byla anketa, teď mluví o chatu, předem avizoval, že tam bude přidávat kde co...
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 22:47:53
Pochopil jsem to tak, že experimentuje, tak jsem si říkal, že Pull je obecnější. Na začátku to byla anketa, teď mluví o chatu, předem avizoval, že tam bude přidávat kde co...
Ja mam jenom trochu obavu, aby novacek nebyl z tech mistnich rad zmatenej a nenabyl dojmu, ze je super napad udelat chat tak, ze zpravu probubla pres deset microservis, na konci ulozi do databaze, na ni navesi obecnej hlidac zmen v databazi, ten posle event na frontend pres long poll a FE si sahne pres rest api pro ten dvacitabajtovej string, kterej mohla v pohode poslat prvni nebo druha microservice...

...a jeste bude mit pocit, ze to je supermoderni design, protoze to tak dela Facebook :)
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 02. 05. 2020, 23:01:23
Ja mam jenom trochu obavu, aby novacek nebyl z tech mistnich rad zmatenej a nenabyl dojmu, ze je super napad udelat chat tak, ze zpravu probubla pres deset microservis, na konci ulozi do databaze, na ni navesi obecnej hlidac zmen v databazi, ten posle event na frontend pres long poll a FE si sahne pres rest api pro ten dvacitabajtovej string, kterej mohla v pohode poslat prvni nebo druha microservice...
...a jeste bude mit pocit, ze to je supermoderni design, protoze to tak dela Facebook :)

souhlasim, seniorita/zkusenost je v tom, ze se pouzije co nejmene rozumnych technologii, aby to fungovalo, aby se to dalo administrovat, aby z toho nevznikla jaderna elektrarna.
znam lidi, kteri vsechno programovali pro TeX, pro XML/XSLT, VB makra pro excel, technologii je milion, ale je zbytecne jich milion pouzit. 
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: schwantner.peter 02. 05. 2020, 23:07:50
Citace
Konkretni priklad: neni "chat-service, ktera zpravu ulozi do DB", je service "db writer", ktera zpravy z Kafky cte a zapisuje do DB, nic jineho nedela. Jina service muze treba zpravy cist a routovat ke spravnemu uzivateli.

Nebudu toto az privelmi male mikrosluzby? Cital som nejaky blog o navrhu mikrosluzieb, a kazda ms by mala riesit konkretny typ uloh (comu odpoveda tvoj navrh), ale zaroven by kazda z nich mala mat aj svoju DB, a v pripade, ze jedna sluzba nemoze fungovat bez druhej, nejedna sa o dobry navrh.

A toto mi pride ako presne tento pripad, pretoze ak writer zapisuje do svojej DB, tak reader nemoze nic precitat a posielat bez toho aby sa neustale dopytaval na data od writera. Cize by som to skor videl ako jednu sluzbu.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 02. 05. 2020, 23:21:59
ja uz jsem si driv rikal, ze jsou dneska popularni ruzne mikro kraviny.
jestli by nebylo nejlepsi udelat webovou aplikaci jako jeden C/C++ modul do nginx.
nginx by zajistoval webovou sluzbu, ale generovani grafickeho rozhrani (html) a i logiku uvnitr by mel na starosti
jeden kod v C/C++.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 02. 05. 2020, 23:22:28
Nebudu toto az privelmi male mikrosluzby? Cital som nejaky blog o navrhu mikrosluzieb, a kazda ms by mala riesit konkretny typ uloh (comu odpoveda tvoj navrh), ale zaroven by kazda z nich mala mat aj svoju DB, a v pripade, ze jedna sluzba nemoze fungovat bez druhej, nejedna sa o dobry navrh.

A toto mi pride ako presne tento pripad, pretoze ak writer zapisuje do svojej DB, tak reader nemoze nic precitat a posielat bez toho aby sa neustale dopytaval na data od writera. Cize by som to skor videl ako jednu sluzbu.
Hele, já mám trochu blbou zkušenost s takovýmahle poučkama. To je stejný jako když si někdo z agile vezme, že se musí dělat standupy. Ne, nemusí se dělat standupy, to přece není cíl. Ty standupy mají v nějakým systému nějakou úlohu. A ten systém má (ideálně ;) ) nějakou vnitřní logiku, do které to musí zapadnout.

A tady to máš stejný. Vyprdni se na poučky tohodle typu. Zaměř se na to, co tvůj systém má plnit za funkce. Navrhni nejjednodušší možnou cestu k cíli. Nevymýšlej narovnáváky na ohýbáky, protože jsi někde četl, že každá microslužba musí mít ohýbák, jinak to není mikroslužba.

Takže já bych doporučil tuhle stupidní, selskou úvahu: tvůj systém je nějaká posloupnost krabiček, do každé krabičky leze A a ven z ní leze B. Proč v systému vůbec tu krabičku máš? No protože nutně potřebuješ dostat B! Nebo nepotřebuješ? No tak ji vyhoď. Potřebuješ znát změny v databázi? Ne, nepotřebuješ. Potřebuješ doručit správný zprávy správným klientům.  O to ti jde. Je zjišťování změn v DB fakt ta nejpřímočařejší cesta k tomuhle cíli? No nevím, spíš bych o tom pochyboval...

Potřebuje služba S databázi? Na to je jednoduchá odpověď: když z A dělá B, potřebuje k téhle operaci znát předchozí Ačka? Ano? Jsi si tím stoprocentně jistý? Umíš vyargumentovat, proč to z principu jinak nejde? Ok, potom teda máš stavovou službu a ta fakt nějaké úložiště potřebuje. Možná DB. Možná stačí soubor na disku. Možná tabulka v paměti. Možná že z minulých Aček si jí stačí zapamatovat si jedno číslo (např. nějaký průměr něčeho).

Každopádně kdykoli dospěješ k názoru, že tahle služba je stavová, desetkrát si promysli, jestli jdeš správnou cestou, protože bezestavové služby jsou vždycky jednodušší na správu i programování.

(to bylo jenom tak Q.E.D.)
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: alex6bbc 03. 05. 2020, 00:09:00
nebudu tu kopirovat cely text.
souhlas s prymek. kdysi jsme si hrali se vsema moznyma knihovnama, jazykama, systemama.
dneska na to nikdo nemam cas, takze pouzij jen nejnutnejsi veci.
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: BoneFlute 03. 05. 2020, 00:13:54
nebudu tu kopirovat cely text.
souhlas s prymek. kdysi jsme si hrali se vsema moznyma knihovnama, jazykama, systemama.
dneska na to nikdo nemam cas, takze pouzij jen nejnutnejsi veci.

Jestli ona vám neunikla ta původní tazatelova motivace? Co? Ne?
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Ondrej Nemecek 03. 05. 2020, 00:15:29
Pokud jde o realtime chat, mohou se ty zprávy předávat brokerovi a z něj rovnou zase číst a přeposílat klientům zpět, zápis do databáze bych navěsil jen kvůli dlouhodobé persistenci. Takže v podstatě jedna služba pro zápis zpráv od klienta na server, druhá na rozposílání nových zpráv členům chatu a  třetí na ukládání do historie. Jako hrubý nástřel IMHO vyhovující. Pak něco na registraci, přihlášení, vytvoření místnosti, stažení seznamu místností apod. Tam se ale bude už jen sledovat podobná logika. Tak bych to viděl já.

Zda bude server komunikovat s browserem přes websockety nebo long pooling je relativně detail, ale použil bych hotovou knihovnu, jinam budete muset řešit různé ztráty spojení, nepodporu websocketů apod., což za vás hotová knihovna vyřeší (websocket není nějaké automaticky garatované spojení - tedy pokud se něco nezměnilo od té doby co jsem to používal).
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: Mirek Prýmek 03. 05. 2020, 00:26:09
Pokud jde o realtime chat, mohou se ty zprávy předávat brokerovi a z něj rovnou zase číst a přeposílat klientům zpět, zápis do databáze bych navěsil jen kvůli dlouhodobé persistenci. Takže v podstatě jedna služba pro zápis zpráv od klienta na server, druhá na rozposílání nových zpráv členům chatu a  třetí na ukládání do historie. Jako hrubý nástřel IMHO vyhovující. Pak něco na registraci, přihlášení, vytvoření místnosti, stažení seznamu místností apod. Tam se ale bude už jen sledovat podobná logika. Tak bych to viděl já.
:thumbsup:

Zda bude server komunikovat s browserem přes websockety nebo long pooling je relativně detail, ale použil bych hotovou knihovnu, jinam budete muset řešit různé ztráty spojení, nepodporu websocketů apod., což za vás hotová knihovna vyřeší (websocket není nějaké automaticky garatované spojení - tedy pokud se něco nezměnilo od té doby co jsem to používal).
Ještě bych k tomu možná dodal, že bych tu technologii (hlavně na serverové straně) vybíral obezřetně. Jsou systémy, které byly dlouhé roky typický CRUD, mají to v morku kostí, a pak tam někdo nějak dobastlil websockety. Chce to něco spíš modernějšího, kde se se streamovým přístupem počítalo od začátku.

P.S. jenom taková drobnost: je to "polling" od "poll", ne od "pool" (píšu to jenom proto, že už se to tady mihlo podruhé :) )
Název: Re:Microservice architektura pre real-time aplikaciu
Přispěvatel: pettan93 04. 05. 2020, 12:25:39
Doporučuji v rámci studia ohledně microservices shlédnout tento konkrétní talk :-)

10 Tips for failing badly at Microservices by David Schmitz
https://www.youtube.com/watch?v=X0tjziAQfNQ

Přednášející jede na sarkastické vlně a je skvělej. Zároveň se mu daří dobře předat myšlenky.