Hoi Habr!
Wy herinnerje jo dat nei oanlieding fan it boek oer wy hawwe in like nijsgjirrich wurk publisearre oer de bibleteek .
Foar no leart de mienskip gewoan de grinzen fan dit krêftige ark. Dat, der is koartlyn in artikel publisearre, wêrfan wy jo graach foarstelle wolle oer de oersetting. Ut eigen ûnderfining fertelt de auteur hoe't Kafka Streams omsette yn in ferspraat gegevens opslach. Genietsje fan it lêzen!
Apache bibleteek wrâldwiid brûkt yn bedriuwen foar ferspraat streamferwurking boppe op Apache Kafka. Ien fan 'e ûnderskatte aspekten fan dit ramt is dat it jo makket om lokale steat te bewarjen produsearre op basis fan threadferwurking.
Yn dit artikel sil ik jo fertelle hoe't ús bedriuw it slagge om dizze kâns profitabel te brûken by it ûntwikkeljen fan in produkt foar wolkapplikaasjefeiligens. Mei Kafka Streams hawwe wy dielde steatsmikrotsjinsten makke, dy't elk tsjinnet as in fout-tolerante en heul beskikbere boarne fan betroubere ynformaasje oer de steat fan objekten yn it systeem. Foar ús is dit in stap foarút sawol yn termen fan betrouberens as gemak fan stipe.
As jo ynteressearre binne yn in alternative oanpak wêrmei jo ien sintrale databank kinne brûke om de formele steat fan jo objekten te stypjen, lês it dan, it sil ynteressant wêze ...
Wêrom tochten wy dat it tiid wie om de manier wêrop wy wurkje mei dielde steat te feroarjen
Wy moasten de steat fan ferskate objekten behâlde op basis fan agintrapporten (bygelyks: wie de side ûnder oanfal)? Foardat wy migrearje nei Kafka Streams, fertrouden wy faak op ien sintrale databank (+ tsjinst API) foar steatbehear. Dizze oanpak hat syn neidielen: behâld fan gearhing en syngronisaasje wurdt in echte útdaging. De databank kin in knelpunt wurde of yn einigje en lêst fan ûnfoarspelberens.
Figuer 1: In typysk split-state senario sjoen foar de oergong nei
Kafka en Kafka Streams: aginten kommunisearje har opfettings fia API, bywurke steat wurdt berekkene fia in sintrale databank
Moetsje Kafka Streams, wêrtroch it maklik is om dielde steatsmikrotsjinsten te meitsjen
Sawat in jier lyn hawwe wy besletten om ús dielde steatsenario's hurd te besjen om dizze problemen oan te pakken. Wy hawwe fuortendaliks besletten Kafka Streams te besykjen - wy witte hoe skaalber, heul beskikber en fouttolerant it is, en hoe ryk syn streamingfunksjonaliteit is (transformaasjes, ynklusyf steatlike). Krekt wat wy nedich wiene, net te hawwen oer hoe folwoeksen en betrouber it berjochtensysteem yn Kafka wurden is.
Elk fan 'e steatlike mikrotsjinsten dy't wy makke hawwe, waard boud boppe op in Kafka Streams-eksimplaar mei in frij ienfâldige topology. It bestie út 1) in boarne 2) in prosessor mei in oanhâldende kaai-wearde winkel 3) in wasktafel:
Ofbylding 2: De standerttopology fan ús streaming-ynstânsjes foar steatlike mikrotsjinsten. Tink derom dat hjir ek in repository is dy't planningmetadata befettet.
Yn dizze nije oanpak komponearje aginten berjochten dy't yn it boarneûnderwerp wurde fiede, en konsuminten - sis in e-postnotifikaasjetsjinst - ûntfange de berekkene dielde steat fia de wasktafel (útfierûnderwerp).
figuer 3: Nije foarbyld taak flow foar in senario mei dielde microservices: 1) de agint genereart in berjocht dat oankomt by de Kafka boarne ûnderwerp; 2) in mikroservice mei dielde steat (mei Kafka Streams) ferwurket it en skriuwt de berekkene steat nei it definitive Kafka-ûnderwerp; wêrnei't 3) konsuminten akseptearje de nije steat
Hey, dizze ynboude winkel foar kaaiwearde is eins heul nuttich!
Lykas hjirboppe neamd, befettet ús dielde steattopology in winkel foar kaaiwearde. Wy hawwe ferskate opsjes fûn om it te brûken, en twa fan har wurde hjirûnder beskreaun.
Opsje #1: Brûk in kaai-wearde-winkel foar berekkeningen
Us earste winkel foar kaaiwearden befette de helpgegevens dy't wy nedich wiene foar berekkeningen. Bygelyks, yn guon gefallen waard de dielde steat bepaald troch it prinsipe fan "mearderheidsstimmen". It repository koe alle lêste agintrapporten hâlde oer de status fan in objekt. Dan, doe't wy krigen in nij rapport fan ien of oare agent, wy koenen bewarje it, ophelje rapporten fan alle oare aginten oer de steat fan itselde objekt út opslach, en werhelje de berekkening.
Figuer 4 hjirûnder lit sjen hoe't wy de kaai / wearde winkel bleatsteld oan de prosessor syn ferwurking metoade, sadat it nije berjocht koe dan wurde ferwurke.
Yllustraasje 4: Wy iepenje tagong ta de kaai-wearde-winkel foar de ferwurkingsmetoade fan 'e prosessor (dêrnei moat elk skript dat wurket mei dielde steat de metoade ymplementearje doProcess)
Opsje #2: In CRUD API oanmeitsje boppe Kafka Streams
Nei it fêststellen fan ús basistaakstream, begûnen wy te besykjen in RESTful CRUD API te skriuwen foar ús dielde steatsmikrotsjinsten. Wy woene de steat fan guon of alle objekten ophelje, en ek de steat fan in objekt ynstelle of fuortsmite (nuttich foar backend-stipe).
Om alle Get State API's te stypjen, elke kear as wy de steat moatte berekkenje by it ferwurkjen, hawwe wy it in lange tiid opslein yn in ynboude kaai-wearde-winkel. Yn dit gefal wurdt it frij ienfâldich om sa'n API te ymplementearjen mei ien eksimplaar fan Kafka Streams, lykas werjûn yn 'e list hjirûnder:
Figuer 5: Mei help fan de ynboude kaai-wearde winkel te krijen de foarberekkene steat fan in objekt
It bywurkjen fan de steat fan in objekt fia de API is ek maklik te ymplementearjen. Yn prinsipe is alles wat jo hoege te dwaan in Kafka-produsint te meitsjen en it te brûken om in rekord te meitsjen dat de nije steat befettet. Dit soarget derfoar dat alle berjochten generearre fia de API wurde ferwurke op deselde wize as dy ûntfongen fan oare produsinten (bgl. aginten).
Ofbylding 6: Jo kinne de steat fan in objekt ynstelle mei de Kafka-produsint
Lytse komplikaasje: Kafka hat in protte partysjes
Dêrnei woenen wy de ferwurkingslast fersprieden en de beskikberens ferbetterje troch in kluster te leverjen fan mikrotsjinsten mei dielde steat per senario. Setup wie in wyntsje: ienris hawwe wy alle eksimplaren konfigureare om ûnder deselde applikaasje-ID (en deselde bootstrap-tsjinners) te rinnen, hast al it oare waard automatysk dien. Wy spesifisearre ek dat elk boarne ûnderwerp soe bestean út ferskate partysjes, sadat elk eksimplaar koe wurde tawiisd in subset fan sokke partysjes.
Ik sil ek neame dat it gewoane praktyk is om in reservekopy fan 'e steatwinkel te meitsjen, sadat, bygelyks, yn gefal fan herstel nei in mislearring, dizze kopy nei in oare eksimplaar oerdrage. Foar elke steatswinkel yn Kafka Streams wurdt in replikearre ûnderwerp makke mei in feroaringslog (dy't lokale updates folget). Sa makket Kafka hieltyd in back-up fan de steat winkel. Dêrom, yn it gefal fan in mislearring fan ien of oare Kafka Streams-eksimplaar, kin de steatwinkel fluch wersteld wurde op in oare eksimplaar, wêr't de oerienkommende partysjes sille gean. Us tests hawwe oantoand dat dit yn sekonden dien wurdt, sels as d'r miljoenen records yn 'e winkel binne.
Ferhúzjen fan in inkele mikrotsjinst mei dielde steat nei in kluster fan mikrotsjinsten, wurdt it minder triviaal om de Get State API te ymplementearjen. Yn 'e nije situaasje befettet de steatwinkel fan elke mikrotsjinst mar in diel fan' e totale ôfbylding (dy objekten wêrfan de kaaien binne yn kaart brocht oan in spesifike partysje). Wy moasten bepale hokker eksimplaar de steat befette fan it objekt dat wy nedich wiene, en wy diene dit op basis fan 'e thread-metadata, lykas hjirûnder werjûn:
Figuer 7: Mei help fan stream metadata, wy bepale út hokker eksimplaar te query de steat fan it winske objekt; in ferlykbere oanpak waard brûkt mei de GET ALL API
Key Findings
Steatswinkels yn Kafka Streams kinne tsjinje as in de facto ferspraat databank,
- hieltyd replikearre yn Kafka
- In CRUD API kin maklik boppe op sa'n systeem boud wurde
- It behanneljen fan meardere partysjes is in bytsje komplisearre
- It is ek mooglik om ien of mear steatwinkels ta te foegjen oan 'e streamingtopology om helpgegevens op te slaan. Dizze opsje kin brûkt wurde foar:
- Opslach op lange termyn fan gegevens nedich foar berekkeningen by streamferwurking
- Opslach op lange termyn fan gegevens dy't nuttich wêze kinne de folgjende kear dat de streamingeksimplaar wurdt levere
- folle mear...
Dizze en oare foardielen meitsje Kafka Streams goed geskikt foar it behâld fan wrâldwide steat yn in ferspraat systeem lykas ús. Kafka Streams hat bewiisd heul betrouber te wêzen yn produksje (wy hawwe praktysk gjin berjochtferlies hân sûnt it ynsetten), en wy binne der wis fan dat syn mooglikheden dêr net sille stopje!
Boarne: www.habr.com