Microservice architektura pre real-time aplikaciu

[Ondrej Nemecek]

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í.

[Reklama]

[schwantner.peter]

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.

[Mirek Prýmek]

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

[Google CTCCTCGGCGGGCACGTAG]

Amazon SQS nebo Yandex Message Queue

[Google CTCCTCGGCGGGCACGTAG]

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.

[Reklama]

[schwantner.peter]

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

[schwantner.peter]

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

[Mirek Prýmek]

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)

[Mirek Prýmek]

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?

[Google CTCCTCGGCGGGCACGTAG]

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

[Mirek Prýmek]

pokud máte odladěné API

Což tazatel nemá.

[schwantner.peter]

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.

[tomas88]

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.

[schwantner.peter]

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.

[luvar]

Na zaklade mojich skusenosti odporucam:

• investovat cas do zhliadnutia par videi (gootgle, infoq, ci veci ako cap theorem ak chcete ist do hlbky a kus mimo)
• ked daco pride, neukladat veci na dve miesta. proste niekto je pan a ten je jediny a hlavny (ci uz kafka, pulsar, postgresql, ....). Usetrite o rad problemov
• Ak je legacy system, co uklada do DB, alebo mate DB oblubenu a nasledne chcete na db integrovat notifikacnu sluzbu napriklad, tak su viacere moznosti. Bud si notifikacna sluzba bude kontrolovat DB a jej nov veci (a to kazda integracia na DB), alebo pouzijete preklapac vesmiru ako napriklad debezium a ten vam bude robit event stream priamo zo zmien v DB (zurnalovy log konvertovany do json-u). Aj taketo veci sa robia a maju obcas vyznam
• Imho za zamyslite vo vyslednej architekture nad tym, kolko resourcou spalite kvoli beznemu usecasu a kvoli comu. Teda pocet poslanych sprav, pocet serializovani a deserializovani, pocet read selektov, insertov a podobne. Nech to dava zmysel.

Moj hruby navrh by bol nasledovny (CQRS pristup):

• sluzba voter -> prijme hlas a ulozi do apache pulsar-u (kafky pripadne)
• sluzba pushNotificator -> zavesi sa pri starte na pulsar/kafku a ked cez websocket (alebo SSE - server side events; alebo long pool, ci iny ekvivalent bude klientom, co sa prihlasia o odber, davat vediet zmeny, prisle spravy, info o prihlaseni/odhlaseni userov a podobne)
• sluzba chat -> uklada spravy do perzistentnej queue (pulsar/kafka)
• sluzba chat history -> subscribe na pulsar/kafku, perzistovanie do lokalnej DB (denormalizovane spravy, kludne kusy html kodu skomprimovane a pripravene na poslanie klientovi). Api pre ziskanie historie a aj api pre aktualne ziskavanie novych prispevkov z chat-u (websocker/SSE)

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).