Event sourcing a mikroslužby

[Coati]

Zdar, uměl by někdo vysvětlit, proč/kdy je event sourcing v architektuře založené na mikroslužbách lepší než tradičnější přístupy (REST, různá RPC)? Případně jaký je váš osobní názor na jeho použití v projektech?

Podle zastánců poskytuje relativní nezávislost (například na konkrétním jazyce), ale to platí pro většinu RPC také. Navíc někde musí běžet server a databáze pro zpracování a uložení událostí, s čímž se pojí nezanedbatelná režie.

[Reklama]

[alex6bbc]

ted jsem si o tom neco cetl.
event sourcing pouzijes, kdyz potrebujes log vsech eventu co se udaly na overeni konzistence systemu (db, ulozena data, stav aplikace). diky write-only event logu lze krokovat do minulosti stav systemu.

pekny popis zde, i kdyz je tohle pro javu, je to obecne:
https://www.baeldung.com/cqrs-event-sourcing-java

[pepa-vomacka]

Hezky je to vysvětlene zde
https://youtu.be/NY9spSccR-0

[_Tomáš_]

Raději to řeknu na úvod, Kafka není event sourcing.

Event sourcing je důležitý, když potřebuji zpracovávat operace konzistentně, když mi z jedné události při zpracování vznikne více samostatných a potřebuji je mít pod kontrolou jako celej (typickej příklad je příkaz k úhradě, kdy potřebuji provést operace na dvou účtech najednou a nechci nikdy, aby se mi rozdělily). Tohle zajistit v REST rozhraní je vždy problém, sice mohu mít bulk transakce, ale jakmile je jedna strana příjme, už se informace o tom, že pocházejí z jedné a které operace ztratí.

Na RPC nebo REST potřebuješ, aby obě strany byly zároveň v provozu a aby všechny strany tu operaci v pořádku dokončily, to ne vždy je vhodné a nebo realizovatelné. Event sourcing mi umožní transakce zpracovávat asynchronně a zpětně. Jak tady psali předřečníci, ukazuje mi vždy konzistentní čas kdykoliv čase, mohu se pohybovat na časový ose, což se hodí pro zálohy, obnovování ze záloh nebo migrace. Je pak možné se např. po nasazení chybné aplikace vrátit a provést transformace opravenou verzí aplikace.

Pro většinu aplikací může být tohle ale příliš komplexní a zbytečně složité.

Používali jsme třeba u velkých eshopů, kdy chtějí mít přesnou skladovou evidenci a vznikl objednávky znamená, že potřebuji zároveň i pohlídat jednotlivé skladové účty v jednotlivých skladech a přitom nechci mít jednu velkou centralizovanou databázi, jak to má řešený náš největší eshop.

[luvar]

Ono je eventsourcing a RPC nieco celkom ineho. RPC je imho "volanie vzdielenj procedury" a eventsourcing je spôsob spracovávania biznis požiadaviek. Eventsourcing môže byť imho implementovaný i cez rest, či rpc (aj keď rest - ako ho chápe väčšina ľudí, a REST podľa autora pôvodného výrazu sú dve značne odpišné veci).

Skúsim ale popísať eventsourcing z pohľadu ekosystému/aplikácií CQRS (Command Query Responsibility Segregation) a ES (event sourcing). Ak sa nemýlim, nemusia byť nevyhnutne spolu tieto spôsoby spracovania požiadaviek.

Užívateľ otvorí web. Nejaká mikroslužba, ktorá si číta ES log (databáza, alebo kafka napríklad), si vytvára z C (commands) aktuálny stav sveta (napríklad načíta commandy: VytvorUžívateľa(124, Fero, Mrkva, 14.3.1999); PripíšNaKonto(124, 13, CZK); VytvorObjednavku(66544, 124, .... ). Daná mikroslužba dostane request na stav konta usera 124. Šáhne do svojej privátnej databázy, kde si robí "cache" a odpovie aktuálnou hodnotou, 13 CZK.

Popri tom iní tím (v inom jazyku ideálne, nech je sranda) nakódi inú mikroslužbu a spustí ju. Mikroslužba si prebehne všetky commandy a vytvorí si svoju "cahce". Keď sa jej niekto spýta na stav konta užívateľa 124, odpovie "0.53€".

Výhoda, že kedykoľvek spravím novú verziu služby, tak po spustení mám vlastnú databázu (cache). Keď zmením logiku spracovania (aplikovania komandov na cache/view), môžem aplikáciu reštartnúť a spraovať celú históriu nanovo.

Obdobne je výhodou, že pri škálovaní postačuje štartnúť ďalšie inštancie aplikácie a tie si budú vytvárať svoje databázky. Je možné odboku vyvinúť službiu poskytujúcu dáta v inom formáte, alebo celkom iné dáta.

Nevýhoda je, že CQRS je asynchrónne. Teda web zavolá rest službu "nahraj mi kredit 10 CZK" a keď zavoláte hneď za tým rest pre získanie kreditu, môže (a bude zväčša) tam stará hodnota. Je to preto, že cqrS -> segregation. Pripísanie kreditu (rest volanie napríklad) blokuje a odpovedá až keď je command zapísaný do ES. To ale nič neznamená a rest volanie nedá odpoveď typu "outcome" z toho commandu. Odpoveďou je maximálne, že sa podarilo zapísať do ES. Po zapísaní komandu do es, sa niekde nejaký processor chytí a spracuje command a "vykoná ho". Teda do svojej súkromnej databázky si updatne riadok s aktuálnym balancom. Získanie stavu konta tak "vidí" túto novú hodnotu až po zapísaní zmeny do databázy (niektoré služby majú len in-memorry DB a pri reštarte si prebehnú "kompletný" ES). Táto vlastnosť sa označuje ako eventual consistency. Občas to kopne poriadne, keď sa človek nezamyslí dostatočne.

PS: ES má okrem samotného logu zvačša aj "snapshot" časť, kde sa "grupujú" samotné commandy. Teda napríklad pre stav konta sa komandy "+1";"+15";"-3" môžu grupnúť do "sum:13". Zrýchluje to štart a umožňuje zmenovanie es logu.

Viac ma narychlo nenapadá, bo som už 3 roky mimo tejto reality. Bola to ale zaujímavá skúsenosť.

[Reklama]