26. februÄrÄ« mÄs rÄ«kojÄm Apache Ignite GreenSource tikÅ”anos, kurÄ uzstÄjÄs atvÄrtÄ pirmkoda projekta dalÄ«bnieki. . SvarÄ«gs notikums Ŕīs kopienas dzÄ«vÄ bija komponenta pÄrstrukturÄÅ”ana , kas ļauj izvietot pielÄgotus mikropakalpojumus tieÅ”i Ignite klasterÄ«. ViÅÅ” tikÅ”anÄs reizÄ stÄstÄ«ja par Å”o grÅ«to procesu , programmatÅ«ras inženieris un Apache Ignite lÄ«dzstrÄdnieks vairÄk nekÄ divus gadus.
SÄksim ar to, kas vispÄr ir Apache Ignite. Å Ä« ir datu bÄze, kas ir sadalÄ«ta atslÄgu/vÄrtÄ«bu krÄtuve ar SQL, transakciju un keÅ”atmiÅas atbalstu. TurklÄt Ignite ļauj izvietot pielÄgotos pakalpojumus tieÅ”i Ignite klasterÄ«. IzstrÄdÄtÄjam ir piekļuve visiem Ignite piedÄvÄtajiem rÄ«kiem ā izplatÄ«tajÄm datu struktÅ«rÄm, ziÅojumapmaiÅai, straumÄÅ”anai, skaitļoÅ”anai un datu režģim. PiemÄram, izmantojot Data Grid, pazÅ«d atseviŔķas infrastruktÅ«ras administrÄÅ”anas problÄma datu uzglabÄÅ”anai un lÄ«dz ar to saistÄ«tÄs pieskaitÄmÄs izmaksas.
Izmantojot Service Grid API, varat izvietot pakalpojumu, vienkÄrÅ”i norÄdot izvietoÅ”anas shÄmu un attiecÄ«gi arÄ« paÅ”u pakalpojumu konfigurÄcijÄ.
Parasti izvietoÅ”anas shÄma norÄda gadÄ«jumu skaitu, kas jÄizvieto klasteru mezglos. Ir divas tipiskas izvietoÅ”anas shÄmas. Pirmais ir Cluster Singleton: jebkurÄ laikÄ tiek garantÄts, ka klasterÄ« bÅ«s pieejams viens lietotÄja pakalpojuma gadÄ«jums. Otrais ir Node Singleton: katrÄ klastera mezglÄ tiek izvietots viens pakalpojuma gadÄ«jums.
LietotÄjs var arÄ« norÄdÄ«t pakalpojumu gadÄ«jumu skaitu visÄ klasterÄ« un definÄt predikÄtu piemÄrotu mezglu filtrÄÅ”anai. Å ajÄ scenÄrijÄ Service Grid pats aprÄÄ·inÄs optimÄlo pakalpojumu izvietoÅ”anas sadalÄ«jumu.
TurklÄt ir tÄda funkcija kÄ Affinity Service. AfinitÄte ir funkcija, kas nosaka atslÄgu attiecÄ«bas ar nodalÄ«jumiem un puÅ”u attiecÄ«bas ar topoloÄ£ijas mezgliem. Izmantojot atslÄgu, varat noteikt primÄro mezglu, kurÄ dati tiek glabÄti. TÄdÄ veidÄ jÅ«s varat saistÄ«t savu pakalpojumu ar atslÄgu un radniecÄ«bas funkciju keÅ”atmiÅu. Ja afinitÄtes funkcija mainÄs, notiks automÄtiska pÄrizvietoÅ”ana. TÄdÄ veidÄ pakalpojums vienmÄr atradÄ«sies tuvu datiem, ar kuriem tam nepiecieÅ”ams manipulÄt, un attiecÄ«gi samazinÄsies informÄcijas piekļuves izmaksas. Å o shÄmu var saukt par sava veida kolokÄto skaitļoÅ”anu.
Tagad, kad esam sapratuÅ”i, kas ir Service Grid skaistums, parunÄsim par tÄ attÄ«stÄ«bas vÄsturi.
Kas notika iepriekÅ”
IepriekÅ”ÄjÄ Service Grid ievieÅ”ana balstÄ«jÄs uz Ignite transakciju replicÄto sistÄmas keÅ”atmiÅu. VÄrds "keÅ”atmiÅa" programmÄ Ignite attiecas uz krÄtuvi. Tas ir, tas nav kaut kas Ä«slaicÄ«gs, kÄ jÅ«s varÄtu domÄt. Neskatoties uz to, ka keÅ”atmiÅa tiek replicÄta un katrs mezgls satur visu datu kopu, keÅ”atmiÅÄ tai ir sadalÄ«ts attÄlojums. Tas ir saistÄ«ts ar krÄtuves optimizÄciju.
Kas notika, kad lietotÄjs vÄlÄjÄs izvietot pakalpojumu?
- Visi klastera mezgli abonÄja datu atjauninÄÅ”anu krÄtuvÄ, izmantojot iebÅ«vÄto nepÄrtrauktÄs vaicÄjuma mehÄnismu.
- SÄkotnÄjais mezgls lasÄ«Å”anas transakcijÄ datu bÄzÄ izveidoja ierakstu, kurÄ bija pakalpojuma konfigurÄcija, tostarp sÄrijveida instance.
- Kad tika paziÅots par jaunu ierakstu, koordinators aprÄÄ·inÄja sadalÄ«jumu, pamatojoties uz konfigurÄciju. IegÅ«tais objekts tika ierakstÄ«ts atpakaļ datu bÄzÄ.
- Ja mezgls bija daļa no izplatÄ«Å”anas, koordinatoram tas bija jÄizvieto.
Kas mums nederÄja
KÄdÄ brÄ«dÄ« mÄs nonÄcÄm pie secinÄjuma: tas nav veids, kÄ strÄdÄt ar pakalpojumiem. Bija vairÄki iemesli.
Ja izvietoÅ”anas laikÄ radÄs kÄda kļūda, tad to varÄja uzzinÄt tikai no tÄ mezgla žurnÄliem, kur viss notika. Bija tikai asinhrona izvietoÅ”ana, tÄpÄc pÄc kontroles atgrieÅ”anas lietotÄjam no izvietoÅ”anas metodes, pakalpojuma palaiÅ”anai bija nepiecieÅ”ams papildu laiks - un Å”ajÄ laikÄ lietotÄjs neko nevarÄja kontrolÄt. Lai tÄlÄk attÄ«stÄ«tu Service Grid, radÄ«tu jaunas iespÄjas, piesaistÄ«tu jaunus lietotÄjus un atvieglotu ikviena dzÄ«vi, kaut kas ir jÄmaina.
IzstrÄdÄjot jauno Service Grid, mÄs, pirmkÄrt, vÄlÄjÄmies nodroÅ”inÄt sinhronas izvietoÅ”anas garantiju: tiklÄ«dz lietotÄjs atgrieza kontroli no API, viÅÅ” varÄja nekavÄjoties izmantot pakalpojumus. Es arÄ« gribÄju dot iniciatoram iespÄju rÄ«koties ar izvietoÅ”anas kļūdÄm.
TurklÄt es gribÄju vienkÄrÅ”ot ievieÅ”anu, proti, atbrÄ«voties no darÄ«jumiem un lÄ«dzsvaroÅ”anas. Neskatoties uz to, ka keÅ”atmiÅa tiek replicÄta un nav lÄ«dzsvaroÅ”anas, problÄmas radÄs lielas izvietoÅ”anas laikÄ ar daudziem mezgliem. Kad topoloÄ£ija mainÄs, mezgliem ir jÄapmainÄs ar informÄciju, un ar lielu izvietoÅ”anu Å”ie dati var svÄrt daudz.
Kad topoloÄ£ija bija nestabila, koordinatoram bija jÄpÄrrÄÄ·ina pakalpojumu sadalÄ«jums. Un vispÄr, ja jums ir jÄstrÄdÄ ar darÄ«jumiem ar nestabilu topoloÄ£iju, tas var izraisÄ«t grÅ«ti paredzamas kļūdas.
ProblÄmas
Kas ir globÄlas pÄrmaiÅas bez pavadoÅ”Äm problÄmÄm? PirmÄ no tÄm bija topoloÄ£ijas maiÅa. Jums jÄsaprot, ka jebkurÄ brÄ«dÄ«, pat pakalpojuma izvietoÅ”anas brÄ«dÄ«, mezgls var ienÄkt klasterÄ« vai iziet no tÄ. TurklÄt, ja izvietoÅ”anas laikÄ mezgls pievienojas klasterim, visa informÄcija par pakalpojumiem bÅ«s konsekventi jÄpÄrsÅ«ta uz jauno mezglu. Un mÄs runÄjam ne tikai par to, kas jau ir izvietots, bet arÄ« par paÅ”reizÄjo un turpmÄko izvietoÅ”anu.
Å Ä« ir tikai viena no problÄmÄm, ko var apkopot atseviÅ”Ä·Ä sarakstÄ:
- KÄ mezgla startÄÅ”anas laikÄ izvietot statiski konfigurÄtus pakalpojumus?
- Mezgla atstÄÅ”ana no klastera ā ko darÄ«t, ja mezglÄ tiek mitinÄti pakalpojumi?
- Ko darīt, ja ir mainījies koordinators?
- Ko darÄ«t, ja klients atkÄrtoti izveido savienojumu ar klasteru?
- Vai un kÄ ir jÄapstrÄdÄ aktivizÄÅ”anas/deaktivizÄÅ”anas pieprasÄ«jumi?
- KÄ bÅ«tu, ja viÅi aicinÄtu iznÄ«cinÄt keÅ”atmiÅu, un mums ir ar to saistÄ«ti radniecÄ«bas pakalpojumi?
Un tas vÄl nav viss.
Å Ä·Ä«dums
KÄ mÄrÄ·i mÄs izvÄlÄjÄmies uz notikumu balstÄ«tu pieeju ar procesa komunikÄcijas ievieÅ”anu, izmantojot ziÅojumus. Ignite jau ievieÅ” divus komponentus, kas ļauj mezgliem pÄrsÅ«tÄ«t ziÅojumus savÄ starpÄ - communication-spi un discovery-spi.
Communication-spi ļauj mezgliem tieÅ”i sazinÄties un pÄrsÅ«tÄ«t ziÅojumus. Tas ir labi piemÄrots liela datu apjoma nosÅ«tÄ«Å”anai. Discovery-spi ļauj nosÅ«tÄ«t ziÅojumu visiem klastera mezgliem. Standarta ievieÅ”anÄ tas tiek darÄ«ts, izmantojot gredzena topoloÄ£iju. Ir arÄ« integrÄcija ar Zookeeper, Å”ajÄ gadÄ«jumÄ tiek izmantota zvaigžÅu topoloÄ£ija. VÄl viens svarÄ«gs punkts, ko vÄrts atzÄ«mÄt, ir tas, ka discovery-spi nodroÅ”ina garantijas, ka ziÅojums noteikti tiks piegÄdÄts pareizajÄ secÄ«bÄ uz visiem mezgliem.
ApskatÄ«sim izvietoÅ”anas protokolu. Visi lietotÄju pieprasÄ«jumi izvietoÅ”anai un atcelÅ”anai tiek nosÅ«tÄ«ti, izmantojot discovery-spi. Tas dod sekojoÅ”o garantija:
- PieprasÄ«jumu saÅems visi klastera mezgli. Tas ļaus turpinÄt pieprasÄ«juma apstrÄdi, kad mainÄs koordinators. Tas arÄ« nozÄ«mÄ, ka vienÄ ziÅojumÄ katram mezglam bÅ«s visi nepiecieÅ”amie metadati, piemÄram, pakalpojuma konfigurÄcija un tÄ seriÄlÄ instance.
- Stingra ziÅojumu piegÄdes secÄ«ba palÄ«dz atrisinÄt konfigurÄcijas konfliktus un konkurÄjoÅ”us pieprasÄ«jumus.
- TÄ kÄ mezgla iekļūŔana topoloÄ£ijÄ tiek apstrÄdÄta arÄ« caur discovery-spi, jaunais mezgls saÅems visus darbam ar pakalpojumiem nepiecieÅ”amos datus.
Kad pieprasÄ«jums tiek saÅemts, klastera mezgli to apstiprina un izveido apstrÄdes uzdevumus. Å os uzdevumus ievieto rindÄ un pÄc tam atseviŔķs darbinieks apstrÄdÄ citÄ pavedienÄ. Tas tiek Ä«stenots Å”ÄdÄ veidÄ, jo izvietoÅ”ana var aizÅemt ievÄrojamu laiku un nepanesami aizkavÄt dÄrgo atklÄjumu plÅ«smu.
Visus pieprasÄ«jumus no rindas apstrÄdÄ izvietoÅ”anas pÄrvaldnieks. Tam ir Ä«paÅ”s darbinieks, kas izvelk uzdevumu no Ŕīs rindas un inicializÄ to, lai sÄktu izvietoÅ”anu. PÄc tam tiek veiktas Å”Ädas darbÄ«bas:
- Katrs mezgls neatkarÄ«gi aprÄÄ·ina sadalÄ«jumu, pateicoties jaunai deterministiskajai pieŔķirÅ”anas funkcijai.
- Mezgli Ä£enerÄ ziÅojumu ar izvietoÅ”anas rezultÄtiem un nosÅ«ta to koordinatoram.
- Koordinators apkopo visus ziÅojumus un Ä£enerÄ visa izvietoÅ”anas procesa rezultÄtu, kas tiek nosÅ«tÄ«ts, izmantojot discovery-spi, visiem klastera mezgliem.
- Kad rezultÄts tiek saÅemts, izvietoÅ”anas process beidzas, pÄc kura uzdevums tiek noÅemts no rindas.
Jauns uz notikumu orientÄts dizains: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ja izvietoÅ”anas laikÄ rodas kļūda, mezgls nekavÄjoties iekļauj Å”o kļūdu ziÅojumÄ, ko tas nosÅ«ta koordinatoram. PÄc ziÅojumu apkopoÅ”anas koordinatoram bÅ«s informÄcija par visÄm izvietoÅ”anas laikÄ pieļautajÄm kļūdÄm un viÅÅ” nosÅ«tÄ«s Å”o ziÅojumu, izmantojot discovery-spi. InformÄcija par kļūdÄm bÅ«s pieejama jebkurÄ klastera mezglÄ.
Visi svarÄ«gie notikumi Service Grid tiek apstrÄdÄti, izmantojot Å”o darbÄ«bas algoritmu. PiemÄram, topoloÄ£ijas maiÅa ir arÄ« ziÅojums, izmantojot discovery-spi. Un kopumÄ, salÄ«dzinot ar to, kas bija iepriekÅ”, protokols izrÄdÄ«jÄs diezgan viegls un uzticams. Pietiekami, lai tiktu galÄ ar jebkuru situÄciju izvietoÅ”anas laikÄ.
Kas notiks tÄlÄk
Tagad par plÄniem. Jebkuras bÅ«tiskas izmaiÅas Ignite projektÄ tiek pabeigtas kÄ Ignite uzlaboÅ”anas iniciatÄ«va, ko sauc par IEP. Service Grid pÄrprojektÄÅ”anai ir arÄ« IEP - ar izsmejoÅ”u nosaukumu āEļļas maiÅa servisa tÄ«klÄā. Bet patiesÄ«bÄ mÄs nemainÄ«jÄm motoreļļu, bet gan visu dzinÄju.
MÄs IEP uzdevumus sadalÄ«jÄm 2 fÄzÄs. Pirmais ir galvenais posms, kas sastÄv no izvietoÅ”anas protokola pÄrstrÄdÄÅ”anas. Tas jau ir iekļauts galvenajÄ, varat izmÄÄ£inÄt jauno Service Grid, kas parÄdÄ«sies 2.8 versijÄ. OtrajÄ posmÄ ietilpst daudzi citi uzdevumi:
- KarstÄ pÄrizvietoÅ”ana
- Pakalpojuma versiju noteikŔana
- PaaugstinÄta kļūdu tolerance
- PlÄns klients
- RÄ«ki dažÄdu metriku uzraudzÄ«bai un aprÄÄ·inÄÅ”anai
Visbeidzot, mÄs varam sniegt padomus par Service Grid, lai izveidotu defektizturÄ«gas augstas pieejamÄ«bas sistÄmas. AicinÄm arÄ« jÅ«s apmeklÄt mÅ«s plkst Šø dalieties pieredzÄ. JÅ«su pieredze ir ļoti svarÄ«ga sabiedrÄ«bai, tÄ palÄ«dzÄs saprast, kur virzÄ«ties tÄlÄk, kÄ attÄ«stÄ«t komponentu nÄkotnÄ.
Avots: www.habr.com