Otsailaren 26an, Apache Ignite GreenSource topaketa bat egin genuen, non kode irekiko proiektuko laguntzaileek hitz egin zuten. . Komunitate honen bizitzako gertaera garrantzitsu bat osagaiaren berregituraketa izan zen , mikrozerbitzu pertsonalizatuak zuzenean Ignite kluster batean zabaltzeko aukera ematen duena. Prozesu zail honi buruz hitz egin zuen topaketan , software ingeniaria eta Apache Ignite kolaboratzailea bi urte baino gehiagoz.
Has gaitezen Apache Ignite orokorrean zer den. Gako/Balioen biltegiratze banatua den datu-base bat da, SQL, transakzionaltasuna eta cachea onartzen dituena. Gainera, Ignite-k zerbitzu pertsonalizatuak zuzenean inplementatzeko aukera ematen du Ignite kluster batean. Garatzaileak Ignite-k eskaintzen dituen tresna guztietarako sarbidea du: datu-egitura banatuak, Mezularitza, Streaming-a, Konputazioa eta Datuen Sarea. Adibidez, Data Grid erabiltzean, datuak biltegiratzeko azpiegitura bereizi bat administratzeko arazoa eta, ondorioz, ondoriozko gastu orokorrak desagertzen dira.
Service Grid APIa erabiliz, zerbitzu bat inplementatu dezakezu inplementazio-eskema eta, horren arabera, zerbitzua bera konfigurazioan zehaztuta.
Normalean, inplementazio-eskema bat kluster-nodoetan zabaldu behar den instantzia kopuruaren adierazlea da. Bi zabaltze-eskema tipiko daude. Lehenengoa Cluster Singleton da: edozein unetan, erabiltzaile-zerbitzu baten instantzia bat bermatuta dago klusterrean eskuragarri egongo dela. Bigarrena Node Singleton da: zerbitzuaren instantzia bat kluster-nodo bakoitzean zabaltzen da.
Erabiltzaileak kluster osoko zerbitzu-instantzia kopurua ere zehaztu dezake eta nodo egokiak iragazteko predikatu bat definitu. Egoera horretan, Service Grid-ek berak kalkulatuko du zerbitzuak zabaltzeko banaketa optimoa.
Horrez gain, Affinity Zerbitzua bezalako ezaugarri bat dago. Afinitatea partizioekiko gakoen erlazioa eta alderdiek topologiako nodoekiko erlazioa definitzen duen funtzioa da. Gakoa erabiliz, datuak gordetzen diren nodo nagusia zehaztu dezakezu. Horrela, zure zerbitzua gako eta afinitate funtzioen cache batekin lotu dezakezu. Afinitate-funtzioa aldatzen bada, birmoldaketa automatikoa gertatuko da. Horrela, zerbitzua manipulatu behar dituen datuetatik gertu kokatuko da beti, eta, horrenbestez, informazioa eskuratzeko gastuak murriztuko dira. Eskema honi konputazio kolokatu moduko bat dei daiteke.
Service Grid-en edertasuna zein den jakin dugunean, hitz egin dezagun bere garapen-historiari buruz.
Aurretik gertatutakoa
Service Grid-en aurreko inplementazioa Ignite-ren transakzio-sistema erreplikatuaren cachean oinarritzen zen. Ignite-n "cache" hitzak biltegiratzeari egiten dio erreferentzia. Hau da, hau ez da behin-behineko zerbait, pentsa litekeen bezala. Cachea errepikatu eta nodo bakoitzak datu multzo osoa eduki arren, cachearen barruan irudikapen partizionatua du. Biltegiratze optimizazioaren ondorioz gertatzen da.
Zer gertatu zen erabiltzaileak zerbitzua zabaldu nahi zuenean?
- Klusterreko nodo guztiak biltegiko datuak eguneratzeko harpidetu ziren Kontsulta Etengabeko mekanismoa erabiliz.
- Hasierako nodoak, irakurtzeko konprometitutako transakzio baten pean, zerbitzuaren konfigurazioa zuen datu-basean erregistro bat egin zuen, serializatutako instantzia barne.
- Sarrera berri baten berri ematean, koordinatzaileak konfigurazioaren arabera kalkulatu zuen banaketa. Sortutako objektua datu-basean idatzi zen.
- Nodo bat banaketaren parte bazen, koordinatzaileak zabaldu behar zuen.
Egokitzen ez zitzaiguna
Noizbait ondoriora iritsi ginen: hau ez da zerbitzuekin lan egiteko modua. Hainbat arrazoi zeuden.
Inplementazioan erroreren bat gertatuz gero, dena gertatu den nodoaren erregistroetan bakarrik aurkitu ahal izango da. Inplementazio asinkronoa baino ez zegoen, beraz, inplementazio metodotik erabiltzaileari kontrola itzuli ondoren, denbora gehigarri bat behar zen zerbitzua abiarazteko, eta denbora horretan erabiltzaileak ezin izan zuen ezer kontrolatu. Zerbitzu-sarea gehiago garatzeko, funtzio berriak sortzeko, erabiltzaile berriak erakartzeko eta guztion bizitza errazteko, zerbait aldatu behar da.
Service Grid berria diseinatzerakoan, lehenik eta behin hedapen sinkronoaren bermea eman nahi izan dugu: erabiltzaileak APItik kontrola itzuli bezain laster, berehala erabil ditzake zerbitzuak. Inplementazio akatsak kudeatzeko gaitasuna ere eman nahi izan diot abiarazleari.
Horrez gain, inplementazioa sinplifikatu nahi nuen, hots, transakzioetatik eta orekatzetik aldendu. Cachea errepikatu eta orekarik ez dagoen arren, arazoak sortu ziren nodo asko zituen inplementazio handi batean. Topologia aldatzen denean, nodoek informazioa trukatu behar dute, eta hedapen handi batekin, datu hauek pisu handia izan dezakete.
Topologia ezegonkorra zenean, koordinatzaileak zerbitzuen banaketa berriro kalkulatu behar zuen. Eta, oro har, topologia ezegonkor batean transakzioekin lan egin behar duzunean, horrek aurreikusteko zailak diren akatsak sor ditzake.
Problems
Zeintzuk dira aldaketa globalak horrekin batera arazorik gabe? Horietako lehenengoa topologia aldaketa izan zen. Ulertu behar duzu edozein unetan, baita zerbitzua zabaltzeko momentuan ere, nodo bat klusterra sartu edo irten daitekeela. Gainera, zabaltzeko unean nodoa klusterra batzen bada, beharrezkoa izango da zerbitzuei buruzko informazio guztia etengabe transferitzea nodo berrira. Eta jada zabaldutakoaz ez ezik, oraingo eta etorkizuneko hedatzeez ere ari gara.
Hau da aparteko zerrenda batean bil daitezkeen arazoetako bat:
- Nola zabaldu estatikoki konfiguratutako zerbitzuak nodoaren abiaraztean?
- Nodo bat klusteretik irtetea - zer egin nodoak zerbitzuak ostatatzen baditu?
- Zer egin koordinatzailea aldatu bada?
- Zer egin bezeroa klusterera berriro konektatzen bada?
- Aktibazio/desaktibazio eskaerak prozesatu behar dira eta nola?
- Zer gertatuko litzateke cache-a suntsitzeko eskatuko balute, eta kidetasun-zerbitzuak lotuta baditugu?
Eta hori ez da guztia.
Erabaki
Helburu gisa, Gertaeren araberako ikuspegia aukeratu dugu mezuen bidez prozesuen komunikazioa ezartzearekin. Ignite-k dagoeneko bi osagai inplementatzen ditu, nodoei mezuak beren artean birbidaltzeko aukera ematen dietenak - communication-spi eta discovery-spi.
Communication-spi-k nodoei zuzenean komunikatzeko eta mezuak birbidaltzeko aukera ematen die. Oso egokia da datu kopuru handiak bidaltzeko. Discovery-spi-k klusterreko nodo guztietara mezu bat bidaltzeko aukera ematen du. Inplementazio estandarrean, eraztun topologia erabiliz egiten da. Zookeeper-ekin ere integrazioa dago, kasu honetan izar topologia erabiltzen da. Azpimarratzekoa den beste puntu garrantzitsu bat da discovery-spi-k mezua behin betiko ordena egokian nodo guztietara bidaliko dela bermatzen duela.
Ikus dezagun hedapen-protokoloa. Erabiltzaileen eskaera guztiak inplementatzeko eta inplementatzeko eskaera guztiak discovery-spi bidez bidaltzen dira. Honek honako hau ematen du bermeak:
- Eskaera klusterreko nodo guztiek jasoko dute. Horri esker, eskaera prozesatzen jarraitu ahal izango da koordinatzailea aldatzen denean. Horrek ere esan nahi du mezu batean, nodo bakoitzak beharrezko metadatu guztiak izango dituela, hala nola zerbitzuaren konfigurazioa eta bere instantzia serializatua.
- Mezuak bidaltzeko ordena zorrotzak konfigurazio-gatazkak eta lehian dauden eskaerak konpontzen laguntzen du.
- Nodoaren topologian sarrera aurkikuntza-spi bidez ere prozesatzen denez, nodo berriak zerbitzuekin lan egiteko beharrezkoak diren datu guztiak jasoko ditu.
Eskaera bat jasotzen denean, klusterreko nodoek baliozkotzen dute eta prozesatzeko zereginak sortzen dituzte. Zeregin hauek ilaran jartzen ditu eta, ondoren, beste hari batean prozesatzen ditu aparteko langile batek. Modu honetan inplementatzen da hedapenak denbora asko behar duelako eta aurkikuntza-fluxu garestiak modu jasangaitzean atzeratu ditzakeelako.
Ilararen eskaera guztiak inplementazio-kudeatzaileak prozesatzen ditu. Langile berezi bat dauka zeregin bat ilara honetatik atera eta hasieratzen duena inplementazioari ekiteko. Horren ondoren, ekintza hauek gertatzen dira:
- Nodo bakoitzak modu independentean kalkulatzen du banaketa esleipen-funtzio determinista berri bati esker.
- Nodoek hedapenaren emaitzekin mezu bat sortzen dute eta koordinatzaileari bidaltzen diote.
- Koordinatzaileak mezu guztiak biltzen ditu eta inplementazio prozesu osoaren emaitza sortzen du, aurkikuntza-spi bidez bidaltzen dena klusterreko nodo guztietara.
- Emaitza jasotzen denean, inplementazio-prozesua amaitzen da eta, ondoren, zeregina ilaratik kentzen da.
Gertaerak gidatutako diseinu berria: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Inplementazioan errore bat gertatzen bada, nodoak berehala sartzen du errore hori koordinatzaileari bidaltzen dion mezu batean. Mezuak batu ondoren, koordinatzaileak inplementazioan zehar akats guztiei buruzko informazioa izango du eta mezu hau discovery-spi bidez bidaliko du. Erroreen informazioa klusterreko edozein nodotan egongo da eskuragarri.
Zerbitzu-sareko gertaera garrantzitsu guztiak algoritmo eragile hau erabiliz prozesatzen dira. Adibidez, topologia aldatzea discovery-spi bidezko mezua ere bada. Eta, oro har, lehen zegoenarekin alderatuta, protokoloa nahiko arina eta fidagarria izan zen. Inplementazioan zehar edozein egoera kudeatzeko nahikoa.
Zer gertatuko da gero
Orain planei buruz. Ignite proiektuaren edozein aldaketa garrantzitsu Ignite hobetzeko ekimen gisa osatzen da, IEP izenekoa. Service Grid birdiseinuak IEP bat ere badu - βOlio-aldaketa Zerbitzuen Sareanβ izenburu burlagarria duena. Baina, egia esan, ez genuen motorraren olioa aldatu, motor osoa baizik.
IEPko atazak 2 fasetan banatu ditugu. Lehenengoa fase nagusi bat da, hedapen-protokoloa berraztertzean datza. Dagoeneko masterrean sartuta dago, 2.8 bertsioan agertuko den Service Grid berria probatu dezakezu. Bigarren faseak beste zeregin asko ditu:
- Berregintze beroa
- Zerbitzuaren bertsioa
- Akatsen tolerantzia handitu
- Bezero mehea
- Hainbat neurketa kontrolatzeko eta kalkulatzeko tresnak
Azkenik, zerbitzu-sarearen inguruko aholkuak eman ditzakegu akatsak jasan ditzaketen eta erabilgarritasun handiko sistemak eraikitzeko. Gu bisitatzera ere gonbidatzen zaitugu ΠΈ partekatu zure esperientzia. Zure esperientzia oso garrantzitsua da komunitatearentzat; hurrengo nora mugitu eta etorkizunean osagaia nola garatu ulertzen lagunduko dizu.
Iturria: www.habr.com