reklama

Microservice architektura pre real-time aplikaciu

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #30 kdy: 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".

reklama


BoneFlute

  • *****
  • 1 418
    • Zobrazit profil
Re:Microservice architektura pre real-time aplikaciu
« Odpověď #31 kdy: 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.

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #32 kdy: 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.

BoneFlute

  • *****
  • 1 418
    • Zobrazit profil
Re:Microservice architektura pre real-time aplikaciu
« Odpověď #33 kdy: 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...

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #34 kdy: 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 :)

reklama


Re:Microservice architektura pre real-time aplikaciu
« Odpověď #35 kdy: 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. 

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #36 kdy: 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.

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #37 kdy: 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++.

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #38 kdy: 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.)

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #39 kdy: 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.

BoneFlute

  • *****
  • 1 418
    • Zobrazit profil
Re:Microservice architektura pre real-time aplikaciu
« Odpověď #40 kdy: 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?

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #41 kdy: 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).

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #42 kdy: 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é :) )

Re:Microservice architektura pre real-time aplikaciu
« Odpověď #43 kdy: 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.


 

reklama