Čau Habr!
Pripomíname, že po knihe o sme vydali nemenej zaujímavé dielo o knižnici .
Komunita zatiaľ len spoznáva limity tohto mocného nástroja. Nedávno teda vyšiel článok, ktorého preklad by sme vám radi predstavili. Autor z vlastnej skúsenosti hovorí, ako premeniť Kafka Streams na distribuované úložisko dát. Užívať si čítanie!
Knižnica Apache celosvetovo používané v podnikoch na spracovanie distribuovaného toku na vrchole Apache Kafka. Jedným z nedocenených aspektov tohto rámca je, že vám umožňuje ukladať lokálny stav vytvorený na základe spracovania vlákien.
V tomto článku vám prezradím, ako sa našej spoločnosti podarilo ziskovo využiť túto príležitosť pri vývoji produktu pre bezpečnosť cloudových aplikácií. Pomocou Kafka Streams sme vytvorili zdieľané stavové mikroslužby, z ktorých každá slúži ako chybový a vysoko dostupný zdroj spoľahlivých informácií o stave objektov v systéme. Pre nás je to krok vpred z hľadiska spoľahlivosti a jednoduchosti podpory.
Ak máte záujem o alternatívny prístup, ktorý vám umožní využívať jedinú centrálnu databázu na podporu formálneho stavu vašich objektov, prečítajte si ho, bude to zaujímavé...
Prečo sme si mysleli, že je čas zmeniť spôsob, akým pracujeme so zdieľaným štátom
Potrebovali sme udržiavať stav rôznych objektov na základe správ agentov (napríklad: bola stránka napadnutá)? Pred migráciou na Kafka Streams sme sa pri správe štátu často spoliehali na jednu centrálnu databázu (+ API služby). Tento prístup má svoje nevýhody: Udržanie konzistentnosti a synchronizácie sa stáva skutočnou výzvou. Databáza sa môže stať prekážkou alebo môže skončiť a trpí nepredvídateľnosťou.
Obrázok 1: Typický split-state scenár pred prechodom na
Kafka a Kafka Streams: agenti komunikujú svoje názory cez API, aktualizovaný stav sa počíta cez centrálnu databázu
Zoznámte sa s Kafka Streams, vďaka čomu je jednoduché vytvárať zdieľané štátne mikroslužby
Asi pred rokom sme sa rozhodli dôkladne pozrieť na naše scenáre zdieľaného stavu, aby sme tieto problémy vyriešili. Okamžite sme sa rozhodli vyskúšať Kafka Streams – vieme, aký je škálovateľný, vysoko dostupný a odolný voči chybám, akú má bohatú streamovaciu funkcionalitu (transformácie vrátane stavových). Presne to, čo sme potrebovali, nehovoriac o tom, aký vyspelý a spoľahlivý sa v Kafke stal systém zasielania správ.
Každá zo stavových mikroslužieb, ktoré sme vytvorili, bola postavená na inštancii Kafka Streams s pomerne jednoduchou topológiou. Pozostával z 1) zdroja 2) procesora s trvalým úložiskom kľúč-hodnota 3) umývadla:
Obrázok 2: Predvolená topológia našich inštancií streamovania pre stavové mikroslužby. Všimnite si, že je tu aj úložisko, ktoré obsahuje plánovacie metadáta.
V tomto novom prístupe agenti vytvárajú správy, ktoré sa vkladajú do zdrojovej témy, a spotrebitelia – povedzme služba oznamovania pošty – prijímajú vypočítaný zdieľaný stav cez umývadlo (výstupná téma).
Obrázok 3: Nový príklad toku úloh pre scenár so zdieľanými mikroslužbami: 1) agent vygeneruje správu, ktorá dorazí ku Kafkovej zdrojovej téme; 2) mikroslužba so zdieľaným stavom (pomocou Kafka Streams) ho spracuje a vypočítaný stav zapíše do finálnej Kafkovej témy; po ktorej 3) spotrebitelia akceptujú nový stav
Hej, tento vstavaný obchod s kľúčmi a hodnotami je skutočne veľmi užitočný!
Ako je uvedené vyššie, naša topológia zdieľaného stavu obsahuje úložisko kľúč-hodnota. Našli sme niekoľko možností jeho využitia a dve z nich sú popísané nižšie.
Možnosť č. 1: Na výpočty použite úložisko párov kľúč – hodnota
Náš prvý kľúč – hodnota obsahoval pomocné údaje, ktoré sme potrebovali na výpočty. Napríklad v niektorých prípadoch bol zdieľaný štát určený princípom „väčšinových hlasov“. Úložisko môže uchovávať všetky najnovšie správy agentov o stave nejakého objektu. Potom, keď sme dostali novú správu od jedného alebo druhého agenta, mohli sme ho uložiť, získať správy od všetkých ostatných agentov o stave toho istého objektu z úložiska a zopakovať výpočet.
Obrázok 4 nižšie ukazuje, ako sme vystavili úložisko kľúča/hodnoty metóde spracovania procesora, aby sa potom mohla spracovať nová správa.
Obrázok 4: Otvárame prístup k úložisku kľúč-hodnota pre metódu spracovania procesora (potom musí každý skript, ktorý pracuje so zdieľaným stavom, implementovať metódu doProcess)
Možnosť č. 2: Vytvorenie CRUD API nad Kafka Streams
Po vytvorení základného toku úloh sme sa začali pokúšať napísať RESTful CRUD API pre naše zdieľané stavové mikroslužby. Chceli sme mať možnosť získať stav niektorých alebo všetkých objektov, ako aj nastaviť alebo odstrániť stav objektu (užitočné pre podporu backendu).
Aby sme podporili všetky rozhrania Get State API, vždy, keď sme potrebovali prepočítať stav počas spracovania, uložili sme ho na dlhú dobu do vstavaného úložiska kľúč-hodnota. V tomto prípade je celkom jednoduché implementovať takéto API pomocou jedinej inštancie Kafka Streams, ako je uvedené v zozname nižšie:
Obrázok 5: Použitie vstavaného úložiska kľúč-hodnota na získanie vopred vypočítaného stavu objektu
Aktualizácia stavu objektu cez API je tiež jednoduchá na implementáciu. V podstate všetko, čo musíte urobiť, je vytvoriť Kafkovho producenta a použiť ho na vytvorenie platne, ktorá obsahuje nový stav. To zaisťuje, že všetky správy generované prostredníctvom API budú spracované rovnakým spôsobom ako správy prijaté od iných výrobcov (napr. agentov).
Obrázok 6: Pomocou výrobcu Kafka môžete nastaviť stav objektu
Malá komplikácia: Kafka má veľa priečok
Ďalej sme chceli rozložiť zaťaženie spracovania a zlepšiť dostupnosť poskytnutím klastra mikroslužieb v zdieľanom stave podľa scenára. Nastavenie bolo hračkou: akonáhle sme nakonfigurovali všetky inštancie tak, aby bežali pod rovnakým ID aplikácie (a rovnakými bootstrap servermi), takmer všetko ostatné sa vykonalo automaticky. Tiež sme špecifikovali, že každá zdrojová téma bude pozostávať z niekoľkých oddielov, takže každej inštancii možno priradiť podmnožinu takýchto oddielov.
Spomeniem tiež, že je bežnou praxou vytvoriť si záložnú kópiu štátneho úložiska, aby sa napríklad v prípade obnovy po zlyhaní preniesla táto kópia do inej inštancie. Pre každý štátny obchod v Kafka Streams sa vytvorí replikovaná téma s protokolom zmien (ktorý sleduje lokálne aktualizácie). Kafka tak neustále zálohuje štátny obchod. Preto v prípade zlyhania jednej alebo druhej inštancie Kafka Streams môže byť stav úložiska rýchlo obnovený na inej inštancii, kam prejdú príslušné oddiely. Naše testy ukázali, že je to hotové v priebehu niekoľkých sekúnd, aj keď sú v obchode milióny záznamov.
Po prechode z jednej mikroslužby so zdieľaným stavom na klaster mikroslužieb je implementácia rozhrania Get State API menej triviálna. V novej situácii obsahuje stavový sklad každej mikroslužby iba časť celkového obrazu (tie objekty, ktorých kľúče boli namapované na konkrétny oddiel). Museli sme určiť, ktorá inštancia obsahuje stav objektu, ktorý sme potrebovali, a urobili sme to na základe metadát vlákna, ako je uvedené nižšie:
Obrázok 7: Pomocou metadát streamu určíme, z ktorej inštancie sa má dotazovať na stav požadovaného objektu; podobný prístup bol použitý s GET ALL API
Kľúčové zistenia
Štátne obchody v Kafka Streams môžu slúžiť ako de facto distribuovaná databáza,
- neustále replikované v Kafkovi
- CRUD API sa dá jednoducho vybudovať na vrchole takéhoto systému
- Manipulácia s viacerými oddielmi je trochu zložitejšia
- Je tiež možné pridať jeden alebo viac stavových úložísk do streamingovej topológie na uloženie pomocných dát. Túto možnosť možno použiť na:
- Dlhodobé ukladanie údajov potrebných pre výpočty pri spracovaní toku
- Dlhodobé ukladanie údajov, ktoré môžu byť užitočné pri ďalšom poskytovaní inštancie streamovania
- oveľa viac...
Vďaka týmto a ďalším výhodám sú Kafka Streams vhodné na udržiavanie globálneho stavu v distribuovanom systéme, ako je ten náš. Kafka Streams sa ukázal ako veľmi spoľahlivý v produkcii (od nasadenia sme nezaznamenali prakticky žiadnu stratu správ) a sme si istí, že jeho schopnosti sa tým neskončia!
Zdroj: hab.com