Mnamo Februari 26, tulifanya mkutano wa Apache Ignite GreenSource, ambapo wachangiaji wa mradi wa chanzo huria walizungumza. . Tukio muhimu katika maisha ya jumuiya hii lilikuwa urekebishaji wa sehemu hiyo , ambayo hukuruhusu kupeleka huduma ndogo ndogo moja kwa moja kwenye nguzo ya Ignite. Alizungumza juu ya mchakato huu mgumu kwenye mkutano , mhandisi wa programu na mchangiaji wa Apache Ignite kwa zaidi ya miaka miwili.
Wacha tuanze na Apache Ignite ni kwa ujumla. Hii ni hifadhidata ambayo ni uhifadhi wa Ufunguo/Thamani uliosambazwa na usaidizi wa SQL, shughuli na uakibishaji. Kwa kuongeza, Ignite hukuruhusu kupeleka huduma maalum moja kwa moja kwenye nguzo ya Ignite. Msanidi anaweza kufikia zana zote ambazo Ignite hutoa - miundo ya data iliyosambazwa, Ujumbe, Utiririshaji, Kokotoo na Gridi ya Data. Kwa mfano, wakati wa kutumia Gridi ya Takwimu, shida ya kusimamia miundombinu tofauti ya uhifadhi wa data na, kwa sababu hiyo, gharama zinazosababishwa hupotea.
Kutumia API ya Gridi ya Huduma, unaweza kupeleka huduma kwa kutaja tu mpango wa kupeleka na, ipasavyo, huduma yenyewe katika usanidi.
Kwa kawaida, mpango wa kupeleka ni dalili ya idadi ya matukio ambayo yanapaswa kutumwa kwenye nodi za nguzo. Kuna mifumo miwili ya kawaida ya kupeleka. Ya kwanza ni Cluster Singleton: kwa wakati wowote, mfano mmoja wa huduma ya mtumiaji umehakikishiwa kupatikana kwenye nguzo. Ya pili ni Node Singleton: mfano mmoja wa huduma huwekwa kwenye kila nodi ya nguzo.
Mtumiaji pia anaweza kutaja idadi ya matukio ya huduma katika nguzo nzima na kufafanua kiima cha kuchuja nodi zinazofaa. Katika hali hii, Gridi ya Huduma yenyewe itahesabu usambazaji bora wa kupeleka huduma.
Kwa kuongeza, kuna kipengele kama Huduma ya Ushirika. Uhusiano ni kazi inayofafanua uhusiano wa funguo za partitions na uhusiano wa vyama kwa nodes katika topolojia. Kutumia ufunguo, unaweza kuamua node ya msingi ambayo data huhifadhiwa. Kwa njia hii unaweza kuhusisha huduma yako mwenyewe na kashe ya utendakazi wa ufunguo na mshikamano. Ikiwa kazi ya mshikamano itabadilika, uwekaji upya wa kiotomatiki utatokea. Kwa njia hii, huduma itakuwa iko karibu na data inayohitaji kudhibiti, na, ipasavyo, kupunguza upeo wa kupata habari. Mpango huu unaweza kuitwa aina ya kompyuta iliyogawanywa.
Sasa kwa kuwa tumegundua uzuri wa Gridi ya Huduma ni nini, hebu tuzungumze kuhusu historia yake ya maendeleo.
Nini kilitokea kabla
Utekelezaji wa awali wa Gridi ya Huduma ulitokana na akiba ya mfumo wa muamala wa Ignite. Neno "cache" katika Ignite hurejelea hifadhi. Hiyo ni, hii sio kitu cha muda, kama unavyoweza kufikiria. Licha ya ukweli kwamba kashe inarudiwa na kila nodi ina seti nzima ya data, ndani ya kache ina uwakilishi uliogawanywa. Hii ni kutokana na uboreshaji wa hifadhi.
Ni nini kilifanyika wakati mtumiaji alitaka kupeleka huduma?
- Nodi zote katika kundi zilijisajili ili kusasisha data kwenye hifadhi kwa kutumia utaratibu wa Hoji Endelevu uliojengewa ndani.
- Nodi ya uanzishaji, chini ya shughuli iliyofanywa na kusoma, ilifanya rekodi katika hifadhidata iliyokuwa na usanidi wa huduma, ikijumuisha tukio la mfululizo.
- Alipoarifiwa kuhusu ingizo jipya, mratibu alikokotoa usambazaji kulingana na usanidi. Kitu kilichosababisha kiliandikwa nyuma kwenye hifadhidata.
- Ikiwa nodi ilikuwa sehemu ya usambazaji, mratibu alilazimika kuipeleka.
Nini haikutufaa
Wakati fulani tulifikia hitimisho: hii sio njia ya kufanya kazi na huduma. Kulikuwa na sababu kadhaa.
Ikiwa hitilafu fulani ilitokea wakati wa kupelekwa, basi inaweza kupatikana tu kutoka kwa magogo ya nodi ambapo kila kitu kilifanyika. Kulikuwa na uwekaji wa asynchronous tu, hivyo baada ya kurejesha udhibiti kwa mtumiaji kutoka kwa njia ya kupeleka, muda wa ziada ulihitajika ili kuanza huduma - na wakati huu mtumiaji hakuweza kudhibiti chochote. Ili kuendeleza Gridi ya Huduma zaidi, unda vipengele vipya, kuvutia watumiaji wapya na kurahisisha maisha ya kila mtu, kuna kitu kinahitaji kubadilika.
Wakati wa kuunda Gridi mpya ya Huduma, kwanza kabisa tulitaka kutoa dhamana ya kupelekwa kwa usawazishaji: mara tu mtumiaji aliporejesha udhibiti kutoka kwa API, angeweza kutumia huduma mara moja. Pia nilitaka kumpa mwanzilishi uwezo wa kushughulikia makosa ya upelekaji.
Kwa kuongeza, nilitaka kurahisisha utekelezaji, yaani, kuondoka kutoka kwa shughuli na kusawazisha upya. Licha ya ukweli kwamba cache inarudiwa na hakuna kusawazisha, matatizo yalitokea wakati wa kupelekwa kubwa na nodes nyingi. Wakati topolojia inabadilika, nodi zinahitaji kubadilishana habari, na kwa upelekaji mkubwa, data hii inaweza kuwa na uzito mkubwa.
Wakati topolojia haikuwa thabiti, mratibu alihitaji kukokotoa upya usambazaji wa huduma. Na kwa ujumla, wakati unapaswa kufanya kazi na shughuli kwenye topolojia isiyo imara, hii inaweza kusababisha makosa magumu-kutabiri.
Shida
Ni mabadiliko gani ya ulimwengu bila kuambatana na shida? Ya kwanza ya haya ilikuwa mabadiliko katika topolojia. Unahitaji kuelewa kwamba wakati wowote, hata wakati wa kupeleka huduma, node inaweza kuingia au kuondoka kwenye nguzo. Zaidi ya hayo, ikiwa wakati wa kupeleka node hujiunga na nguzo, itakuwa muhimu kuhamisha mara kwa mara taarifa zote kuhusu huduma kwenye node mpya. Na hatuzungumzii tu juu ya kile ambacho tayari kimetumika, lakini pia juu ya kupelekwa kwa sasa na siku zijazo.
Hii ni moja tu ya shida ambazo zinaweza kukusanywa katika orodha tofauti:
- Jinsi ya kupeleka huduma zilizosanidiwa tuli wakati wa kuanza kwa nodi?
- Kuacha nodi kutoka kwa nguzo - nini cha kufanya ikiwa huduma za mwenyeji wa nodi?
- Nini cha kufanya ikiwa mratibu amebadilika?
- Nini cha kufanya ikiwa mteja ataunganisha tena kwenye nguzo?
- Je, maombi ya kuwezesha/kuzima yanahitaji kushughulikiwa na jinsi gani?
- Je, ikiwa wangetaka uharibifu wa cache, na tuna huduma za ushirika zilizounganishwa nayo?
Na si kwamba wote.
uamuzi
Kama lengo, tulichagua mbinu inayoendeshwa na Tukio na utekelezaji wa mchakato wa mawasiliano kwa kutumia ujumbe. Ignite tayari inatekeleza vipengele viwili vinavyoruhusu nodi kusambaza ujumbe miongoni mwao - communication-spi na discovery-spi.
Mawasiliano-spi huruhusu nodi kuwasiliana moja kwa moja na kusambaza ujumbe. Inafaa kwa kutuma kiasi kikubwa cha data. Discovery-spi hukuruhusu kutuma ujumbe kwa nodi zote kwenye nguzo. Katika utekelezaji wa kawaida, hii inafanywa kwa kutumia topolojia ya pete. Pia kuna ushirikiano na Zookeeper, katika kesi hii topolojia ya nyota hutumiwa. Jambo lingine muhimu linalostahili kuzingatiwa ni kwamba uvumbuzi-spi hutoa hakikisho kwamba ujumbe utawasilishwa kwa mpangilio sahihi kwa nodi zote.
Hebu tuangalie itifaki ya kupeleka. Maombi yote ya mtumiaji ya kupelekwa na kutotumwa yanatumwa kupitia discovery-spi. Hii inatoa yafuatayo dhamana:
- Ombi litapokelewa na nodi zote kwenye nguzo. Hii itaruhusu ombi kuendelea kuchakata wakati mratibu anabadilika. Hii pia inamaanisha kuwa katika ujumbe mmoja, kila nodi itakuwa na metadata zote zinazohitajika, kama vile usanidi wa huduma na mfano wake wa mfululizo.
- Upangaji mkali wa uwasilishaji wa ujumbe husaidia kutatua mizozo ya usanidi na maombi shindani.
- Kwa kuwa kuingia kwa nodi kwenye topolojia pia kunachakatwa kupitia ugunduzi-spi, nodi mpya itapokea data zote muhimu kwa kufanya kazi na huduma.
Wakati ombi linapokelewa, nodi kwenye nguzo huithibitisha na kuunda kazi za usindikaji. Kazi hizi zimewekwa kwenye foleni na kisha kuchakatwa katika uzi mwingine na mfanyakazi tofauti. Inatekelezwa kwa njia hii kwa sababu uwekaji unaweza kuchukua muda mwingi na kuchelewesha mtiririko wa ugunduzi wa gharama kubwa bila kuvumiliwa.
Maombi yote kutoka kwa foleni yanachakatwa na msimamizi wa upelekaji. Ina mfanyakazi maalum ambaye huchota kazi kutoka kwenye foleni hii na kuianzisha ili kuanza kupelekwa. Baada ya hayo, vitendo vifuatavyo hufanyika:
- Kila nodi hukokotoa shukrani za usambazaji kwa kitendakazi kipya cha kubainisha.
- Nodes hutoa ujumbe na matokeo ya kupelekwa na kutuma kwa mratibu.
- Mratibu hujumlisha ujumbe wote na kutoa matokeo ya mchakato mzima wa utumaji, ambao hutumwa kupitia ugunduzi-spi kwa nodi zote kwenye nguzo.
- Wakati matokeo yamepokelewa, mchakato wa kupeleka unaisha, baada ya hapo kazi hiyo imeondolewa kwenye foleni.
Muundo mpya unaoendeshwa na tukio: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ikiwa hitilafu hutokea wakati wa kupelekwa, node mara moja inajumuisha kosa hili katika ujumbe ambao hutuma kwa mratibu. Baada ya kujumlisha ujumbe, mratibu atakuwa na taarifa kuhusu hitilafu zote wakati wa kusambaza na atatuma ujumbe huu kupitia discovery-spi. Maelezo ya hitilafu yatapatikana kwenye nodi yoyote kwenye nguzo.
Matukio yote muhimu katika Gridi ya Huduma yanachakatwa kwa kutumia kanuni hii ya uendeshaji. Kwa mfano, kubadilisha topolojia pia ni ujumbe kupitia ugunduzi-spi. Na kwa ujumla, ikilinganishwa na kile kilichokuwa hapo awali, itifaki iligeuka kuwa nyepesi na ya kuaminika. Inatosha kushughulikia hali yoyote wakati wa kupelekwa.
Ni nini kitatokea baadaye
Sasa kuhusu mipango. Mabadiliko yoyote makubwa kwa mradi wa Ignite yanakamilika kama mpango wa kuboresha Ignite, unaoitwa IEP. Usanifu upya wa Gridi ya Huduma pia ina IEP - yenye kichwa cha dhihaka "Mabadiliko ya mafuta kwenye Gridi ya Huduma". Lakini kwa kweli, hatukubadilisha mafuta ya injini, lakini injini nzima.
Tuligawanya kazi katika IEP katika awamu 2. Ya kwanza ni awamu kuu, ambayo inajumuisha upya itifaki ya kupeleka. Tayari imejumuishwa katika bwana, unaweza kujaribu Gridi mpya ya Huduma, ambayo itaonekana katika toleo la 2.8. Awamu ya pili inajumuisha kazi zingine nyingi:
- Kuweka upya moto
- Utoaji wa huduma
- Kuongezeka kwa uvumilivu wa makosa
- Mteja mwembamba
- Zana za ufuatiliaji na kuhesabu vipimo mbalimbali
Hatimaye, tunaweza kukushauri kwenye Gridi ya Huduma kwa ajili ya kujenga mifumo inayostahimili hitilafu na yenye upatikanaji wa hali ya juu. Pia tunakualika ututembelee kwenye ΠΈ shiriki uzoefu wako. Uzoefu wako ni muhimu sana kwa jumuiya; itakusaidia kuelewa ni wapi pa kuhamia, jinsi ya kuunda kipengele katika siku zijazo.
Chanzo: mapenzi.com