Sveiki, Habr!
Primename, kad sekant knygą apie išleidome ne mažiau įdomų veikalą apie biblioteką .
Kol kas bendruomenė tik mokosi šio galingo įrankio ribų. Taigi, neseniai buvo publikuotas straipsnis, su kurio vertimu norime jus supažindinti. Iš savo patirties autorius pasakoja, kaip Kafka Streams paversti paskirstyta duomenų saugykla. Smagaus skaitymo!
Apache biblioteka visame pasaulyje naudojamas įmonėse paskirstytam srauto apdorojimui, papildant Apache Kafka. Vienas iš neįvertintų šios sistemos aspektų yra tai, kad ji leidžia saugoti vietinę būseną, pagamintą remiantis siūlų apdorojimu.
Šiame straipsnyje papasakosiu, kaip mūsų įmonei pavyko pelningai pasinaudoti šia galimybe kuriant debesų programų saugos produktą. Naudodami Kafka Streams sukūrėme bendras būsenos mikropaslaugas, kurių kiekviena tarnauja kaip gedimams atsparus ir labai prieinamas patikimos informacijos apie sistemos objektų būklę šaltinis. Mums tai yra žingsnis į priekį tiek patikimumo, tiek pagalbos paprastumo požiūriu.
Jei jus domina alternatyvus metodas, leidžiantis naudoti vieną centrinę duomenų bazę formaliai jūsų objektų būklei palaikyti, perskaitykite, bus įdomu...
Kodėl manėme, kad atėjo laikas pakeisti būdą, kaip dirbame su bendra būsena
Mums reikėjo palaikyti įvairių objektų būseną pagal agentų ataskaitas (pvz.: ar svetainė buvo užpulta)? Prieš pereidami prie „Kafka Streams“, valstybės valdymui dažnai pasitikėjome viena centrine duomenų baze (+ paslaugos API). Šis metodas turi savo trūkumų: išlaikyti nuoseklumą ir sinchronizavimą tampa tikru iššūkiu. Duomenų bazė gali tapti kliūtimi arba atsidurti ir kenčia nuo nenuspėjamumo.
1 pav. Įprastas suskaidytos būsenos scenarijus, matytas prieš pereinant prie
Kafka ir Kafka srautai: agentai perduoda savo nuomonę per API, atnaujinta būsena apskaičiuojama per centrinę duomenų bazę
Susipažinkite su Kafka Streams, kad būtų lengva kurti bendras valstybės mikropaslaugas
Maždaug prieš metus nusprendėme atidžiai pažvelgti į mūsų bendrus būsenos scenarijus, kad išspręstume šias problemas. Iš karto nusprendėme išbandyti Kafka Streams – žinome, koks jis keičiamas, labai prieinamas ir atsparus gedimams, koks turtingas srautinio perdavimo funkcionalumas (transformacijos, įskaitant būsenas). Kaip tik tai, ko mums reikėjo, jau nekalbant apie tai, kokia brandi ir patikima Kafkos pranešimų sistema tapo.
Visos mūsų sukurtos būsenos mikropaslaugos buvo sukurtos ant „Kafka Streams“ egzemplioriaus su gana paprasta topologija. Jį sudarė 1) šaltinis, 2) procesorius su nuolatine raktų verčių saugykla 3) kriaukle:
2 pav. Numatytoji mūsų būseną palaikančių mikropaslaugų srautinio perdavimo egzempliorių topologija. Atminkite, kad taip pat yra saugykla, kurioje yra planavimo metaduomenys.
Taikant šį naują metodą, agentai kuria pranešimus, kurie įvedami į šaltinio temą, o vartotojai, tarkime, pranešimų el. paštu paslauga, gauna apskaičiuotą bendrinamą būseną per kriauklę (išvesties temą).
3 pav. Naujas scenarijaus su bendrai naudojamomis mikropaslaugomis užduočių eigos pavyzdys: 1) agentas sugeneruoja pranešimą, kuris pasiekia Kafkos šaltinio temą; 2) mikropaslauga su bendra būsena (naudodama Kafka Streams) ją apdoroja ir įrašo apskaičiuotą būseną į galutinę Kafkos temą; po kurio 3) vartotojai priima naują būseną
Ei, ši integruota raktų vertės saugykla iš tikrųjų yra labai naudinga!
Kaip minėta pirmiau, mūsų bendroje būsenos topologijoje yra raktų vertės saugykla. Mes radome keletą jo naudojimo būdų, du iš jų aprašyti toliau.
1 parinktis: skaičiavimams naudokite rakto-reikšmių saugyklą
Pirmoje mūsų raktų reikšmių saugykloje buvo pagalbiniai duomenys, kurių mums reikėjo skaičiavimams. Pavyzdžiui, kai kuriais atvejais bendroji valstybė buvo nulemta „balsų daugumos“ principu. Saugykloje gali būti visos naujausios agento ataskaitos apie kokio nors objekto būseną. Tada, gavę naują ataskaitą iš vieno ar kito agento, galėjome ją išsaugoti, gauti iš visų kitų agentų ataskaitas apie to paties objekto būseną iš saugyklos ir pakartoti skaičiavimą.
Toliau pateiktame 4 paveiksle parodyta, kaip raktų / reikšmių saugyklai buvo taikomas procesoriaus apdorojimo metodas, kad būtų galima apdoroti naują pranešimą.
4 iliustracija: atidarome prieigą prie procesoriaus apdorojimo metodo raktų-reikšmių saugyklos (po to kiekvienas scenarijus, veikiantis su bendrinama būsena, turi įdiegti metodą doProcess)
2 parinktis: CRUD API sukūrimas „Kafka Streams“ viršuje
Sukūrę pagrindinį užduočių srautą, pradėjome bandyti rašyti RESTful CRUD API mūsų bendroms valstybės mikropaslaugoms. Norėjome, kad būtų galima nuskaityti kai kurių arba visų objektų būseną, taip pat nustatyti arba pašalinti objekto būseną (naudinga užpakaliniam palaikymui).
Kad palaikytume visas Gauti būsenos API, kai tik apdorojimo metu reikėjo perskaičiuoti būseną, ilgą laiką saugojome ją integruotoje raktų verčių saugykloje. Tokiu atveju tampa gana paprasta įdiegti tokią API naudojant vieną Kafka Streams egzempliorių, kaip parodyta toliau pateiktame sąraše:
5 pav. Integruotos raktų-reikšmių saugyklos naudojimas norint gauti iš anksto apskaičiuotą objekto būseną
Taip pat lengva įdiegti objekto būseną per API. Iš esmės viskas, ką jums reikia padaryti, tai sukurti Kafkos prodiuserį ir jį panaudoti įrašui, kuriame yra nauja būsena, sukurti. Tai užtikrina, kad visi pranešimai, sukurti naudojant API, bus apdorojami taip pat, kaip ir iš kitų gamintojų (pvz., agentų) gaunami pranešimai.
6 pav. Objekto būseną galite nustatyti naudodami Kafka gamintoją
Nedidelė komplikacija: Kafka turi daug pertvarų
Be to, norėjome paskirstyti apdorojimo apkrovą ir pagerinti pasiekiamumą, kiekvienam scenarijui teikdami bendros būsenos mikropaslaugų grupę. Sąranka buvo lengva: kai sukonfigūravome visus egzempliorius veikti naudojant tą patį programos ID (ir tuos pačius įkrovos serverius), beveik visa kita buvo atlikta automatiškai. Taip pat nurodėme, kad kiekvieną šaltinio temą sudarys keli skaidiniai, kad kiekvienam egzemplioriui būtų galima priskirti tokių skaidinių poaibį.
Taip pat paminėsiu, kad įprasta daryti valstybinės parduotuvės atsarginę kopiją, kad, pavyzdžiui, atsistačius po gedimo, šią kopiją perkelti į kitą egzempliorių. Kiekvienai valstijos parduotuvei „Kafka Streams“ sukuriama pakartotinė tema su pakeitimų žurnalu (kuris stebi vietinius naujinimus). Taigi Kafka nuolat kuria valstybinės parduotuvės atsargines kopijas. Todėl, sugedus vienam ar kitam „Kafka Streams“ egzemplioriui, būsenos saugykla gali būti greitai atkurta kitame egzemplioriuje, kur pateks atitinkami skaidiniai. Mūsų bandymai parodė, kad tai atliekama per kelias sekundes, net jei parduotuvėje yra milijonai įrašų.
Perėjus nuo vienos mikropaslaugos su bendrinamos būsenos prie mikropaslaugų grupės, „Get State“ API diegimas tampa ne toks trivialus. Naujoje situacijoje kiekvienos mikropaslaugos būsenos saugykloje yra tik dalis bendro vaizdo (tie objektai, kurių raktai buvo susieti su konkrečia skaidiniu). Turėjome nustatyti, kuriame egzemplioriuje yra mums reikalingo objekto būsena, ir tai padarėme pagal gijos metaduomenis, kaip parodyta toliau:
7 pav. Naudodami srauto metaduomenis nustatome, iš kurio egzemplioriaus reikia užklausti norimo objekto būsenos; panašus metodas buvo naudojamas su GET ALL API
Pagrindinės išvados
Valstybinės parduotuvės „Kafka Streams“ gali būti de facto paskirstyta duomenų bazė,
- nuolat kartojamas Kafkoje
- CRUD API galima lengvai sukurti ant tokios sistemos
- Kelių skaidinių tvarkymas yra šiek tiek sudėtingesnis
- Taip pat į srautinio perdavimo topologiją galima įtraukti vieną ar daugiau būsenų saugyklų, kad būtų saugomi pagalbiniai duomenys. Ši parinktis gali būti naudojama:
- Ilgalaikis duomenų, reikalingų skaičiavimams, saugojimas srauto apdorojimo metu
- Ilgalaikis duomenų saugojimas, kuris gali būti naudingas kitą kartą pateikus srautinio perdavimo egzempliorių
- daug daugiau...
Dėl šių ir kitų pranašumų „Kafka Streams“ puikiai tinka palaikyti pasaulinę būklę paskirstytoje sistemoje, kaip mūsų. „Kafka Streams“ pasirodė esąs labai patikimas gamyboje (nuo tada, kai ją įdiegėme, pranešimų beveik nepraradome), ir esame įsitikinę, kad jos galimybės tuo nesibaigs!
Šaltinis: www.habr.com
