Hæ Habr!
Við minnum á að eftir bókinni um við höfum gefið út jafn áhugavert verk um bókasafnið .
Í bili er samfélagið bara að læra takmörk þessa öfluga tækis. Svo, nýlega var birt grein, þýðinguna sem við viljum kynna fyrir þér. Af eigin reynslu segir höfundurinn hvernig eigi að breyta Kafka Streams í dreifða gagnageymslu. Njóttu þess að lesa!
Apache bókasafn notað um allan heim í fyrirtækjum fyrir dreifða straumvinnslu ofan á Apache Kafka. Einn af vanmetnum þáttum þessa ramma er að hann gerir þér kleift að geyma staðbundið ástand framleitt á grundvelli þráðavinnslu.
Í þessari grein mun ég segja þér hvernig fyrirtækinu okkar tókst að nýta þetta tækifæri með hagnaði þegar hann þróaði vöru fyrir öryggi skýjaforrita. Með því að nota Kafka Streams, bjuggum við til sameiginlegar örþjónustur ríkisins, sem hver um sig þjónar sem bilunarþolin og mjög tiltæk uppspretta áreiðanlegra upplýsinga um stöðu hluta í kerfinu. Fyrir okkur er þetta skref fram á við bæði hvað varðar áreiðanleika og auðveldan stuðning.
Ef þú hefur áhuga á annarri nálgun sem gerir þér kleift að nota einn miðlægan gagnagrunn til að styðja við formlegt ástand hlutanna þinna, lestu það, það verður áhugavert...
Hvers vegna við héldum að það væri kominn tími til að breyta því hvernig við vinnum með sameiginlegu ástandi
Við þurftum að viðhalda ástandi ýmissa hluta byggt á skýrslum umboðsmanna (til dæmis: var vefsvæðið fyrir árás)? Áður en við fluttum yfir í Kafka Streams treystum við oft á einn miðlægan gagnagrunn (+ þjónustu API) fyrir ríkisstjórnun. Þessi aðferð hefur sína galla: að viðhalda samræmi og samstillingu verður raunveruleg áskorun. Gagnagrunnurinn getur orðið flöskuháls eða endað í og þjást af ófyrirsjáanleika.
Mynd 1: Dæmigert atburðarás í skiptingum sem sést áður en skipt var yfir í
Kafka og Kafka straumar: umboðsmenn miðla skoðunum sínum í gegnum API, uppfært ástand er reiknað í gegnum miðlægan gagnagrunn
Kynntu þér Kafka Streams, sem gerir það auðvelt að búa til sameiginlegar örþjónustur ríkisins
Fyrir um ári síðan ákváðum við að skoða sameiginlegar aðstæður okkar til að takast á við þessi mál. Við ákváðum strax að prófa Kafka strauma - við vitum hversu skalanlegt, mjög fáanlegt og bilanaþolið það er, hvaða ríka streymisvirkni það hefur (umbreytingar, þar á meðal staðbundnar). Einmitt það sem við þurftum, svo ekki sé minnst á hversu þroskað og áreiðanlegt skilaboðakerfið er orðið í Kafka.
Sérhver staðbundin örþjónusta sem við bjuggum til var byggð ofan á Kafka Streams tilviki með frekar einfaldri staðfræði. Það samanstóð af 1) uppsprettu 2) örgjörva með viðvarandi lykilgildageymslu 3) vaski:
Mynd 2: Sjálfgefin svæðisfræði streymistilvika okkar fyrir staðbundna örþjónustu. Athugið að hér er líka geymsla sem inniheldur lýsigögn áætlanagerðar.
Í þessari nýju nálgun semur umboðsmenn skilaboð sem eru færð inn í upprunaviðfangsefnið og neytendur - til dæmis pósttilkynningarþjónusta - fá reiknað samnýtt ástand í gegnum vaskinn (úttaksefni).
Mynd 3: Nýtt dæmi um verkefnaflæði fyrir atburðarás með sameiginlegri örþjónustu: 1) umboðsmaðurinn býr til skilaboð sem berast til Kafka upprunaviðfangsefnisins; 2) örþjónusta með sameiginlegu ástandi (með því að nota Kafka strauma) vinnur úr því og skrifar útreiknað ástand í loka Kafka efni; eftir það 3) neytendur samþykkja nýja ríkið
Hey, þessi innbyggða verslun með lykilgildi er í raun mjög gagnleg!
Eins og nefnt er hér að ofan, inniheldur sameiginlega ástandssvæðifræði okkar lykilgildageymslu. Við fundum nokkra möguleika til að nota það og tveimur þeirra er lýst hér að neðan.
Valkostur #1: Notaðu lykilgildageymslu fyrir útreikninga
Fyrsta lykilgildisgeymslan okkar innihélt hjálpargögnin sem við þurftum fyrir útreikninga. Sem dæmi má nefna að í sumum tilfellum var sameiginlegt ríki ákvarðað af meginreglunni um „meirihlutaatkvæði“. Geymslan gæti geymt allar nýjustu umboðsmannaskýrslur um stöðu einhvers hlutar. Síðan, þegar við fengum nýja skýrslu frá einum eða öðrum umboðsmanni, gátum við vistað hana, sótt skýrslur frá öllum öðrum umboðsmönnum um ástand sama hluts úr geymslu og endurtekið útreikninginn.
Mynd 4 hér að neðan sýnir hvernig við útsettum lykilgildisgeymsluna fyrir vinnsluaðferð örgjörvans svo hægt væri að vinna úr nýju skilaboðunum.
Mynd 4: Við opnum aðgang að lykilgildageymslunni fyrir vinnsluaðferð örgjörvans (eftir þetta verður hvert smáforrit sem vinnur með sameiginlegu ástandi að innleiða aðferðina doProcess)
Valkostur #2: Að búa til CRUD API ofan á Kafka Streams
Eftir að hafa komið á fót grunnverkefnaflæðinu okkar byrjuðum við að reyna að skrifa RESTful CRUD API fyrir sameiginlegu örþjónustuna okkar. Við vildum geta sótt stöðu sumra eða allra hluta, auk þess að stilla eða fjarlægja stöðu hlutar (gagnlegt fyrir bakendastuðning).
Til að styðja öll Get State API, þegar við þurftum að endurreikna ástandið meðan á vinnslu stóð, geymdum við það í innbyggðri lykilgildageymslu í langan tíma. Í þessu tilfelli verður það frekar einfalt að innleiða slíkt API með því að nota eitt tilvik af Kafka Streams, eins og sýnt er á skráningunni hér að neðan:
Mynd 5: Notkun innbyggðu lykilgildageymslunnar til að fá fyrirfram reiknað ástand hlutar
Það er líka auðvelt að uppfæra stöðu hlutar í gegnum API. Í grundvallaratriðum, allt sem þú þarft að gera er að búa til Kafka framleiðanda og nota hann til að gera plötu sem inniheldur nýja ástandið. Þetta tryggir að öll skilaboð sem myndast í gegnum API verða unnin á sama hátt og þau sem berast frá öðrum framleiðendum (td umboðsmönnum).
Mynd 6: Þú getur stillt stöðu hlutar með Kafka framleiðanda
Lítil flækja: Kafka hefur marga skipting
Næst vildum við dreifa vinnsluálaginu og bæta aðgengi með því að bjóða upp á þyrping af samnýttum örþjónustum fyrir hverja atburðarás. Uppsetningin var gola: þegar við stilltum öll tilvik til að keyra undir sama forritaauðkenni (og sömu ræsiþjónum) var næstum allt annað gert sjálfkrafa. Við tilgreindum líka að hvert frumefni myndi samanstanda af nokkrum skiptingum, þannig að hægt væri að úthluta hverju tilviki undirmengi slíkra skiptinga.
Ég nefni líka að það er algengt að gera öryggisafrit af ríkisversluninni þannig að til dæmis, ef endurheimt er eftir bilun, flytjið þetta afrit yfir á annað tilvik. Fyrir hverja ríkisverslun í Kafka Streams er endurtekið efni búið til með breytingaskrá (sem rekur staðbundnar uppfærslur). Þannig bakkar Kafka stöðugt ríkisverslunina. Þess vegna, ef bilun verður í einu eða öðru Kafka Streams tilviki, er hægt að endurheimta ríkisverslunina fljótt á öðru tilviki, þar sem samsvarandi skipting mun fara. Prófanir okkar hafa sýnt að þetta er gert á nokkrum sekúndum, jafnvel þótt það séu milljónir platna í versluninni.
Að flytja úr einni örþjónustu með sameiginlegu ástandi yfir í hóp örþjónustu, verður minna léttvægt að innleiða Get State API. Í nýju ástandinu inniheldur ríkisverslun hverrar örþjónustu aðeins hluta af heildarmyndinni (þeir hlutir sem lyklarnir voru kortlagðir á tiltekið skipting). Við urðum að ákvarða hvaða tilvik innihélt ástand hlutarins sem við þurftum og við gerðum þetta út frá lýsigögnum þráðsins, eins og sýnt er hér að neðan:
Mynd 7: Með því að nota straumlýsigögn, ákveðum við frá hvaða tilviki á að spyrjast fyrir um stöðu viðkomandi hlutar; svipuð nálgun var notuð með GET ALL API
Lykilatriði
Ríkisverslanir í Kafka Streams geta þjónað sem dreifður gagnagrunnur í reynd,
- sífellt endurtekið í Kafka
- Auðvelt er að byggja CRUD API ofan á slíkt kerfi
- Meðhöndlun á mörgum skiptingum er aðeins flóknari
- Það er líka hægt að bæta einni eða fleiri ríkisverslunum við streymissvæðifræði til að geyma aukagögn. Hægt er að nota þennan valkost fyrir:
- Langtíma geymsla gagna sem þarf til útreikninga við straumvinnslu
- Langtíma geymsla gagna sem gæti verið gagnleg næst þegar streymistilvikið er útvegað
- miklu meira...
Þessir og aðrir kostir gera Kafka Streams vel til þess fallna að viðhalda hnattrænu ástandi í dreifðu kerfi eins og okkar. Kafka Streams hefur reynst mjög áreiðanlegt í framleiðslu (við höfum nánast ekkert tapað skilaboðum frá því að það var sett upp) og við erum fullviss um að hæfileikar þess munu ekki hætta þar!
Heimild: www.habr.com