Þann 26. febrúar héldum við Apache Ignite GreenSource fund þar sem þátttakendur í opna uppspretta verkefninu töluðu . Mikilvægur atburður í lífi þessa samfélags var endurskipulagning íhlutans , sem gerir þér kleift að dreifa sérsniðnum örþjónustum beint inn í Ignite þyrping. Hann talaði um þetta erfiða ferli á fundinum , hugbúnaðarverkfræðingur og Apache Ignite framlag í meira en tvö ár.
Við skulum byrja á því hvað Apache Ignite er almennt. Þetta er gagnagrunnur sem er dreifð Key/Value geymsla með stuðningi fyrir SQL, viðskipti og skyndiminni. Að auki gerir Ignite þér kleift að dreifa sérsniðnum þjónustum beint inn í Ignite þyrping. Verktaki hefur aðgang að öllum verkfærum sem Ignite býður upp á - dreifð gagnaskipulag, skilaboð, streymi, reikna og gagnanet. Til dæmis, þegar Data Grid er notað, hverfur vandamálið við að hafa umsjón með sérstökum innviðum fyrir gagnageymslu og þar af leiðandi kostnaður sem fylgir því.
Með því að nota Service Grid API geturðu sett upp þjónustu með því einfaldlega að tilgreina dreifingarkerfið og, í samræmi við það, þjónustuna sjálfa í uppsetningunni.
Venjulega er dreifingarkerfi vísbending um fjölda tilvika sem ætti að dreifa á klasahnútum. Það eru tvö dæmigerð dreifingarkerfi. Hið fyrra er Cluster Singleton: á hverjum tíma er tryggt að eitt tilvik af notendaþjónustu sé tiltækt í klasanum. Annað er Node Singleton: eitt tilvik af þjónustunni er sett á hvern klasahnút.
Notandinn getur einnig tilgreint fjölda þjónustutilvika í öllum klasanum og skilgreint forsögn til að sía viðeigandi hnúta. Í þessari atburðarás mun Service Grid sjálft reikna út bestu dreifingu til að dreifa þjónustu.
Að auki er til eiginleiki eins og Affinity Service. Sækni er fall sem skilgreinir tengsl lykla við skipting og tengsl aðila við hnúta í staðfræðinni. Með því að nota lykilinn geturðu ákvarðað aðalhnútinn sem gögnin eru geymd á. Þannig geturðu tengt þína eigin þjónustu við skyndiminni lykla og skyldleikaaðgerða. Ef skyldleikaaðgerðin breytist mun sjálfvirk endurdreifing eiga sér stað. Þannig verður þjónustan alltaf staðsett nálægt þeim gögnum sem hún þarf til að vinna með og dregur því úr kostnaði við aðgang að upplýsingum. Þetta kerfi má kalla eins konar samlokaða tölvuvinnslu.
Nú þegar við höfum komist að því hver fegurð Service Grid er, skulum við tala um þróunarsögu þess.
Hvað gerðist áður
Fyrri útfærsla Service Grid var byggð á Ignite endurteknu skyndiminni kerfisins. Orðið „skyndiminni“ í Ignite vísar til geymslu. Það er, þetta er ekki eitthvað tímabundið, eins og þú gætir haldið. Þrátt fyrir þá staðreynd að skyndiminni sé endurtekið og hver hnút inniheldur allt gagnasettið, hefur það inni í skyndiminni skipta framsetningu. Þetta er vegna hagræðingar á geymslu.
Hvað gerðist þegar notandinn vildi innleiða þjónustuna?
- Allir hnútar í þyrpingunni gerðust áskrifendur að uppfærslu gagna í geymslunni með því að nota innbyggða samfellda fyrirspurnarkerfið.
- Upphafshnúturinn, undir lesbundinni færslu, gerði skrá í gagnagrunninum sem innihélt þjónustustillinguna, þar á meðal raðaða tilvikið.
- Þegar tilkynnt var um nýja færslu reiknaði umsjónarmaður dreifinguna út frá uppsetningunni. Hluturinn sem varð til var skrifaður aftur í gagnagrunninn.
- Ef hnútur var hluti af dreifingunni þurfti samræmingarstjórinn að dreifa honum.
Hvað hentaði okkur ekki
Á einhverjum tímapunkti komumst við að þeirri niðurstöðu: svona er ekki hægt að vinna með þjónustu. Það voru nokkrar ástæður.
Ef einhver villa kom upp við dreifingu, þá var aðeins hægt að finna það úr annálum hnútsins þar sem allt gerðist. Aðeins var um ósamstillta uppsetningu að ræða, þannig að eftir að hafa skilað stjórn til notandans frá uppsetningaraðferðinni þurfti nokkurn viðbótartíma til að hefja þjónustuna - og á þessum tíma gat notandinn ekki stjórnað neinu. Til þess að þróa þjónustunetið frekar, búa til nýja eiginleika, laða að nýja notendur og gera líf allra auðveldara þarf eitthvað að breytast.
Þegar við hönnuðum nýja þjónustunetið vildum við fyrst og fremst veita tryggingu fyrir samstilltri dreifingu: um leið og notandinn skilaði stjórn frá API, gat hann strax notað þjónustuna. Ég vildi líka gefa frumkvöðlinum getu til að meðhöndla uppsetningarvillur.
Auk þess vildi ég einfalda framkvæmdina, nefnilega komast í burtu frá viðskiptum og endurjöfnun. Þrátt fyrir þá staðreynd að skyndiminni sé endurtekið og það er ekkert jafnvægi, komu upp vandamál við stóra dreifingu með mörgum hnútum. Þegar staðfræðin breytist þurfa hnútar að skiptast á upplýsingum og með mikilli dreifingu geta þessi gögn vegið mikið.
Þegar staðfræðin var óstöðug þurfti samræmingarstjórinn að endurreikna dreifingu þjónustunnar. Og almennt, þegar þú þarft að vinna með viðskipti á óstöðugri staðfræði, getur þetta leitt til villna sem erfitt er að spá fyrir um.
Vandamál
Hvað eru alþjóðlegar breytingar án fylgikvilla? Fyrsta þeirra var breyting á staðfræði. Þú þarft að skilja að hvenær sem er, jafnvel á því augnabliki sem þjónustu er dreifing, getur hnútur farið inn í eða farið úr þyrpingunni. Þar að auki, ef á þeim tíma sem hnúturinn er dreifður, tengist þyrpingunni, verður nauðsynlegt að flytja allar upplýsingar um þjónustuna stöðugt yfir á nýja hnútinn. Og við erum ekki aðeins að tala um það sem þegar hefur verið sent, heldur einnig um núverandi og framtíðaruppsetningar.
Þetta er aðeins eitt af vandamálunum sem hægt er að safna í sérstakan lista:
- Hvernig á að dreifa kyrrstöðu stilltri þjónustu við ræsingu hnúts?
- Að yfirgefa hnút úr klasanum - hvað á að gera ef hnúturinn hýsti þjónustu?
- Hvað á að gera ef umsjónarmaður hefur breyst?
- Hvað á að gera ef viðskiptavinurinn tengist aftur við þyrpinguna?
- Þarf að vinna úr virkjunar-/afvirkjunarbeiðnum og hvernig?
- Hvað ef þeir kölluðu eftir eyðingu skyndiminni og við höfum skyldleikaþjónustu tengda því?
Og það er ekki allt.
ákvörðun
Sem markmið völdum við Event Driven nálgun með innleiðingu á ferlisamskiptum með skilaboðum. Ignite útfærir nú þegar tvo þætti sem gera hnútum kleift að senda skilaboð sín á milli - samskipti-spi og uppgötvun-spi.
Communication-spi gerir hnútum kleift að hafa bein samskipti og framsenda skilaboð. Það hentar vel til að senda mikið magn af gögnum. Discovery-spi gerir þér kleift að senda skilaboð til allra hnúta í klasanum. Í stöðluðu útfærslunni er þetta gert með því að nota hringlaga svæðisfræði. Það er líka samþætting við Zookeeper, í þessu tilfelli er stjörnusvæðisfræði notuð. Annað mikilvægt atriði sem vert er að taka fram er að Discovery-spi veitir tryggingu fyrir því að skilaboðin verði örugglega afhent í réttri röð til allra hnúta.
Við skulum líta á dreifingarreglurnar. Allar notendabeiðnir um dreifingu og afdreifingu eru sendar í gegnum discovery-spi. Þetta gefur eftirfarandi ábyrgðir:
- Beiðnin mun berast öllum hnútum í klasanum. Þetta gerir beiðninni kleift að halda áfram afgreiðslu þegar umsjónarmaður breytist. Þetta þýðir líka að í einni skilaboðum mun hver hnút hafa öll nauðsynleg lýsigögn, svo sem þjónustustillingu og raðbundið tilvik.
- Strangar röðun skilaboðasendingar hjálpar til við að leysa uppsetningarárekstra og samkeppnisbeiðnir.
- Þar sem innganga hnútsins í staðfræði er einnig unnin í gegnum Discovery-spi, mun nýi hnúturinn fá öll nauðsynleg gögn til að vinna með þjónustu.
Þegar beiðni er móttekin, staðfesta hnútar í klasanum hana og búa til vinnsluverkefni. Þessi verkefni eru sett í biðröð og síðan unnin í öðrum þræði af sérstökum starfsmanni. Það er útfært með þessum hætti vegna þess að uppsetning getur tekið talsverðan tíma og tafið dýra uppgötvunarflæðið óþolandi.
Allar beiðnir úr biðröðinni eru unnar af dreifingarstjóra. Það hefur sérstakan starfsmann sem dregur verkefni úr þessari biðröð og frumstillir það til að hefja dreifingu. Eftir þetta eiga sér stað eftirfarandi aðgerðir:
- Hver hnút reiknar sjálfstætt út dreifinguna þökk sé nýrri deterministic úthlutunaraðgerð.
- Hnútar búa til skilaboð með niðurstöðum dreifingarinnar og senda þau til samræmingarstjórans.
- Samhæfingarstjórinn safnar saman öllum skilaboðum og býr til niðurstöðu alls dreifingarferlisins, sem er send með Discovery-spi til allra hnúta í klasanum.
- Þegar niðurstaðan er móttekin lýkur dreifingarferlinu, eftir það er verkefnið fjarlægt úr biðröðinni.
Ný atburðadrifin hönnun: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ef villa kemur upp meðan á dreifingu stendur tekur hnúturinn þessa villu strax með í skilaboðum sem hann sendir til samræmingarstjórans. Eftir samsöfnun skilaboða mun umsjónarmaðurinn hafa upplýsingar um allar villur meðan á dreifingu stendur og mun senda þessi skilaboð í gegnum discovery-spi. Villuupplýsingar verða tiltækar á hvaða hnút sem er í klasanum.
Allir mikilvægir atburðir í þjónustunetinu eru unnin með þessu rekstraralgrími. Til dæmis, að breyta staðfræði er einnig skilaboð í gegnum Discovery-spi. Og almennt, miðað við það sem var áður, reyndist siðareglur vera frekar léttar og áreiðanlegar. Nóg til að takast á við allar aðstæður meðan á dreifingu stendur.
Hvað mun gerast næst
Nú um áformin. Öllum meiriháttar breytingum á Ignite verkefninu er lokið sem Ignite umbótaverkefni, kallað IEP. Endurhönnun þjónustunetsins er einnig með IEP - með háðsheitinu „Olíuskipti á þjónustunetinu“. En í raun skiptum við ekki um vélarolíu, heldur alla vélina.
Við skiptum verkefnum í IEP í 2 áfanga. Sá fyrsti er stór áfangi, sem samanstendur af endurvinnslu á dreifingarreglunni. Það er nú þegar innifalið í masternum, þú getur prófað nýja þjónustunetið, sem mun birtast í útgáfu 2.8. Seinni áfanginn inniheldur mörg önnur verkefni:
- Heitt endurskipuleggja
- Útgáfa þjónustu
- Aukið bilanaþol
- Þunnur viðskiptavinur
- Verkfæri til að fylgjast með og reikna út ýmsar mælikvarðar
Að lokum getum við ráðlagt þér um þjónustunet til að byggja upp bilunarþolin kerfi með mikið aðgengi. Einnig bjóðum við þér að heimsækja okkur kl и deila reynslu þinni. Reynsla þín er mjög mikilvæg fyrir samfélagið; hún mun hjálpa þér að skilja hvert þú átt að flytja næst, hvernig á að þróa íhlutinn í framtíðinni.
Heimild: www.habr.com