Héy Habr!
Urang ngingetan yén nuturkeun buku ngeunaan
Pikeun ayeuna mah, masarakat nembé diajar watesan alat anu kuat ieu. Janten, hiji artikel nembé diterbitkeun, tarjamahan anu kami hoyong terangkeun ka anjeun. Tina pangalamanna sorangan, panulis nyarioskeun kumaha cara ngarobah Kafka Streams kana panyimpenan data anu disebarkeun. Senang maca!
perpustakaan Apache
Dina tulisan ieu, kuring bakal nyarioskeun ka anjeun kumaha perusahaan kami junun ngamangpaatkeun kasempetan ieu nalika ngembangkeun produk pikeun kaamanan aplikasi awan. Nganggo Kafka Streams, kami nyiptakeun layanan mikro kaayaan anu dibagi, anu masing-masing janten sumber inpormasi anu tiasa dipercaya ngeunaan kaayaan objék dina sistem. Pikeun kami, ieu mangrupikeun léngkah ka hareup boh tina segi reliabilitas sareng betah dukungan.
Upami anjeun kabetot dina pendekatan alternatif anu ngamungkinkeun anjeun ngagunakeun database pusat tunggal pikeun ngadukung kaayaan formal objék anjeun, baca éta, éta bakal pikaresepeun ...
Naha urang panginten éta waktuna pikeun ngarobih cara urang damel sareng kaayaan anu dibagikeun
Urang diperlukeun pikeun ngajaga kaayaan rupa objék dumasar kana laporan agén (contona: éta situs dina serangan)? Sateuacan migrasi ka Kafka Streams, urang sering ngandelkeun database pusat tunggal (+ layanan API) pikeun manajemén nagara. pendekatan ieu boga drawbacks na:
Angka 1: Skenario kaayaan pamisah anu biasa ditingali sateuacan transisi ka
Aliran Kafka sareng Kafka: agén nginpokeun pandanganna ngalangkungan API, kaayaan anu diropéa diitung ngalangkungan pangkalan data pusat
Minuhan Kafka Streams, ngagampangkeun nyiptakeun layanan mikro kaayaan anu dibagikeun
Kira-kira sataun katukang, kami mutuskeun pikeun ningali skénario kaayaan anu dibagikeun pikeun ngatasi masalah ieu. Kami langsung mutuskeun pikeun nyobaan Kafka Streams - kami terang kumaha scalable, sayogi pisan sareng toleran kasalahan, naon fungsi streaming anu beunghar (transformasi, kalebet anu stateful). Ngan naon urang diperlukeun, teu nyebut kumaha dewasa sarta dipercaya sistem olahtalatah geus jadi di Kafka.
Unggal microservices stateful kami dijieun diwangun dina luhureun hiji conto Kafka Streams kalawan topologi cukup basajan. Éta diwangun ku 1) sumber 2) prosesor kalayan toko nilai konci anu pengkuh 3) tilelep:
Gambar 2: Topologi standar tina instansi streaming urang pikeun microservices stateful. Catet yén aya ogé gudang di dieu anu ngandung metadata perencanaan.
Dina pendekatan anyar ieu, agén nyusun seratan nu fed kana topik sumber, sarta pamakéna-sebutkeun, layanan bewara mail-nampi kaayaan dibagikeun diitung ngaliwatan tilelep (topik output).
angka 3: aliran tugas conto anyar pikeun skenario kalawan microservices dibagikeun: 1) agén dibangkitkeun pesen nu datang ka topik sumber Kafka; 2) layanan mikro sareng kaayaan dibagikeun (ngagunakeun Kafka Streams) ngolah sareng nyerat kaayaan anu diitung kana topik Kafka ahir; sanggeus nu 3) pamakéna narima kaayaan anyar
Hei, toko nilai konci anu diwangun ieu saleresna mangpaat pisan!
Sakumaha didadarkeun di luhur, topologi kaayaan dibagikeun kami ngandung toko konci-nilai. Kami mendakan sababaraha pilihan pikeun ngagunakeunana, sareng dua di antarana dijelaskeun di handap.
Pilihan #1: Paké toko konci-nilai pikeun itungan
Toko konci-nilai munggaran kami ngandung data bantu anu diperyogikeun pikeun itungan. Contona, dina sababaraha kasus kaayaan dibagikeun ditangtukeun ku prinsip "sora mayoritas". Repository tiasa nahan sadaya laporan agén panganyarna ngeunaan status sababaraha obyék. Teras, nalika kami nampi laporan énggal ti hiji agén atanapi anu sanés, urang tiasa nyimpen éta, nyandak laporan ti sadayana agén sanés ngeunaan kaayaan objék anu sami tina panyimpenan, sareng ngulang itungan.
angka 4 di handap nembongkeun kumaha urang kakeunaan konci / toko nilai kana métode processing processor urang supados pesen anyar bisa lajeng diolah.
Ilustrasi 4: Urang muka aksés ka toko nilai-konci pikeun padika pamrosésan prosésor (sanggeus ieu, unggal skrip anu dianggo sareng kaayaan dibagikeun kedah ngalaksanakeun metodeu doProcess
)
Pilihan #2: Nyiptakeun API CRUD di luhur Aliran Kafka
Sanggeus netepkeun aliran tugas dasar urang, urang mimiti nyoba nulis RESTful CRUD API pikeun microservices kaayaan urang dibagikeun. Urang hayang bisa meunangkeun kaayaan sababaraha atawa sakabéh objék, kitu ogé nyetél atawa miceun kaayaan hiji obyék (mangpaat pikeun rojongan backend).
Pikeun ngadukung sadaya API Get State, iraha waé urang kedah ngitung deui kaayaan nalika ngolah, kami disimpen dina toko nilai konci anu diwangun pikeun lami. Dina hal ieu, janten saderhana pisan pikeun nerapkeun API sapertos kitu nganggo conto tunggal Kafka Streams, sapertos anu dipidangkeun dina daptar di handap ieu:
Angka 5: Ngagunakeun toko nilai-konci anu diwangun pikeun kéngingkeun kaayaan anu dikomputasi tina hiji obyék
Ngamutahirkeun kaayaan hiji obyék via API oge gampang pikeun nerapkeun. Dasarna, sadaya anu anjeun kedah laksanakeun nyaéta nyiptakeun produser Kafka sareng dianggo pikeun ngadamel rékaman anu ngandung kaayaan énggal. Ieu mastikeun yén sadaya pesen anu dihasilkeun tina API bakal diolah dina cara anu sami sareng anu ditampi ti produsén sanés (misalna agén).
Gambar 6: Anjeun tiasa nyetél kaayaan hiji obyék ngagunakeun produser Kafka
Komplikasi leutik: Kafka ngagaduhan seueur partisi
Salajengna, urang hoyong ngadistribusikaeun beban pamrosésan sareng ningkatkeun kasadiaan ku nyayogikeun gugusan microservices nagara bagian per skenario. Setup éta angin ngahiliwir: sakali urang ngonpigurasikeun sakabeh instansi pikeun ngajalankeun handapeun ID aplikasi sarua (jeung server bootstrap sarua), ampir sagalana sejenna dipigawé sacara otomatis. Kami ogé netepkeun yén unggal topik sumber bakal diwangun ku sababaraha partisi, ku kituna unggal conto tiasa ditugaskeun sawaréh tina partisi sapertos kitu.
Kuring ogé bakal disebatkeun yén éta téh prakték umum nyieun salinan cadangan tina toko kaayaan jadi, contona, dina kasus recovery sanggeus gagal, mindahkeun salinan ieu ka conto sejen. Pikeun unggal toko kaayaan di Kafka Streams, hiji topik replicated dijieun kalawan log robah (anu ngalacak apdet lokal). Ku kituna, Kafka terus nyadangkeun toko kaayaan. Ku alatan éta, dina kasus gagalna hiji atawa sejen conto Kafka Streams, toko kaayaan bisa gancang dibalikeun dina instansi sejen, dimana partisi pakait bakal balik. Tés kami nunjukkeun yén ieu dilakukeun dina sababaraha detik, sanaos aya jutaan rékaman di toko.
Pindah ti microservice tunggal kalawan kaayaan dibagikeun ka gugusan microservices, janten kirang trivial pikeun nerapkeun Get State API. Dina kaayaan anyar, toko kaayaan unggal microservice ngandung ukur bagian tina gambar sakabéh (éta objék anu konci dipetakeun kana partisi husus). Urang kedah nangtukeun conto mana anu ngandung kaayaan obyék anu urang peryogikeun, sareng urang ngalakukeun ieu dumasar kana metadata benang, sapertos anu dipidangkeun di handap ieu:
Gambar 7: Ngagunakeun metadata aliran, urang nangtukeun ti mana conto query kaayaan objék nu dipikahoyong; pendekatan sarupa ieu dipaké kalawan GET ALL API
Pamanggihan utama
Toko kaayaan di Kafka Streams tiasa janten database anu disebarkeun sacara de facto,
- terus replicated di Kafka
- API CRUD tiasa gampang diwangun dina luhureun sistem sapertos kitu
- Nanganan sababaraha partisi téh saeutik leuwih pajeulit
- Ieu oge mungkin pikeun nambahkeun hiji atawa leuwih toko kaayaan ka topologi streaming pikeun nyimpen data bantu. Pilihan ieu tiasa dianggo pikeun:
- Panyimpenan jangka panjang data anu diperyogikeun pikeun itungan nalika ngolah aliran
- Panyimpenan data jangka panjang anu tiasa mangpaat dina waktos salajengna conto streaming disayogikeun
- seueur deui...
Kauntungan ieu sareng anu sanésna ngajantenkeun Kafka Streams cocog pikeun ngajaga kaayaan global dina sistem anu disebarkeun sapertos urang. Kafka Streams geus kabuktian bisa dipercaya pisan dina produksi (kami geus ampir euweuh leungitna pesen saprak nyebarkeun eta), sarta kami yakin yén kamampuhan na moal eureun di dinya!
sumber: www.habr.com