Hej Habr!
Ju kujtojmë se duke ndjekur librin rreth ne kemi botuar një vepër po aq interesante për bibliotekën .
Tani për tani, komuniteti po mëson vetëm kufijtë e këtij mjeti të fuqishëm. Kështu së fundmi është publikuar një artikull, përkthimin e të cilit dëshirojmë t'ju prezantojmë. Nga përvoja e tij, autori tregon se si ta shndërroni Kafka Streams në një ruajtje të shpërndarë të të dhënave. Kënaquni duke lexuar!
Biblioteka Apache përdoret në mbarë botën në ndërmarrjet për përpunimin e rrymës së shpërndarë në krye të Apache Kafka. Një nga aspektet e nënvlerësuara të këtij kuadri është se ju lejon të ruani gjendjen lokale të prodhuar bazuar në përpunimin e fijeve.
Në këtë artikull, unë do t'ju tregoj se si kompania jonë arriti të përdorë me fitim këtë mundësi kur zhvillon një produkt për sigurinë e aplikacionit cloud. Duke përdorur Kafka Streams, ne krijuam mikroshërbime të përbashkëta shtetërore, secila prej të cilave shërben si një burim tolerant ndaj gabimeve dhe shumë i disponueshëm i informacionit të besueshëm për gjendjen e objekteve në sistem. Për ne, ky është një hap përpara si për sa i përket besueshmërisë ashtu edhe lehtësisë së mbështetjes.
Nëse jeni të interesuar për një qasje alternative që ju lejon të përdorni një bazë të dhënash të vetme qendrore për të mbështetur gjendjen formale të objekteve tuaja, lexoni atë, do të jetë interesante...
Pse menduam se ishte koha për të ndryshuar mënyrën se si punojmë me shtetin e përbashkët
Na duhej të ruanim gjendjen e objekteve të ndryshme bazuar në raportet e agjentëve (për shembull: a ishte faqja nën sulm)? Përpara se të migronim në Kafka Streams, ne shpesh mbështeteshim në një bazë të dhënash të vetme qendrore (+ shërbim API) për menaxhimin e shtetit. Kjo qasje ka të metat e saj: ruajtja e konsistencës dhe sinkronizimit bëhet një sfidë e vërtetë. Baza e të dhënave mund të bëhet një pengesë ose të përfundojë brenda dhe vuajnë nga paparashikueshmëria.
Figura 1: Një skenar tipik i gjendjes së ndarë që shihet përpara kalimit në
Kafka dhe Kafka Streams: agjentët komunikojnë pikëpamjet e tyre nëpërmjet API, gjendja e përditësuar llogaritet përmes një bazë të dhënash qendrore
Njihuni me Kafka Streams, duke e bërë të lehtë krijimin e mikroshërbimeve të përbashkëta shtetërore
Rreth një vit më parë, ne vendosëm të hedhim një vështrim të hollësishëm në skenarët tanë të përbashkët shtetërorë për të adresuar këto çështje. Ne menjëherë vendosëm të provonim Kafka Streams - ne e dimë se sa i shkallëzuar, shumë i disponueshëm dhe tolerant ndaj gabimeve është, çfarë funksionaliteti të pasur transmetimi ka (transformime, përfshirë ato shtetërore). Vetëm ajo që na duhej, për të mos përmendur sa i pjekur dhe i besueshëm është bërë sistemi i mesazheve në Kafka.
Secili nga mikroshërbimet shtetërore që krijuam u ndërtua në krye të një shembulli të Kafka Streams me një topologji mjaft të thjeshtë. Ai përbëhej nga 1) një burim 2) një procesor me një ruajtës të vazhdueshëm të vlerës së çelësit 3) një lavaman:
Figura 2: Topologjia e paracaktuar e instancave tona të transmetimit për mikroshërbimet shtetërore. Vini re se këtu ka edhe një depo që përmban meta të dhëna planifikimi.
Në këtë qasje të re, agjentët krijojnë mesazhe që futen në temën burimore dhe konsumatorët - të themi, një shërbim njoftimi me postë - marrin gjendjen e përbashkët të llogaritur përmes lavamanit (tema e daljes).
Figura 3: Shembulli i ri i rrjedhës së detyrave për një skenar me mikroshërbime të përbashkëta: 1) agjenti gjeneron një mesazh që mbërrin në temën burimore të Kafkës; 2) një mikroshërbim me gjendje të përbashkët (duke përdorur Kafka Streams) e përpunon atë dhe e shkruan gjendjen e llogaritur në temën përfundimtare të Kafkës; pas së cilës 3) konsumatorët pranojnë gjendjen e re
Hej, ky dyqan i integruar me vlerë kyçe është në të vërtetë shumë i dobishëm!
Siç u përmend më lart, topologjia jonë e përbashkët e gjendjes përmban një depo me vlerë kyçe. Ne gjetëm disa opsione për ta përdorur atë, dhe dy prej tyre janë përshkruar më poshtë.
Opsioni #1: Përdorni një dyqan me vlerë kyçe për llogaritjet
Dyqani ynë i parë me vlerë kyçe përmbante të dhënat ndihmëse që na duheshin për llogaritjet. Për shembull, në disa raste shteti i përbashkët përcaktohej nga parimi i "votave të shumicës". Depoja mund të mbajë të gjitha raportet më të fundit të agjentëve mbi statusin e disa objekteve. Pastaj, kur merrnim një raport të ri nga një agjent ose një tjetër, ne mund ta ruanim atë, të merrnim raporte nga të gjithë agjentët e tjerë për gjendjen e të njëjtit objekt nga ruajtja dhe të përsërisnim llogaritjen.
Figura 4 më poshtë tregon se si e ekspozuam ruajtjen e çelësit/vlerës ndaj metodës së përpunimit të procesorit në mënyrë që mesazhi i ri të mund të përpunohej më pas.
Ilustrimi 4: Ne hapim hyrjen në dyqanin e vlerës së çelësit për metodën e përpunimit të procesorit (pas kësaj, çdo skript që funksionon me gjendjen e përbashkët duhet të zbatojë metodën doProcess)
Opsioni #2: Krijimi i një API CRUD në krye të Kafka Streams
Pasi vendosëm rrjedhën tonë bazë të detyrave, filluam të përpiqemi të shkruajmë një API RESTful CRUD për mikroshërbimet tona shtetërore të përbashkëta. Ne donim të ishim në gjendje të rikuperonim gjendjen e disa ose të gjitha objekteve, si dhe të vendosnim ose hiqnim gjendjen e një objekti (i dobishëm për mbështetjen e backend-it).
Për të mbështetur të gjitha API-të e Get State, sa herë që na nevojitej të rillogaritnim gjendjen gjatë përpunimit, ne e ruanim atë në një dyqan të integruar me vlerë kyçe për një kohë të gjatë. Në këtë rast, bëhet mjaft e thjeshtë të zbatosh një API të tillë duke përdorur një shembull të vetëm të Kafka Streams, siç tregohet në listën më poshtë:
Figura 5: Përdorimi i ruajtjes së integruar të vlerës së çelësit për të marrë gjendjen e parallogaritur të një objekti
Përditësimi i gjendjes së një objekti nëpërmjet API-së është gjithashtu i lehtë për t'u zbatuar. Në thelb, gjithçka që duhet të bëni është të krijoni një producent Kafka dhe ta përdorni për të bërë një regjistrim që përmban gjendjen e re. Kjo siguron që të gjitha mesazhet e gjeneruara përmes API-së do të përpunohen në të njëjtën mënyrë si ato të marra nga prodhues të tjerë (p.sh. agjentë).
Figura 6: Mund të vendosni gjendjen e një objekti duke përdorur prodhuesin Kafka
Komplikim i vogël: Kafka ka shumë ndarje
Më pas, ne donim të shpërndanim ngarkesën e përpunimit dhe të përmirësonim disponueshmërinë duke ofruar një grup mikroshërbimesh të shtetit të përbashkët për skenar. Konfigurimi ishte i lehtë: sapo konfiguruam të gjitha instancat që të ekzekutoheshin nën të njëjtin ID të aplikacionit (dhe të njëjtët serverë bootstrap), pothuajse gjithçka tjetër bëhej automatikisht. Ne gjithashtu specifikuam se çdo temë burimore do të përbëhet nga disa ndarje, në mënyrë që çdo shembulli të mund t'i caktohet një nëngrup i ndarjeve të tilla.
Do të përmend gjithashtu se është praktikë e zakonshme të bësh një kopje rezervë të dyqanit shtetëror në mënyrë që, për shembull, në rast rikuperimi pas një dështimi, ta transferosh këtë kopje në një shembull tjetër. Për çdo dyqan shtetëror në Kafka Streams, krijohet një temë e përsëritur me një regjistër ndryshimesh (i cili gjurmon përditësimet lokale). Kështu, Kafka vazhdimisht mbështet dyqanin shtetëror. Prandaj, në rast të dështimit të një ose një shembulli tjetër të Kafka Streams, dyqani shtetëror mund të rikthehet shpejt në një shembull tjetër, ku do të shkojnë ndarjet përkatëse. Testet tona kanë treguar se kjo bëhet në pak sekonda, edhe nëse ka miliona regjistrime në dyqan.
Duke kaluar nga një mikroshërbim i vetëm me gjendje të përbashkët në një grup mikroshërbimesh, bëhet më pak e parëndësishme zbatimi i Get State API. Në situatën e re, ruajtja shtetërore e çdo mikroservice përmban vetëm një pjesë të pamjes së përgjithshme (ato objekte, çelësat e të cilëve u vendosën në një ndarje specifike). Ne duhej të përcaktonim se cili shembull përmbante gjendjen e objektit që na nevojitej, dhe e bëmë këtë bazuar në meta të dhënat e fillit, siç tregohet më poshtë:
Figura 7: Duke përdorur metadatat e transmetimit, ne përcaktojmë se nga cili instancë të kërkojmë gjendjen e objektit të dëshiruar; një qasje e ngjashme është përdorur me GET ALL API
Gjetjet kryesore
Dyqanet shtetërore në Kafka Streams mund të shërbejnë si një bazë të dhënash e shpërndarë de facto,
- përsëritet vazhdimisht te Kafka
- Një API CRUD mund të ndërtohet lehtësisht në krye të një sistemi të tillë
- Trajtimi i ndarjeve të shumta është pak më i komplikuar
- Është gjithashtu e mundur të shtoni një ose më shumë dyqane shtetërore në topologjinë e transmetimit për të ruajtur të dhëna ndihmëse. Ky opsion mund të përdoret për:
- Ruajtja afatgjatë e të dhënave të nevojshme për llogaritjet gjatë përpunimit të rrjedhës
- Ruajtja afatgjatë e të dhënave që mund të jenë të dobishme herën tjetër kur ofrohet shembulli i transmetimit
- me shume...
Këto dhe avantazhe të tjera e bëjnë Kafka Streams të përshtatshme për ruajtjen e gjendjes globale në një sistem të shpërndarë si i yni. Kafka Streams është dëshmuar të jetë shumë i besueshëm në prodhim (ne nuk kemi pasur pothuajse asnjë humbje mesazhi që nga vendosja e tij) dhe jemi të sigurt se aftësitë e tij nuk do të ndalen me kaq!
Burimi: www.habr.com