Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Habari Habr!

Tunakukumbusha kwamba kufuatia kitabu kuhusu Kafka tumechapisha kazi ya kuvutia sawa kuhusu maktaba API ya Mipasho ya Kafka.

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kwa sasa, jumuiya inajifunza tu mipaka ya zana hii yenye nguvu. Kwa hivyo, nakala ilichapishwa hivi karibuni, tafsiri ambayo tungependa kukujulisha. Kutokana na uzoefu wake mwenyewe, mwandishi anaeleza jinsi ya kugeuza Mipasho ya Kafka kuwa hifadhi ya data iliyosambazwa. Furahia kusoma!

Maktaba ya Apache Mipasho ya Kafka kutumika duniani kote katika makampuni ya biashara kwa usambazaji wa usindikaji wa mtiririko juu ya Apache Kafka. Moja ya vipengele visivyothaminiwa vya mfumo huu ni kwamba hukuruhusu kuhifadhi hali ya ndani inayozalishwa kulingana na usindikaji wa nyuzi.

Katika nakala hii, nitakuambia jinsi kampuni yetu imeweza kutumia fursa hii kwa faida wakati wa kutengeneza bidhaa kwa usalama wa programu ya wingu. Kwa kutumia Mipasho ya Kafka, tuliunda huduma ndogo za serikali zilizoshirikiwa, ambazo kila moja hutumika kama chanzo kisichostahimili makosa na kinachopatikana sana cha habari ya kuaminika kuhusu hali ya vitu kwenye mfumo. Kwa sisi, hii ni hatua ya mbele katika suala la kuegemea na urahisi wa usaidizi.

Ikiwa una nia ya mbinu mbadala ambayo hukuruhusu kutumia hifadhidata moja kuu kusaidia hali rasmi ya vitu vyako, isome, itafurahisha ...

Kwa nini tulifikiri ulikuwa wakati wa kubadilisha jinsi tunavyofanya kazi na hali ya pamoja

Tulihitaji kudumisha hali ya vitu mbalimbali kulingana na ripoti za wakala (kwa mfano: je tovuti ilikuwa ikishambuliwa)? Kabla ya kuhamia Kafka Streams, mara nyingi tulitegemea hifadhidata moja kuu (+ API ya huduma) kwa usimamizi wa serikali. Mbinu hii ina hasara zake: tarehe hali kubwa kudumisha uthabiti na ulandanishi inakuwa changamoto halisi. Hifadhidata inaweza kuwa kizuizi au kuishia ndani hali ya mbio na kuteseka kutokana na kutotabirika.

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kielelezo cha 1: Hali ya kawaida ya mgawanyiko inayoonekana kabla ya mpito kwenda
Mipasho ya Kafka na Kafka: mawakala huwasilisha maoni yao kupitia API, hali iliyosasishwa inakokotolewa kupitia hifadhidata kuu.

Kutana na Mipasho ya Kafka, ili kurahisisha kuunda huduma ndogo za serikali zinazoshirikiwa

Takriban mwaka mmoja uliopita, tuliamua kuangalia kwa bidii hali zetu za pamoja za serikali kushughulikia masuala haya. Tuliamua mara moja kujaribu Mipasho ya Kafka - tunajua jinsi ilivyo hatarini, inapatikana sana na kustahimili makosa, na jinsi utendakazi wake wa utiririshaji ulivyo (mabadiliko, pamoja na yale ya serikali). Tulichohitaji tu, bila kutaja jinsi mfumo wa utumaji ujumbe ulivyokomaa na kutegemewa huko Kafka.

Kila moja ya huduma ndogo ndogo tulizounda iliundwa juu ya mfano wa Mipasho ya Kafka na topolojia rahisi. Ilijumuisha 1) chanzo 2) kichakataji kilicho na duka la ufunguo wa thamani 3) sinki:

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kielelezo cha 2: Topolojia chaguo-msingi ya matukio yetu ya utiririshaji kwa huduma ndogo ndogo. Kumbuka kuwa pia kuna hazina hapa ambayo ina metadata ya kupanga.

Katika mbinu hii mpya, mawakala hutunga jumbe ambazo zimeingizwa kwenye mada chanzo, na watumiaji—tuseme, huduma ya arifa ya barua—kupokea hali iliyoshirikiwa kwa njia ya sinki (mada ya pato).

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kielelezo 3: Mfano mpya wa mtiririko wa kazi kwa kisa chenye huduma ndogo ndogo zinazoshirikiwa: 1) wakala hutoa ujumbe unaofika kwenye mada ya chanzo cha Kafka; 2) huduma ndogo iliyo na hali iliyoshirikiwa (kwa kutumia Mito ya Kafka) inasindika na kuandika hali iliyohesabiwa kwa mada ya mwisho ya Kafka; baada ya hapo 3) watumiaji kukubali hali mpya

Halo, duka hili la thamani la ufunguo lililojengwa ni muhimu sana!

Kama ilivyotajwa hapo juu, topolojia ya hali yetu iliyoshirikiwa ina duka la thamani kuu. Tulipata chaguzi kadhaa za kuitumia, na mbili kati yao zimeelezewa hapa chini.

Chaguo #1: Tumia duka la ufunguo-thamani kwa mahesabu

Hifadhi yetu ya kwanza ya thamani ya ufunguo ilikuwa na data saidizi tuliyohitaji kwa mahesabu. Kwa mfano, katika baadhi ya matukio hali ya pamoja iliamuliwa na kanuni ya "kura za wengi". Hifadhi inaweza kushikilia ripoti zote za hivi punde za wakala kuhusu hali ya baadhi ya kitu. Kisha, tulipopokea ripoti mpya kutoka kwa wakala mmoja au mwingine, tunaweza kuihifadhi, kupata ripoti kutoka kwa mawakala wengine wote kuhusu hali ya kitu sawa kutoka kwa hifadhi, na kurudia hesabu.
Kielelezo cha 4 hapa chini kinaonyesha jinsi tulivyofichua hifadhi ya ufunguo/thamani kwa mbinu ya kuchakata ya kichakataji ili ujumbe mpya uweze kuchakatwa.

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Mchoro wa 4: Tunafungua ufikiaji wa duka la thamani-msingi kwa njia ya usindikaji ya kichakataji (baada ya hili, kila hati inayofanya kazi na hali iliyoshirikiwa lazima itekeleze mbinu hiyo. doProcess)

Chaguo #2: Kuunda API ya CRUD juu ya Mipasho ya Kafka

Baada ya kuanzisha mtiririko wetu wa kazi ya kimsingi, tulianza kujaribu kuandika RESTful CRUD API kwa huduma zetu ndogo za serikali zilizoshirikiwa. Tulitaka kuweza kupata hali ya baadhi au vitu vyote, na pia kuweka au kuondoa hali ya kitu (kina manufaa kwa usaidizi wa nyuma).

Ili kuauni API zote za Jimbo la Get State, wakati wowote tulipohitaji kukokotoa upya hali wakati wa kuchakata, tuliihifadhi kwenye hifadhi ya thamani ya ufunguo iliyojengewa ndani kwa muda mrefu. Katika kesi hii, inakuwa rahisi sana kutekeleza API kama hiyo kwa kutumia mfano mmoja wa Mito ya Kafka, kama inavyoonyeshwa kwenye orodha hapa chini:

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kielelezo cha 5: Kutumia hifadhi ya thamani ya ufunguo iliyojengwa ili kupata hali ya kukokotwa mapema ya kitu.

Kusasisha hali ya kitu kupitia API pia ni rahisi kutekeleza. Kimsingi, unachohitaji kufanya ni kuunda mtayarishaji wa Kafka na kuitumia kutengeneza rekodi ambayo ina hali mpya. Hii inahakikisha kwamba jumbe zote zinazotolewa kupitia API zitachakatwa kwa njia sawa na zile zinazopokelewa kutoka kwa wazalishaji wengine (kwa mfano mawakala).

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kielelezo cha 6: Unaweza kuweka hali ya kitu kwa kutumia mzalishaji wa Kafka

Shida ndogo: Kafka ina sehemu nyingi

Kisha, tulitaka kusambaza mzigo wa uchakataji na kuboresha upatikanaji kwa kutoa kundi la huduma ndogo za serikali pamoja kwa kila hali. Usanidi ulikuwa mwepesi: mara tu tuliposanidi hali zote kufanya kazi chini ya kitambulisho sawa cha programu (na seva zile zile za bootstrap), karibu kila kitu kingine kilifanyika kiotomatiki. Pia tulibainisha kuwa kila mada chanzo kitakuwa na sehemu kadhaa, ili kila mfano uweze kupewa sehemu ndogo ya sehemu hizo.

Pia nitataja kuwa ni kawaida kufanya nakala ya hifadhi ya hifadhi ya serikali ili, kwa mfano, katika hali ya kurejesha baada ya kushindwa, kuhamisha nakala hii kwa mfano mwingine. Kwa kila duka la serikali katika Mipasho ya Kafka, mada iliyorudiwa huundwa kwa kumbukumbu ya mabadiliko (ambayo hufuatilia masasisho ya ndani). Kwa hivyo, Kafka inaunga mkono duka la serikali kila wakati. Kwa hivyo, katika tukio la kutofaulu kwa mfano mmoja au mwingine wa Mito ya Kafka, duka la serikali linaweza kurejeshwa haraka kwa mfano mwingine, ambapo sehemu zinazolingana zitaenda. Majaribio yetu yameonyesha kuwa hii inafanywa kwa sekunde chache, hata ikiwa kuna mamilioni ya rekodi kwenye duka.

Kuhama kutoka huduma ndogo ndogo iliyo na hali iliyoshirikiwa hadi kikundi cha huduma ndogo, inakuwa rahisi sana kutekeleza API ya Jimbo la Get State. Katika hali mpya, hifadhi ya serikali ya kila microservice ina sehemu tu ya picha ya jumla (vitu hivyo ambavyo funguo zao zilipangwa kwa ugawaji maalum). Ilitubidi kuamua ni mfano gani ulikuwa na hali ya kitu tulichohitaji, na tulifanya hivi kulingana na metadata ya nyuzi, kama inavyoonyeshwa hapa chini:

Sio tu kuchakata: Jinsi tulivyotengeneza hifadhidata iliyosambazwa kutoka kwa Mipasho ya Kafka, na kilichotokana nayo

Kielelezo cha 7: Kwa kutumia metadata ya mtiririko, tunaamua kutoka kwa mfano gani ili kuuliza hali ya kitu unachotaka; mbinu sawa ilitumika na GET ALL API

Matokeo Muhimu

Duka za serikali katika Kafka Streams zinaweza kutumika kama hifadhidata iliyosambazwa,

  • mara kwa mara kuigwa katika Kafka
  • API ya CRUD inaweza kujengwa kwa urahisi juu ya mfumo kama huo
  • Kushughulikia partitions nyingi ni ngumu zaidi
  • Inawezekana pia kuongeza duka moja au zaidi za serikali kwenye topolojia ya utiririshaji ili kuhifadhi data saidizi. Chaguo hili linaweza kutumika kwa:
  • Uhifadhi wa muda mrefu wa data unaohitajika kwa hesabu wakati wa usindikaji wa mtiririko
  • Uhifadhi wa muda mrefu wa data ambao unaweza kuwa muhimu wakati mwingine tukio la kutiririsha litakapotolewa
  • mengi zaidi...

Faida hizi na nyinginezo hufanya Mipasho ya Kafka ifae vyema kwa kudumisha hali ya kimataifa katika mfumo unaosambazwa kama wetu. Mipasho ya Kafka imethibitishwa kuwa ya kutegemewa sana katika uzalishaji (hatujapoteza ujumbe wowote tangu kuituma), na tuna uhakika kwamba uwezo wake hautaishia hapo!

Chanzo: mapenzi.com

Kuongeza maoni