Noong Pebrero 26, nagsagawa kami ng Apache Ignite GreenSource meetup, kung saan nagsalita ang mga contributor sa open source na proyekto . Ang isang mahalagang kaganapan sa buhay ng komunidad na ito ay ang muling pagsasaayos ng bahagi , na nagbibigay-daan sa iyong direktang mag-deploy ng mga custom na microservice sa isang Ignite cluster. Nagsalita siya tungkol sa mahirap na prosesong ito sa meetup , software engineer at Apache Ignite contributor sa loob ng mahigit dalawang taon.
Magsimula tayo sa kung ano ang Apache Ignite sa pangkalahatan. Ito ay isang database na isang distributed Key/Value storage na may suporta para sa SQL, transactionality at caching. Bilang karagdagan, binibigyang-daan ka ng Ignite na direktang mag-deploy ng mga custom na serbisyo sa isang Ignite cluster. May access ang developer sa lahat ng tool na ibinibigay ng Ignite - mga istruktura ng data na ipinamahagi, Messaging, Streaming, Compute at Data Grid. Halimbawa, kapag gumagamit ng Data Grid, ang problema sa pangangasiwa ng isang hiwalay na imprastraktura para sa pag-iimbak ng data at, bilang kinahinatnan, ang mga nagresultang gastos sa overhead ay nawawala.
Gamit ang Service Grid API, maaari kang mag-deploy ng isang serbisyo sa pamamagitan lamang ng pagtukoy sa deployment scheme at, nang naaayon, ang serbisyo mismo sa configuration.
Karaniwan, ang deployment scheme ay isang indikasyon ng bilang ng mga instance na dapat i-deploy sa mga cluster node. Mayroong dalawang karaniwang mga scheme ng pag-deploy. Ang una ay ang Cluster Singleton: sa anumang partikular na oras, isang pagkakataon ng isang serbisyo ng gumagamit ang garantisadong magagamit sa cluster. Ang pangalawa ay Node Singleton: isang instance ng serbisyo ang naka-deploy sa bawat cluster node.
Maaari ding tukuyin ng user ang bilang ng mga instance ng serbisyo sa buong cluster at tukuyin ang isang predicate para sa pag-filter ng mga angkop na node. Sa sitwasyong ito, kakalkulahin mismo ng Service Grid ang pinakamainam na pamamahagi para sa pag-deploy ng mga serbisyo.
Bilang karagdagan, mayroong isang tampok tulad ng Affinity Service. Ang affinity ay isang function na tumutukoy sa kaugnayan ng mga susi sa mga partisyon at ang kaugnayan ng mga partido sa mga node sa topology. Gamit ang key, matutukoy mo ang pangunahing node kung saan nakaimbak ang data. Sa ganitong paraan maaari mong iugnay ang iyong sariling serbisyo sa isang key at affinity function na cache. Kung magbabago ang function ng affinity, magaganap ang awtomatikong redeployment. Sa ganitong paraan, ang serbisyo ay palaging matatagpuan malapit sa data na kailangan nitong manipulahin, at, nang naaayon, bawasan ang overhead ng pag-access ng impormasyon. Ang scheme na ito ay maaaring tawaging isang uri ng collocated computing.
Ngayong nalaman na natin kung ano ang kagandahan ng Service Grid, pag-usapan natin ang kasaysayan ng pag-unlad nito.
Ang nangyari kanina
Ang nakaraang pagpapatupad ng Service Grid ay batay sa transactional replicated system cache ng Ignite. Ang salitang "cache" sa Ignite ay tumutukoy sa storage. Ibig sabihin, hindi ito pansamantala, gaya ng iniisip mo. Sa kabila ng katotohanan na ang cache ay kinokopya at ang bawat node ay naglalaman ng buong set ng data, sa loob ng cache ay mayroon itong nakabahaging representasyon. Ito ay dahil sa pag-optimize ng storage.
Ano ang nangyari noong gustong i-deploy ng user ang serbisyo?
- Nag-subscribe ang lahat ng node sa cluster upang i-update ang data sa storage gamit ang built-in na mekanismo ng Continuous Query.
- Ang panimulang node, sa ilalim ng isang read-committed na transaksyon, ay gumawa ng tala sa database na naglalaman ng configuration ng serbisyo, kasama ang serialized na instance.
- Kapag naabisuhan ng isang bagong entry, kinakalkula ng coordinator ang pamamahagi batay sa configuration. Ang resultang bagay ay isinulat pabalik sa database.
- Kung ang isang node ay bahagi ng pamamahagi, kailangan itong i-deploy ng coordinator.
Ano ang hindi nababagay sa amin
Sa ilang mga punto nakarating kami sa konklusyon: hindi ito ang paraan upang gumana sa mga serbisyo. Mayroong ilang mga dahilan.
Kung may naganap na error sa panahon ng pag-deploy, maaari lamang itong malaman mula sa mga log ng node kung saan nangyari ang lahat. Nagkaroon lamang ng asynchronous na pag-deploy, kaya pagkatapos ibalik ang kontrol sa user mula sa paraan ng pag-deploy, kailangan ng ilang karagdagang oras upang simulan ang serbisyo - at sa panahong ito ay hindi makontrol ng user ang anuman. Upang mabuo pa ang Service Grid, lumikha ng mga bagong feature, makaakit ng mga bagong user at gawing mas madali ang buhay ng lahat, may kailangang baguhin.
Kapag nagdidisenyo ng bagong Grid ng Serbisyo, una sa lahat, gusto naming magbigay ng garantiya ng sabay-sabay na pag-deploy: sa sandaling bumalik ang user ng kontrol mula sa API, magagamit niya kaagad ang mga serbisyo. Nais ko ring bigyan ang nagpasimula ng kakayahang pangasiwaan ang mga error sa pag-deploy.
Bilang karagdagan, nais kong gawing simple ang pagpapatupad, ibig sabihin, lumayo sa mga transaksyon at muling pagbabalanse. Sa kabila ng katotohanan na ang cache ay ginagaya at walang pagbabalanse, ang mga problema ay lumitaw sa panahon ng isang malaking deployment na may maraming mga node. Kapag nagbago ang topology, kailangang magpalitan ng impormasyon ang mga node, at sa malaking deployment, maaaring tumimbang ng malaki ang data na ito.
Kapag ang topology ay hindi matatag, ang coordinator ay kailangang muling kalkulahin ang pamamahagi ng mga serbisyo. At sa pangkalahatan, kapag kailangan mong magtrabaho sa mga transaksyon sa isang hindi matatag na topology, maaari itong humantong sa mga error na mahirap hulaan.
Mga Problema
Ano ang mga pandaigdigang pagbabago nang walang kasamang mga problema? Ang una sa mga ito ay isang pagbabago sa topology. Kailangan mong maunawaan na sa anumang sandali, kahit na sa sandali ng pag-deploy ng serbisyo, maaaring pumasok o umalis ang isang node sa cluster. Higit pa rito, kung sa oras ng pag-deploy ang node ay sumali sa cluster, kinakailangan na palagiang ilipat ang lahat ng impormasyon tungkol sa mga serbisyo sa bagong node. At pinag-uusapan natin hindi lamang kung ano ang na-deploy na, kundi pati na rin ang tungkol sa kasalukuyan at hinaharap na mga deployment.
Ito ay isa lamang sa mga problema na maaaring kolektahin sa isang hiwalay na listahan:
- Paano mag-deploy ng mga statically configured na serbisyo sa node startup?
- Ang pag-iwan ng node mula sa cluster - ano ang gagawin kung ang node ay nagho-host ng mga serbisyo?
- Ano ang gagawin kung nagbago ang coordinator?
- Ano ang gagawin kung muling kumonekta ang kliyente sa cluster?
- Kailangan bang iproseso ang mga kahilingan sa activation/deactivation at paano?
- Paano kung tumawag sila para sa pagkasira ng cache, at mayroon kaming mga serbisyo ng affinity na nakatali dito?
At hindi lang iyon.
desisyon
Bilang target, pinili namin ang Event Driven approach sa pagpapatupad ng proseso ng komunikasyon gamit ang mga mensahe. Ang Ignite ay nagpapatupad na ng dalawang bahagi na nagpapahintulot sa mga node na mag-forward ng mga mensahe sa kanilang mga sarili - communication-spi at discovery-spi.
Binibigyang-daan ng komunikasyon-spi ang mga node na direktang makipag-usap at magpasa ng mga mensahe. Ito ay angkop para sa pagpapadala ng malaking halaga ng data. Binibigyang-daan ka ng Discovery-spi na magpadala ng mensahe sa lahat ng node sa cluster. Sa karaniwang pagpapatupad, ito ay ginagawa gamit ang isang ring topology. Mayroon ding integration sa Zookeeper, sa kasong ito, isang star topology ang ginagamit. Ang isa pang mahalagang punto na dapat tandaan ay ang pagtuklas-spi ay nagbibigay ng mga garantiya na ang mensahe ay tiyak na maihahatid sa tamang pagkakasunud-sunod sa lahat ng mga node.
Tingnan natin ang deployment protocol. Ang lahat ng kahilingan ng user para sa deployment at undeployment ay ipinapadala sa pamamagitan ng discovery-spi. Nagbibigay ito ng mga sumusunod garantiya:
- Ang kahilingan ay matatanggap ng lahat ng node sa cluster. Papayagan nito ang kahilingan na magpatuloy sa pagproseso kapag nagbago ang coordinator. Nangangahulugan din ito na sa isang mensahe, ang bawat node ay magkakaroon ng lahat ng kinakailangang metadata, gaya ng configuration ng serbisyo at ang serialized na instance nito.
- Ang mahigpit na pagkakasunud-sunod ng paghahatid ng mensahe ay nakakatulong sa paglutas ng mga salungatan sa pagsasaayos at pakikipagkumpitensya sa mga kahilingan.
- Dahil ang pagpasok ng node sa topology ay pinoproseso din sa pamamagitan ng discovery-spi, matatanggap ng bagong node ang lahat ng data na kinakailangan para sa pagtatrabaho sa mga serbisyo.
Kapag natanggap ang isang kahilingan, ang mga node sa cluster ay magpapatunay nito at lumikha ng mga gawain sa pagproseso. Ang mga gawaing ito ay nakapila at pagkatapos ay pinoproseso sa ibang thread ng isang hiwalay na manggagawa. Ito ay ipinatupad sa ganitong paraan dahil ang pag-deploy ay maaaring tumagal ng isang malaking tagal ng oras at maantala ang mamahaling daloy ng pagtuklas nang hindi matatagalan.
Ang lahat ng mga kahilingan mula sa queue ay pinoproseso ng deployment manager. Mayroon itong espesyal na manggagawa na kumukuha ng isang gawain mula sa pila na ito at magsisimula ito upang simulan ang pag-deploy. Pagkatapos nito, magaganap ang mga sumusunod na aksyon:
- Ang bawat node ay nakapag-iisa na kinakalkula ang pamamahagi salamat sa isang bagong deterministikong function ng pagtatalaga.
- Bumubuo ang mga node ng mensahe na may mga resulta ng deployment at ipadala ito sa coordinator.
- Pinagsasama-sama ng coordinator ang lahat ng mensahe at bubuo ng resulta ng buong proseso ng pag-deploy, na ipinapadala sa pamamagitan ng discovery-spi sa lahat ng node sa cluster.
- Kapag ang resulta ay natanggap, ang proseso ng pag-deploy ay nagtatapos, pagkatapos kung saan ang gawain ay tinanggal mula sa pila.
Bagong disenyong hinimok ng kaganapan: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Kung may naganap na error sa panahon ng pag-deploy, agad na isinasama ng node ang error na ito sa isang mensahe na ipinapadala nito sa coordinator. Pagkatapos ng pagsasama-sama ng mensahe, ang coordinator ay magkakaroon ng impormasyon tungkol sa lahat ng mga error sa panahon ng pag-deploy at ipapadala ang mensaheng ito sa pamamagitan ng discovery-spi. Magiging available ang impormasyon ng error sa anumang node sa cluster.
Ang lahat ng mahahalagang kaganapan sa Service Grid ay pinoproseso gamit ang operating algorithm na ito. Halimbawa, ang pagpapalit ng topology ay isa ring mensahe sa pamamagitan ng discovery-spi. At sa pangkalahatan, kung ihahambing sa dati, ang protocol ay naging medyo magaan at maaasahan. Sapat na upang mahawakan ang anumang sitwasyon sa panahon ng pag-deploy.
Anong sunod na mangyayari
Ngayon tungkol sa mga plano. Ang anumang malaking pagbabago sa proyektong Ignite ay nakumpleto bilang isang inisyatiba sa pagpapabuti ng Ignite, na tinatawag na isang IEP. Ang redesign ng Service Grid ay mayroon ding IEP - na may mapanuksong pamagat na "Pagbabago ng langis sa Grid ng Serbisyo". Ngunit sa katunayan, hindi namin pinalitan ang langis ng makina, ngunit ang buong makina.
Hinati namin ang mga gawain sa IEP sa 2 yugto. Ang una ay isang pangunahing yugto, na binubuo ng muling paggawa ng deployment protocol. Kasama na ito sa master, maaari mong subukan ang bagong Service Grid, na lalabas sa bersyon 2.8. Kasama sa ikalawang yugto ang maraming iba pang mga gawain:
- Mainit na muling pag-deploy
- Pag-bersyon ng serbisyo
- Nadagdagang fault tolerance
- Payat na kliyente
- Mga tool para sa pagsubaybay at pagkalkula ng iba't ibang sukatan
Sa wakas, maaari ka naming payuhan sa Service Grid para sa pagbuo ng fault-tolerant, high-availability system. Inaanyayahan ka rin naming bisitahin kami sa ΠΈ ibahagi ang iyong karanasan. Ang iyong karanasan ay talagang mahalaga para sa komunidad; makakatulong ito sa iyong maunawaan kung saan susunod na lilipat, kung paano bubuo ang bahagi sa hinaharap.
Pinagmulan: www.habr.com