Tanggal 26 Februari, kita nganakake temu Apache Ignite GreenSource, ing ngendi kontributor proyek open source ngomong. . Acara penting ing urip komunitas iki yaiku restrukturisasi komponen kasebut , sing ngidini sampeyan masang layanan mikro khusus langsung menyang kluster Ignite. Dheweke ngomong babagan proses sing angel iki ing rapat kasebut , insinyur piranti lunak lan kontributor Apache Ignite luwih saka rong taun.
Ayo dadi miwiti karo apa Apache Ignite ing umum. Iki minangka basis data sing minangka panyimpenan Key / Value sing disebarake kanthi dhukungan kanggo SQL, transactionality lan caching. Kajaba iku, Ignite ngidini sampeyan nyebarake layanan khusus langsung menyang kluster Ignite. Pangembang nduweni akses menyang kabeh alat sing diwenehake Ignite - struktur data sing disebarake, Pesen, Streaming, Komputasi lan Data Grid. Contone, nalika nggunakake Data Grid, masalah administrasi infrastruktur kapisah kanggo panyimpenan data lan, minangka akibat, biaya overhead asil ilang.
Nggunakake Service Grid API, sampeyan bisa masang layanan kanthi mung nemtokake skema penyebaran lan, miturut, layanan kasebut dhewe ing konfigurasi.
Biasane, skema panyebaran minangka indikasi jumlah kedadeyan sing kudu dipasang ing simpul kluster. Ana rong skema panyebaran khas. Kapisan yaiku Cluster Singleton: ing sembarang wektu tartamtu, siji conto saka layanan pangguna dijamin kasedhiya ing kluster. Kapindho yaiku Node Singleton: siji conto layanan disebarake ing saben simpul kluster.
Pangguna uga bisa nemtokake jumlah conto layanan ing kabeh kluster lan nemtokake predikat kanggo nyaring simpul sing cocog. Ing skenario iki, Service Grid dhewe bakal ngetung distribusi optimal kanggo deploying layanan.
Kajaba iku, ana fitur kayata Affinity Service. Afinitas minangka fungsi sing nemtokake sesambungan kunci menyang partisi lan hubungan pihak menyang simpul ing topologi. Nggunakake tombol, sampeyan bisa nemtokake simpul utama ing ngendi data disimpen. Kanthi cara iki sampeyan bisa nggandhengake layanan sampeyan dhewe karo cache fungsi kunci lan afinitas. Yen fungsi afinitas diganti, redeployment otomatis bakal kelakon. Kanthi cara iki, layanan bakal tansah dumunung cedhak karo data sing kudu dimanipulasi, lan, kanthi mangkono, nyuda biaya akses informasi. Skema iki bisa diarani jenis komputasi collocated.
Saiki kita wis ngerti apa kaendahan Service Grid, ayo ngomong babagan sejarah pangembangane.
Apa sing kedadeyan sadurunge
Implementasi sadurunge Service Grid adhedhasar cache sistem replikasi transaksi Ignite. Tembung "cache" ing Ignite nuduhake panyimpenan. Tegese, iki dudu barang sementara, kaya sing sampeyan pikirake. Senadyan kasunyatan manawa cache ditiru lan saben simpul ngemot kabeh set data, ing njero cache nduweni perwakilan partisi. Iki amarga optimasi panyimpenan.
Apa sing kedadeyan nalika pangguna pengin nyebarake layanan kasebut?
- Kabeh kelenjar ing kluster langganan nganyari data ing panyimpenan nggunakake mekanisme Query Terus-terusan dibangun ing.
- Node wiwitan, miturut transaksi sing wis diwaca, nggawe rekaman ing database sing ngemot konfigurasi layanan, kalebu conto serial.
- Nalika diwenehi kabar babagan entri anyar, koordinator ngitung distribusi adhedhasar konfigurasi. Objek sing diasilake ditulis maneh menyang database.
- Yen simpul minangka bagean saka distribusi, koordinator kudu nyebarake.
Apa sing ora cocog karo kita
Ing sawetara titik, kita entuk kesimpulan: iki dudu cara kanggo nggarap layanan. Ana sawetara alasan.
Yen ana sawetara kesalahan nalika panyebaran, mula mung bisa ditemokake saka log simpul ing ngendi kabeh kedadeyan. Mung ana panyebaran bedo, supaya sawise bali kontrol kanggo pangguna saka cara penyebaran, sawetara wektu tambahan dibutuhake kanggo miwiti layanan - lan ing wektu iki pangguna ora bisa ngontrol apa-apa. Kanggo ngembangake Layanan Grid luwih, nggawe fitur anyar, narik kawigaten pangguna anyar lan nggawe urip saben wong luwih gampang, ana sing kudu diganti.
Nalika ngrancang Service Grid anyar, kita pisanan kabeh wanted kanggo nyedhiyani njamin panyebaran sinkron: sanalika pangguna bali kontrol saka API, kang bisa langsung nggunakake layanan. Aku uga pengin menehi inisiator kemampuan kanggo nangani kesalahan penyebaran.
Kajaba iku, aku pengin nyederhanakake implementasine, yaiku, adoh saka transaksi lan rebalancing. Senadyan kasunyatan manawa cache ditiru lan ora ana imbangan, masalah muncul nalika penyebaran gedhe kanthi akeh kelenjar. Nalika topologi diganti, simpul kudu ngganti informasi, lan kanthi panyebaran gedhe, data iki bisa bobote akeh.
Nalika topologi ora stabil, koordinator kudu ngitung maneh distribusi layanan. Lan umume, nalika sampeyan kudu nggarap transaksi ing topologi sing ora stabil, iki bisa nyebabake kesalahan sing angel diprediksi.
Masalah
Apa owah-owahan global tanpa masalah? Sing pisanan yaiku owah-owahan ing topologi. Sampeyan kudu ngerti manawa kapan wae, sanajan nalika panyebaran layanan, simpul bisa mlebu utawa ninggalake kluster. Menapa malih, yen ing wektu panyebaran simpul gabung karo kluster, mesthine kudu terus-terusan nransfer kabeh informasi babagan layanan menyang simpul anyar. Lan kita ngomong ora mung babagan apa sing wis disebarake, nanging uga babagan penyebaran saiki lan mbesuk.
Iki mung minangka salah sawijining masalah sing bisa diklumpukake ing dhaptar sing kapisah:
- Kepiye cara masang layanan sing dikonfigurasi sacara statis nalika wiwitan simpul?
- Ninggalake simpul saka kluster - apa sing kudu ditindakake yen simpul dadi host layanan?
- Apa sing kudu ditindakake yen koordinator wis diganti?
- Apa sing kudu ditindakake yen klien nyambung maneh menyang kluster?
- Apa panjaluk aktivasi / mateni kudu diproses lan kepiye carane?
- Apa yen padha njaluk karusakan cache, lan kita duwe layanan karemenan disambungake menyang?
Lan ora mung kuwi.
kaputusan
Minangka target, kita milih pendekatan Event Driven kanthi implementasine proses komunikasi nggunakake pesen. Ignite wis ngleksanakake rong komponen sing ngidini kelenjar ngirim pesen ing antarane awake dhewe - komunikasi-spi lan penemuan-spi.
Komunikasi-spi ngidini kelenjar kanggo komunikasi langsung lan pesen nerusake. Iku uga cocog kanggo ngirim jumlah gedhe saka data. Discovery-spi ngijini sampeyan kanggo ngirim pesen kanggo kabeh kelenjar ing kluster. Ing implementasine standar, iki rampung nggunakake topologi ring. Ana uga integrasi karo Zookeeper, ing kasus iki topologi star digunakake. Titik penting liyane sing kudu dicathet yaiku panemuan-spi menehi jaminan manawa pesen kasebut bakal dikirim kanthi urutan sing bener kanggo kabeh kelenjar.
Ayo goleki protokol penyebaran. Kabeh panjalukan pangguna kanggo penyebaran lan undeployment dikirim liwat discovery-spi. Iki menehi ing ngisor iki babar pisan:
- Panjaluk kasebut bakal ditampa dening kabeh simpul ing kluster. Iki bakal ngidini panyuwunan terus diproses nalika koordinator ganti. Iki uga tegese ing siji pesen, saben simpul bakal duwe kabeh metadata sing dibutuhake, kayata konfigurasi layanan lan conto serial.
- Pesenan pangiriman pesen sing ketat mbantu ngatasi konflik konfigurasi lan panjaluk sing saingan.
- Wiwit entri simpul menyang topologi uga diproses liwat discovery-spi, simpul anyar bakal nampa kabeh data sing perlu kanggo nggarap layanan.
Nalika panjalukan ditampa, simpul ing kluster bakal ngesyahke lan nggawe tugas pangolahan. Tugas iki diantrekake banjur diproses ing thread liyane dening buruh sing kapisah. Iki dileksanakake kanthi cara iki amarga panyebaran bisa njupuk wektu sing akeh lan nundha aliran panemuan sing larang.
Kabeh panjalukan saka antrian diproses dening manajer penyebaran. Wis buruh khusus sing narik tugas saka antrian iki lan initializes kanggo miwiti panyebaran. Sawise iki, tumindak ing ngisor iki kedadeyan:
- Saben simpul independen ngetung distribusi thanks kanggo fungsi assignment deterministik anyar.
- Node ngasilake pesen kanthi asil panyebaran lan dikirim menyang koordinator.
- Koordinator aggregates kabeh pesen lan njedulake asil kabeh proses penyebaran prajurit, kang dikirim liwat panemuan-spi kanggo kabeh kelenjar ing kluster.
- Nalika asil ditampa, proses panyebaran rampung, sawise tugas kasebut dibusak saka antrian.
Desain sing didorong acara anyar: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Yen ana kesalahan nalika panyebaran, simpul kasebut langsung nyakup kesalahan kasebut ing pesen sing dikirim menyang koordinator. Sawise pengumpulan pesen, koordinator bakal duwe informasi babagan kabeh kasalahan sajrone penyebaran lan bakal ngirim pesen iki liwat Discovery-spi. Informasi kesalahan bakal kasedhiya ing sembarang simpul ing kluster.
Kabeh acara penting ing Service Grid diproses nggunakake algoritma operasi iki. Contone, ngganti topologi uga pesen liwat discovery-spi. Lan umume, yen dibandhingake karo sing sadurunge, protokol kasebut cukup entheng lan dipercaya. Cukup kanggo nangani kahanan apa wae sajrone penyebaran.
Apa sing bakal kelakon mengko
Saiki babagan rencana. Sembarang owah-owahan utama ing proyek Ignite rampung minangka inisiatif perbaikan Ignite, sing diarani IEP. Desain ulang Service Grid uga duwe IEP - kanthi judhul moyoki "Ganti lenga ing Grid Layanan". Nanging nyatane, kita ora ngganti lenga mesin, nanging kabeh mesin.
Kita dibagi tugas ing IEP dadi 2 fase. Kapisan minangka fase utama, sing kalebu ngolah ulang protokol panyebaran. Iku wis klebu ing master, sampeyan bisa nyoba Service Grid anyar, kang bakal katon ing versi 2.8. Tahap kapindho kalebu akeh tugas liyane:
- Redeploy panas
- Versi layanan
- Tambah toleransi fault
- Klien tipis
- Piranti kanggo ngawasi lan ngitung macem-macem metrik
Pungkasan, kita bisa menehi saran babagan Service Grid kanggo mbangun sistem sing tahan kesalahan lan kasedhiyan dhuwur. Kita uga ngajak sampeyan ngunjungi kita ing ΠΈ nuduhake pengalaman. Pengalaman sampeyan pancen penting kanggo komunitas; iku bakal mbantu sampeyan ngerti ngendi arep pindhah sabanjure, carane ngembangake komponen kasebut ing mangsa ngarep.
Source: www.habr.com