Dina 26 Pébruari, urang ngayakeun pasamoan Apache Ignite GreenSource, dimana kontributor kana proyék open source nyarios. . Hiji acara penting dina kahirupan masarakat ieu restructuring sahiji komponén , nu ngidinan Anjeun pikeun nyebarkeun microservices custom langsung kana hiji klaster Ignite. Anjeunna nyarioskeun ngeunaan prosés sesah ieu dina rapat éta , insinyur software sareng kontributor Apache Ignite salami dua taun.
Hayu urang mimitian ku naon Apache Ignite sacara umum. Ieu database anu mangrupa Key disebarkeun / Panyimpenan nilai kalayan rojongan pikeun SQL, transactionality na cache. Salaku tambahan, Ignite ngamungkinkeun anjeun nyebarkeun jasa khusus langsung kana kluster Ignite. Pamekar ngagaduhan aksés ka sadaya alat anu disayogikeun ku Ignite - struktur data anu disebarkeun, Olahtalatah, Streaming, Komputasi sareng Data Grid. Salaku conto, nalika nganggo Data Grid, masalah administrasi infrastruktur anu misah pikeun neundeun data sareng, akibatna, biaya overhead anu dileungitkeun.
Ngagunakeun Service Grid API, anjeun tiasa nyebarkeun jasa ku saukur nangtukeun skéma deployment sarta, sasuai, layanan sorangan dina konfigurasi nu.
Biasana, skéma panyebaran mangrupikeun indikasi jumlah instansi anu kedah dipasang dina titik kluster. Aya dua skéma panyebaran anu biasa. Anu kahiji nyaéta Cluster Singleton: iraha waé, hiji conto jasa pangguna dijamin sayogi dina kluster. Anu kadua nyaéta Node Singleton: salah sahiji conto jasa dipasang dina unggal titik kluster.
Pamaké ogé bisa nangtukeun jumlah instansi jasa dina sakabéh klaster jeung nangtukeun predikat pikeun nyaring titik cocog. Dina skenario ieu, Service Grid sorangan bakal ngitung sebaran optimal pikeun deploying jasa.
Salaku tambahan, aya fitur sapertos Affinity Service. Afinitas nyaéta fungsi anu nangtukeun hubungan konci pikeun partisi sareng hubungan pihak ka titik dina topologi. Nganggo konci, anjeun tiasa nangtukeun titik primér dimana data disimpen. Ku cara ieu anjeun tiasa ngahubungkeun jasa anjeun nyalira sareng cache fungsi konci sareng afinitas. Lamun fungsi pangirut robah, redeployment otomatis bakal lumangsung. Ku cara ieu, jasa bakal salawasna lokasina deukeut data eta perlu ngamanipulasi, sarta, sasuai, ngurangan overhead ngakses informasi. Skéma ieu bisa disebut jenis komputasi collocated.
Ayeuna urang parantos terang naon kaéndahan Service Grid, hayu urang ngobrol ngeunaan sajarah pangembanganana.
Naon anu lumangsung saméméh
Palaksanaan Service Grid saméméhna dumasar kana cache sistem replicated transactional Ignite. Kecap "cache" dina Ignite nujul kana neundeun. Nyaéta, ieu sanés samentawis, sapertos anu anjeun pikirkeun. Najan kanyataan yén cache ieu replicated sarta unggal titik ngandung sakabéh set data, di jero cache éta ngagambarkeun partitioned. Ieu alatan optimasi gudang.
Naon anu kajantenan nalika pangguna hoyong nyebarkeun jasa éta?
- Sadaya titik dina kluster ngalanggan pikeun ngapdet data dina panyimpenan nganggo mékanisme Query Continuous anu diwangun.
- Titik initiating, dina transaksi dibaca-komitmen, dijieun catetan dina database nu ngandung konfigurasi jasa, kaasup conto serialized.
- Nalika dibéjakeun ngeunaan éntri anyar, koordinator ngitung distribusi dumasar kana konfigurasi. Obyék anu dihasilkeun ieu ditulis deui kana database.
- Upami titik mangrupikeun bagian tina distribusi, koordinator kedah nyebarkeunana.
Naon teu cocog kami
Dina sababaraha waktos kami dugi ka kacindekan: ieu sanés cara pikeun damel sareng jasa. Aya sababaraha alesan.
Upami aya kasalahan nalika panyebaran, maka éta ngan ukur tiasa dipendakan tina log titik dimana sadayana kajantenan. Aya ngan deployment Asynchronous, jadi sanggeus balik kontrol ka pamaké tina metoda deployment, sababaraha waktu tambahan diperlukeun pikeun ngamimitian jasa - sarta salila ieu pamaké teu bisa ngadalikeun nanaon. Dina raraga ngamekarkeun Service Grid salajengna, nyieun fitur anyar, mikat pamaké anyar jeung nyieun hirup dulur urang leuwih gampang, hal perlu robah.
Nalika ngarancang Service Grid anyar, urang mimitina hoyong nyadiakeun jaminan deployment sinkron: pas pamaké balik kontrol ti API, anjeunna bisa langsung ngagunakeun jasa. Kuring ogé hayang masihan inisiator kamampuhan pikeun nanganan kasalahan deployment.
Salaku tambahan, kuring hoyong nyederhanakeun palaksanaan, nyaéta, ngajauhan transaksi sareng rebalancing. Sanaos kanyataan yén cache ditiru sareng teu aya kasaimbangan, masalah timbul nalika panyebaran ageung sareng seueur titik. Nalika topologi robah, titik kudu tukeur informasi, sarta kalawan deployment badag, data ieu bisa beuratna pisan.
Nalika topologi teu stabil, koordinator kedah ngitung deui distribusi jasa. Sareng sacara umum, nalika anjeun kedah damel sareng transaksi dina topologi anu teu stabil, ieu tiasa nyababkeun kasalahan anu sesah diprediksi.
Anu jadi masalah
Naon parobahan global tanpa masalah? Anu mimiti nyaéta parobahan topologi. Anjeun kedah ngartos yén iraha waé, bahkan dina waktos panyebaran jasa, titik tiasa lebet atanapi ngantunkeun kluster. Sumawona, upami dina waktos panyebaran titik ngagabung kana kluster, kedah konsistén nransferkeun sadaya inpormasi ngeunaan jasa kana titik énggal. Sareng urang ngobrolkeun henteu ngan ukur ngeunaan naon anu parantos disebarkeun, tapi ogé ngeunaan panyebaran ayeuna sareng anu bakal datang.
Ieu mangrupikeun salah sahiji masalah anu tiasa dikumpulkeun dina daptar anu misah:
- Kumaha cara nyebarkeun jasa anu dikonpigurasi sacara statik dina ngamimitian titik?
- Ninggalkeun titik tina kluster - naon anu kudu dilakukeun upami node ngagaduhan jasa?
- Naon anu kudu dipigawé lamun koordinator geus robah?
- Naon anu kudu dilakukeun upami klien nyambung deui ka kluster?
- Naha pamundut aktivasina/nonaktipkeun kedah diolah sareng kumaha?
- Kumaha upami aranjeunna nyauran karusakan cache, sareng kami ngagaduhan jasa afinitas anu aya hubunganana?
Sareng éta sanés sadayana.
kaputusan
Salaku udagan, kami milih pendekatan Event Driven kalayan palaksanaan prosés komunikasi nganggo pesen. Ignite parantos ngalaksanakeun dua komponén anu ngamungkinkeun titik pikeun neraskeun pesen diantara aranjeunna - komunikasi-spi sareng penemuan-spi.
Komunikasi-spi ngamungkinkeun titik pikeun komunikasi langsung jeung pesen diteruskeun. Ieu ogé cocog pikeun ngirim jumlah badag data. Discovery-spi ngidinan Anjeun pikeun ngirim pesen ka sadaya titik dina kluster. Dina palaksanaan standar, ieu dilakukeun ngagunakeun topologi ring. Aya ogé integrasi jeung Zookeeper, dina hal ieu topologi béntang dipaké. titik penting séjén sia noting éta kapanggihna-spi nyadiakeun jaminan yén suratna pasti bakal dikirimkeun dina urutan bener ka sadaya titik.
Hayu urang nempo protokol deployment. Kabéh requests pamaké pikeun deployment na undeployment dikirim via kapanggihna-spi. Ieu méré handap ngajamin:
- Paménta bakal ditampi ku sadaya titik dina kluster. Ieu bakal ngidinan pamundut neruskeun ngolah nalika koordinator robah. Ieu ogé ngandung harti yén dina hiji pesen, unggal titik bakal ngagaduhan sadaya metadata anu diperyogikeun, sapertos konfigurasi jasa sareng conto serial na.
- Pesenan anu ketat pikeun pangiriman pesen ngabantosan ngabéréskeun konflik konfigurasi sareng paménta anu bersaing.
- Kusabab asupna titik kana topologi ogé diolah via discovery-spi, titik anyar bakal nampi sadaya data anu dipikabutuh pikeun damel sareng jasa.
Nalika pamundut ditampi, titik dina kluster ngesahkeunana sareng ngadamel tugas ngolah. Tugas-tugas ieu diantri teras diolah dina utas anu sanés ku pagawé anu misah. Hal ieu dilaksanakeun ku cara ieu kusabab panyebaran tiasa nyandak waktos anu ageung sareng ngalambatkeun aliran penemuan anu mahal sacara teu kaampeuh.
Sadaya pamundut ti antrian diolah ku manajer panyebaran. Mibanda worker husus nu narik tugas ti antrian ieu sareng initializes eta dimimitian deployment. Saatos ieu, tindakan di handap ieu lumangsung:
- Unggal titik bebas ngitung distribusi berkat fungsi ngerjakeun deterministik anyar.
- Titik ngahasilkeun pesen kalayan hasil panyebaran sareng kirimkeun ka koordinator.
- Koordinator aggregates sakabeh pesen na dibangkitkeun hasil tina sakabéh prosés deployment, nu dikirim via kapanggihna-spi ka sadaya titik dina kluster.
- Nalika hasilna ditampi, prosés panyebaran réngsé, saatos éta tugasna dipiceun tina antrian.
Desain dumasar-kajadian anyar: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Upami aya kasalahan nalika panyebaran, titik langsung kalebet kasalahan ieu dina pesen anu dikirimkeun ka koordinator. Saatos aggregation pesen, bakal koordinator informasi ngeunaan sagala kasalahan salila deployment sarta bakal ngirim pesen ieu via kapanggihna-spi. Inpormasi kasalahan bakal sayogi dina titik mana waé dina kluster.
Sadaya kajadian penting dina Service Grid diolah nganggo algoritma operasi ieu. Contona, ngarobah topologi oge pesen via discovery-spi. Sareng sacara umum, upami dibandingkeun sareng anu sateuacana, protokol tétéla rada enteng sareng dipercaya. Cukup pikeun nanganan kaayaan naon waé salami panyebaran.
Naon anu bakal kajadian salajengna
Ayeuna ngeunaan rencana. Sakur parobahan utama dina proyék Ignite réngsé salaku inisiatif perbaikan Ignite, anu disebut IEP. Desain ulang Service Grid ogé ngagaduhan IEP - kalawan judul mocking "Robah minyak dina Service Grid". Tapi dina kanyataanana, urang teu ngarobah oli mesin, tapi sakabéh mesin.
Urang ngabagi tugas dina IEP kana 2 fase. Kahiji nyaéta fase utama, nu diwangun ku reworking protokol deployment. Éta parantos kalebet dina master, anjeun tiasa nyobian Service Grid énggal, anu bakal muncul dina versi 2.8. Fase kadua ngawengku loba tugas séjén:
- Panas redeploy
- Service versioning
- Ningkatkeun kasabaran kasalahan
- Klién ipis
- Alat pikeun ngawaskeun sareng ngitung rupa-rupa métrik
Tungtungna, urang tiasa mamatahan anjeun dina Service Grid pikeun ngawangun toleran lepat, sistem kasadiaan tinggi. Urang ogé ngajak anjeun nganjang kami di и babagi pangalaman Anjeun. Pangalaman anjeun penting pisan pikeun masarakat; éta bakal ngabantosan anjeun ngartos dimana ngalih salajengna, kumaha carana ngamekarkeun komponén di hareup.
sumber: www.habr.com