Më 26 shkurt, ne mbajtëm një takim të Apache Ignite GreenSource, ku folën kontribuuesit në projektin me burim të hapur . Një ngjarje e rëndësishme në jetën e këtij komuniteti ishte ristrukturimi i komponentit , i cili ju lejon të vendosni mikroshërbime të personalizuara drejtpërdrejt në një grupim Ignite. Ai foli për këtë proces të vështirë në takim , inxhinier softuerësh dhe kontribues i Apache Ignite për më shumë se dy vjet.
Le të fillojmë me atë që është Apache Ignite në përgjithësi. Kjo është një bazë të dhënash që është një ruajtje e shpërndarë e çelësit/vlerës me mbështetje për SQL, transaksionalitet dhe memorie. Për më tepër, Ignite ju lejon të vendosni shërbime me porosi direkt në një grup Ignite. Zhvilluesi ka qasje në të gjitha mjetet që ofron Ignite - strukturat e të dhënave të shpërndara, Mesazhimi, Transmetimi, Llogaritja dhe Rrjeti i të Dhënave. Për shembull, kur përdorni Rrjetin e të Dhënave, problemi i administrimit të një infrastrukture të veçantë për ruajtjen e të dhënave dhe, si pasojë, kostot e përgjithshme që rezultojnë zhduken.
Duke përdorur API-në e rrjetit të shërbimit, mund të vendosni një shërbim thjesht duke specifikuar skemën e vendosjes dhe, në përputhje me rrethanat, vetë shërbimin në konfigurim.
Në mënyrë tipike, një skemë vendosjeje është një tregues i numrit të rasteve që duhet të vendosen në nyjet e grupimit. Ekzistojnë dy skema tipike të vendosjes. E para është Cluster Singleton: në çdo moment, një shembull i një shërbimi përdoruesi është i garantuar të jetë i disponueshëm në grup. E dyta është Node Singleton: një shembull i shërbimit vendoset në çdo nyje grupi.
Përdoruesi mund të specifikojë gjithashtu numrin e rasteve të shërbimit në të gjithë grupin dhe të përcaktojë një predikat për filtrimin e nyjeve të përshtatshme. Në këtë skenar, vetë rrjeti i shërbimit do të llogarisë shpërndarjen optimale për vendosjen e shërbimeve.
Për më tepër, ekziston një veçori e tillë si Shërbimi i Afinitetit. Afiniteti është një funksion që përcakton marrëdhënien e çelësave me ndarjet dhe marrëdhëniet e palëve me nyjet në topologji. Duke përdorur çelësin, mund të përcaktoni nyjen kryesore në të cilën ruhen të dhënat. Në këtë mënyrë ju mund të lidhni shërbimin tuaj me një memorie të fshehtë të funksionit kyç dhe afiniteti. Nëse funksioni i afinitetit ndryshon, do të ndodhë rivendosja automatike. Në këtë mënyrë, shërbimi do të vendoset gjithmonë afër të dhënave që i nevojiten për të manipuluar dhe, në përputhje me rrethanat, do të zvogëlojë shpenzimet e përgjithshme të aksesit në informacion. Kjo skemë mund të quhet një lloj llogaritje e përbashkët.
Tani që kemi kuptuar se cila është bukuria e Service Grid, le të flasim për historinë e zhvillimit të tij.
Çfarë ndodhi më parë
Implementimi i mëparshëm i Service Grid bazohej në memorien e sistemit të përsëritur transaksional të Ignite. Fjala "cache" në Ignite i referohet ruajtjes. Kjo do të thotë, kjo nuk është diçka e përkohshme, siç mund të mendoni. Përkundër faktit se cache është replikuar dhe secila nyje përmban të gjithë grupin e të dhënave, brenda në cache ajo ka një paraqitje të ndarë. Kjo është për shkak të optimizimit të ruajtjes.
Çfarë ndodhi kur përdoruesi donte të vendoste shërbimin?
- Të gjitha nyjet në grup u pajtuan për të përditësuar të dhënat në ruajtje duke përdorur mekanizmin e integruar të pyetjeve të vazhdueshme.
- Nyja inicuese, sipas një transaksioni të kryer me lexim, bëri një rekord në bazën e të dhënave që përmbante konfigurimin e shërbimit, duke përfshirë shembullin e serializuar.
- Kur u njoftua për një hyrje të re, koordinatori llogariti shpërndarjen bazuar në konfigurimin. Objekti që rezultoi u shkrua përsëri në bazën e të dhënave.
- Nëse një nyje ishte pjesë e shpërndarjes, koordinatori duhej ta vendoste atë.
Çfarë nuk na shkonte
Në një moment arritëm në përfundimin: kjo nuk është mënyra për të punuar me shërbimet. Kishte disa arsye.
Nëse ka ndodhur ndonjë gabim gjatë vendosjes, atëherë mund të zbulohej vetëm nga regjistrat e nyjës ku ndodhi gjithçka. Kishte vetëm vendosje asinkrone, kështu që pas kthimit të kontrollit te përdoruesi nga metoda e vendosjes, nevojitej pak kohë shtesë për të filluar shërbimin - dhe gjatë kësaj kohe përdoruesi nuk mund të kontrollonte asgjë. Për të zhvilluar më tej Rrjetin e Shërbimit, për të krijuar veçori të reja, për të tërhequr përdorues të rinj dhe për ta bërë jetën e të gjithëve më të lehtë, diçka duhet të ndryshojë.
Gjatë projektimit të Rrjetit të ri të Shërbimit, para së gjithash donim të siguronim një garanci për vendosjen sinkrone: sapo përdoruesi të kthente kontrollin nga API, ai mund të përdorte menjëherë shërbimet. Doja gjithashtu t'i jepja iniciatorit aftësinë për të trajtuar gabimet e vendosjes.
Për më tepër, doja të thjeshtoja zbatimin, domethënë, të largohesha nga transaksionet dhe ribalancimi. Përkundër faktit se cache është përsëritur dhe nuk ka balancim, problemet u shfaqën gjatë një vendosjeje të madhe me shumë nyje. Kur topologjia ndryshon, nyjet duhet të shkëmbejnë informacion, dhe me një vendosje të madhe, këto të dhëna mund të peshojnë shumë.
Kur topologjia ishte e paqëndrueshme, koordinatori duhej të rillogariste shpërndarjen e shërbimeve. Dhe në përgjithësi, kur duhet të punoni me transaksione në një topologji të paqëndrueshme, kjo mund të çojë në gabime të vështira për t'u parashikuar.
Problemet
Cilat janë ndryshimet globale pa probleme shoqëruese? E para prej tyre ishte një ndryshim në topologji. Duhet të kuptoni se në çdo moment, edhe në momentin e vendosjes së shërbimit, një nyje mund të hyjë ose të dalë nga grupi. Për më tepër, nëse në kohën e vendosjes nyja bashkohet me grupin, do të jetë e nevojshme që vazhdimisht të transferohen të gjitha informacionet rreth shërbimeve në nyjen e re. Dhe ne po flasim jo vetëm për atë që tashmë është vendosur, por edhe për vendosjet aktuale dhe të ardhshme.
Ky është vetëm një nga problemet që mund të mblidhen në një listë të veçantë:
- Si të vendosim shërbime të konfiguruara në mënyrë statike në fillimin e nyjeve?
- Lënia e një nyje nga grupi - çfarë të bëni nëse nyja pret shërbime?
- Çfarë duhet bërë nëse koordinatori ka ndryshuar?
- Çfarë duhet bërë nëse klienti rilidhet me grupin?
- A duhet të përpunohen kërkesat për aktivizim/çaktivizim dhe si?
- Po sikur të bënin thirrje për shkatërrimin e cache-it dhe ne kemi shërbime afiniteti të lidhura me të?
Dhe kjo nuk është e gjitha.
vendim
Si objektiv, ne zgjodhëm qasjen e drejtuar nga ngjarjet me zbatimin e komunikimit të procesit duke përdorur mesazhe. Ignite tashmë zbaton dy komponentë që lejojnë nyjet të përcjellin mesazhe mes tyre - komunikimi-spi dhe zbulimi-spi.
Communication-spi lejon nyjet të komunikojnë drejtpërdrejt dhe të përcjellin mesazhe. Është i përshtatshëm për dërgimin e sasive të mëdha të të dhënave. Discovery-spi ju lejon të dërgoni një mesazh te të gjitha nyjet në grup. Në zbatimin standard, kjo bëhet duke përdorur një topologji unazore. Ka edhe integrim me Zookeeper, në këtë rast përdoret një topologji ylli. Një pikë tjetër e rëndësishme që vlen të përmendet është se zbulimi-spi siguron garanci që mesazhi patjetër do të dërgohet në rendin e duhur në të gjitha nyjet.
Le të shohim protokollin e vendosjes. Të gjitha kërkesat e përdoruesve për vendosje dhe dislokim dërgohen përmes zbulimit-spi. Kjo jep sa vijon garancitë:
- Kërkesa do të merret nga të gjitha nyjet në grup. Kjo do të lejojë që kërkesa të vazhdojë përpunimin kur të ndryshojë koordinatori. Kjo do të thotë gjithashtu se në një mesazh, çdo nyje do të ketë të gjitha meta të dhënat e nevojshme, si p.sh. konfigurimin e shërbimit dhe shembullin e tij të serializuar.
- Renditja e rreptë e dërgimit të mesazheve ndihmon në zgjidhjen e konflikteve të konfigurimit dhe kërkesave konkurruese.
- Meqenëse hyrja e nyjës në topologji përpunohet gjithashtu nëpërmjet zbulimit-spi, nyja e re do të marrë të gjitha të dhënat e nevojshme për të punuar me shërbimet.
Kur merret një kërkesë, nyjet në grup e vërtetojnë atë dhe krijojnë detyra përpunimi. Këto detyra vendosen në radhë dhe më pas përpunohen në një fill tjetër nga një punëtor i veçantë. Zbatohet në këtë mënyrë sepse vendosja mund të marrë një sasi të konsiderueshme kohe dhe të vonojë rrjedhën e shtrenjtë të zbulimit në mënyrë të patolerueshme.
Të gjitha kërkesat nga radha përpunohen nga menaxheri i vendosjes. Ajo ka një punonjës të veçantë që tërheq një detyrë nga kjo radhë dhe e inicializon atë për të filluar vendosjen. Pas kësaj, ndodhin veprimet e mëposhtme:
- Çdo nyje llogarit në mënyrë të pavarur shpërndarjen falë një funksioni të ri të caktimit përcaktues.
- Nyjet gjenerojnë një mesazh me rezultatet e vendosjes dhe ia dërgojnë atë koordinatorit.
- Koordinatori grumbullon të gjitha mesazhet dhe gjeneron rezultatin e të gjithë procesit të vendosjes, i cili dërgohet nëpërmjet zbulimit-spi në të gjitha nyjet në grup.
- Kur merret rezultati, procesi i vendosjes përfundon, pas së cilës detyra hiqet nga radha.
Dizajni i ri i drejtuar nga ngjarjet: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Nëse ndodh një gabim gjatë vendosjes, nyja e përfshin menjëherë këtë gabim në një mesazh që i dërgon koordinatorit. Pas grumbullimit të mesazheve, koordinatori do të ketë informacion për të gjitha gabimet gjatë vendosjes dhe do ta dërgojë këtë mesazh përmes Discovery-spi. Informacioni i gabimit do të jetë i disponueshëm në çdo nyje në grup.
Të gjitha ngjarjet e rëndësishme në Rrjetin e Shërbimit përpunohen duke përdorur këtë algoritëm operativ. Për shembull, ndryshimi i topologjisë është gjithashtu një mesazh nëpërmjet zbulimit-spi. Dhe në përgjithësi, kur krahasohet me atë që ishte më parë, protokolli doli të ishte mjaft i lehtë dhe i besueshëm. Mjaft për të trajtuar çdo situatë gjatë vendosjes.
Çfarë do të ndodhë më pas
Tani për planet. Çdo ndryshim i madh në projektin Ignite përfundon si një iniciativë për përmirësimin e Ignite, e quajtur IEP. Ridizajnimi i Rrjetit të Shërbimit ka gjithashtu një IEP - me titullin tallës “Ndërrim vaji në rrjetin e shërbimit”. Por në fakt, ne nuk ndryshuam vajin e motorit, por të gjithë motorin.
Ne i ndamë detyrat në IEP në 2 faza. E para është një fazë kryesore, e cila konsiston në ripërpunimin e protokollit të vendosjes. Është përfshirë tashmë në master, mund të provoni Rrjetin e ri të Shërbimit, i cili do të shfaqet në versionin 2.8. Faza e dytë përfshin shumë detyra të tjera:
- Rishpërndarje e nxehtë
- Versionimi i shërbimit
- Rritja e tolerancës ndaj gabimeve
- Klient i hollë
- Mjete për monitorimin dhe llogaritjen e metrikave të ndryshme
Së fundi, ne mund t'ju këshillojmë për Rrjetin e Shërbimit për ndërtimin e sistemeve tolerante ndaj gabimeve dhe me disponueshmëri të lartë. Gjithashtu ju ftojmë të na vizitoni në и ndani përvojën tuaj. Përvoja juaj është vërtet e rëndësishme për komunitetin; do t'ju ndihmojë të kuptoni se ku të lëvizni më pas, si ta zhvilloni komponentin në të ardhmen.
Burimi: www.habr.com