La 26-an de februaro, ni okazigis renkontiĝon Apache Ignite GreenSource, kie kontribuantoj al la malfermfonta projekto parolis . Grava okazaĵo en la vivo de tiu komunumo estis la restrukturado de la komponento , kiu permesas vin disfaldi kutimajn mikroservojn rekte en Ignite-areton. Li parolis pri ĉi tiu malfacila procezo ĉe la renkontiĝo , softvarinĝeniero kaj Apache Ignite kontribuanto dum pli ol du jaroj.
Ni komencu per kio estas Apache Ignite ĝenerale. Ĉi tio estas datumbazo kiu estas distribuita Ŝlosilo/Valo-stokado kun subteno por SQL, transakco kaj kaŝmemoro. Krome, Ignite permesas vin disfaldi kutimajn servojn rekte en Ignite-areton. La programisto havas aliron al ĉiuj iloj kiujn Ignite provizas - distribuitaj datumstrukturoj, Mesaĝado, Streaming, Komputado kaj Datuma Reto. Ekzemple, uzante Data Grid, la problemo de administrado de aparta infrastrukturo por datumstokado kaj, kiel sekvo, la rezultaj superkostoj malaperas.
Uzante la Service Grid API, vi povas disfaldi servon simple specifante la deplojan skemon kaj, sekve, la servon mem en la agordo.
Tipe, deplojskemo estas indiko de la nombro da kazoj kiuj devus esti deplojitaj sur aretnodoj. Estas du tipaj deplojkabaloj. La unua estas Cluster Singleton: en iu ajn momento, unu okazo de uzantservo estas garantiita esti disponebla en la areto. La dua estas Node Singleton: unu kazo de la servo estas deplojita sur ĉiu clusternodo.
La uzanto ankaŭ povas specifi la nombron da servokazoj en la tuta areto kaj difini predikaton por filtrado de taŭgaj nodoj. En ĉi tiu scenaro, Service Grid mem kalkulos la optimuman distribuon por disfaldi servojn.
Krome, ekzistas tia funkcio kiel Affinity Service. Afineco estas funkcio kiu difinas la rilaton de ŝlosiloj al sekcioj kaj la rilaton de partioj al nodoj en la topologio. Uzante la ŝlosilon, vi povas determini la primaran nodon, sur kiu la datumoj estas konservitaj. Tiel vi povas asocii vian propran servon kun ŝlosila kaj afinca funkcio kaŝmemoro. Se la afinecfunkcio ŝanĝiĝas, aŭtomata redeplojo okazos. Tiel, la servo ĉiam troviĝos proksime al la datumoj, kiujn ĝi bezonas por manipuli, kaj, sekve, reduktos la superan aliron de informoj. Ĉi tiu skemo povas esti nomita speco de samlokita komputado.
Nun kiam ni eksciis, kio estas la beleco de Service Grid, ni parolu pri ĝia evoluhistorio.
Kio okazis antaŭe
La antaŭa efektivigo de Service Grid estis bazita sur la transakcia reproduktita sistemkaŝmemoro de Ignite. La vorto "kaŝmemoro" en Ignite rilatas al stokado. Tio estas, ĉi tio ne estas io provizora, kiel vi povus pensi. Malgraŭ la fakto ke la kaŝmemoro estas reproduktita kaj ĉiu nodo enhavas la tutan datuman aron, ene de la kaŝmemoro ĝi havas dividitan reprezentadon. Ĉi tio estas pro konservada optimumigo.
Kio okazis kiam la uzanto volis deploji la servon?
- Ĉiuj nodoj en la areto abonis ĝisdatigi datumojn en la stokado uzante la enkonstruitan Kontinuan Demandan mekanismon.
- La komencanta nodo, sub leg-engaĝita transakcio, faris rekordon en la datumbazo kiu enhavis la servan agordon, inkluzive de la seriigita kazo.
- Kiam sciigita pri nova eniro, la kunordiganto kalkulis la distribuon surbaze de la agordo. La rezulta objekto estis skribita reen al la datumbazo.
- Se nodo estis parto de la distribuo, la kunordiganto devis deploji ĝin.
Kio ne konvenis al ni
Iam ni alvenis al la konkludo: ĉi tio ne estas la maniero labori kun servoj. Estis pluraj kialoj.
Se iu eraro okazis dum deplojo, tiam ĝi nur povus esti trovita el la protokoloj de la nodo, kie ĉio okazis. Ekzistis nur nesinkrona deplojo, do post redonado de kontrolo al la uzanto de la deplojmetodo, estis necesa iom da plia tempo por komenci la servon - kaj dum tiu ĉi tempo la uzanto povis nenion kontroli. Por disvolvi la Servan Reton plu, krei novajn funkciojn, altiri novajn uzantojn kaj faciligi la vivon de ĉiuj, io devas ŝanĝi.
Dum la dezajno de la nova Servo-Krado, ni antaŭ ĉio volis provizi garantion de sinkrona disvastigo: tuj kiam la uzanto resendis kontrolon de la API, li tuj povis uzi la servojn. Mi ankaŭ volis doni al la iniciatinto la kapablon pritrakti deplojajn erarojn.
Krome, mi volis simpligi la efektivigon, nome, foriri de transakcioj kaj rebalancado. Malgraŭ tio, ke la kaŝmemoro estas reproduktita kaj ne ekzistas ekvilibro, problemoj ekestis dum granda deplojo kun multaj nodoj. Kiam la topologio ŝanĝiĝas, nodoj bezonas interŝanĝi informojn, kaj kun granda disfaldo, ĉi tiuj datumoj povas multe pezi.
Kiam la topologio estis malstabila, la kunordiganto devis rekalkuli la distribuadon de servoj. Kaj ĝenerale, kiam vi devas labori kun transakcioj sur malstabila topologio, ĉi tio povas konduki al malfacilaj antaŭdiri erarojn.
Problemoj
Kio estas tutmondaj ŝanĝoj sen akompanaj problemoj? La unua el tiuj estis ŝanĝo en topologio. Vi devas kompreni, ke ĉiumomente, eĉ en la momento de servo-deplojo, nodo povas eniri aŭ forlasi la areton. Krome, se en la momento de deplojo la nodo aliĝas al la areto, estos necese konsekvence transdoni ĉiujn informojn pri la servoj al la nova nodo. Kaj ni parolas ne nur pri tio, kio jam estis deplojita, sed ankaŭ pri nunaj kaj estontaj deplojoj.
Ĉi tio estas nur unu el la problemoj, kiuj povas esti kolektitaj en aparta listo:
- Kiel disfaldi statike agorditajn servojn ĉe noda ekfunkciigo?
- Forlasi nodon el la areto - kion fari se la nodo gastigis servojn?
- Kion fari se la kunordiganto ŝanĝiĝis?
- Kion fari se la kliento rekonektas al la areto?
- Ĉu aktivigaj/malaktivigaj petoj devas esti procesitaj kaj kiel?
- Kio se ili postulus detruon de kaŝmemoro, kaj ni havas afinecajn servojn ligitajn al ĝi?
Kaj tio ne estas ĉio.
decido
Kiel celon, ni elektis la Event Driven aliron kun la efektivigo de proceza komunikado uzante mesaĝojn. Ignite jam efektivigas du komponantojn, kiuj permesas al nodoj plusendi mesaĝojn inter si - komunikado-spi kaj discovery-spi.
Communication-spi permesas al nodoj rekte komuniki kaj plusendi mesaĝojn. Ĝi taŭgas por sendi grandajn kvantojn da datumoj. Discovery-spi permesas sendi mesaĝon al ĉiuj nodoj en la areto. En la norma efektivigo, tio estas farita uzante ringan topologion. Ekzistas ankaŭ integriĝo kun Zookeeper, ĉi-kaze steltopologio estas uzata. Alia grava punkto atentinda estas, ke discovery-spi provizas garantiojn, ke la mesaĝo certe estos liverita en la ĝusta ordo al ĉiuj nodoj.
Ni rigardu la deplojan protokolon. Ĉiuj uzantpetoj por deplojo kaj maldeplojo estas senditaj per discovery-spi. Ĉi tio donas la jenon garantioj:
- La peto ricevos ĉiuj nodoj en la areto. Ĉi tio permesos al la peto daŭrigi la prilaboradon kiam la kunordiganto ŝanĝiĝas. Ĉi tio ankaŭ signifas, ke en unu mesaĝo, ĉiu nodo havos ĉiujn necesajn metadatenojn, kiel la servo-konfiguracio kaj ĝia seriigita kazo.
- Strikta mendo de mesaĝa livero helpas solvi agordajn konfliktojn kaj konkurantajn petojn.
- Ĉar la eniro de la nodo en la topologion ankaŭ estas procesita per discovery-spi, la nova nodo ricevos ĉiujn datumojn necesajn por labori kun servoj.
Kiam peto estas ricevita, nodoj en la areto validas ĝin kaj kreas pretigajn taskojn. Tiuj taskoj estas vicigitaj kaj tiam prilaboritaj en alia fadeno fare de aparta laboristo. Ĝi estas efektivigita tiel ĉar deplojo povas preni signifan kvanton de tempo kaj prokrasti la multekostan eltrovaĵfluon netolerebla.
Ĉiuj petoj de la atendovico estas prilaboritaj de la deplojadministranto. Ĝi havas specialan laboriston kiu tiras taskon de ĉi tiu atendovico kaj pravalorigas ĝin por komenci deplojon. Post tio okazas la jenaj agoj:
- Ĉiu nodo sendepende kalkulas la distribuon danke al nova determinisma atribua funkcio.
- Nodoj generas mesaĝon kun la rezultoj de la deplojo kaj sendas ĝin al la kunordiganto.
- La kunordiganto agregas ĉiujn mesaĝojn kaj generas la rezulton de la tuta deplojprocezo, kiu estas sendita per malkovro-spi al ĉiuj nodoj en la areto.
- Kiam la rezulto estas ricevita, la deplojprocezo finiĝas, post kiu la tasko estas forigita de la atendovico.
Nova okazaĵa dezajno: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Se eraro okazas dum deplojo, la nodo tuj inkluzivas ĉi tiun eraron en mesaĝo, kiun ĝi sendas al la kunordiganto. Post mesaĝo-agregado, la kunordiganto havos informojn pri ĉiuj eraroj dum deplojo kaj sendos ĉi tiun mesaĝon per discovery-spi. Informoj pri eraroj estos disponeblaj sur iu ajn nodo en la areto.
Ĉiuj gravaj eventoj en la Servo-Krado estas procesitaj per ĉi tiu funkcianta algoritmo. Ekzemple, ŝanĝi la topologion ankaŭ estas mesaĝo per discovery-spi. Kaj ĝenerale, kompare kun tio, kio estis antaŭe, la protokolo montriĝis sufiĉe malpeza kaj fidinda. Sufiĉe por trakti ajnan situacion dum deplojo.
Kio okazos poste
Nun pri la planoj. Ĉiu grava ŝanĝo al la Ignite-projekto estas kompletigita kiel Ignite-pliboniginiciato, nomita IEP. La Restrukturado de Servo-Krado ankaŭ havas IEP - kun la moka titolo "Oleoŝanĝo en la Serva Reto". Sed fakte, ni ne ŝanĝis la motoroleon, sed la tutan motoron.
Ni dividis la taskojn en la IEP en 2 fazojn. La unua estas grava fazo, kiu konsistas el reverkado de la disfalda protokolo. Ĝi jam estas inkluzivita en la majstro, vi povas provi la novan Servan Reton, kiu aperos en versio 2.8. La dua fazo inkluzivas multajn aliajn taskojn:
- Varma redeplojo
- Servoversiado
- Pliigita faŭltoleremo
- Maldika kliento
- Iloj por monitori kaj kalkuli diversajn metrikojn
Fine, ni povas konsili vin pri Servo-Krado por konstrui mistolerajn, alt-haveblajn sistemojn. Ni ankaŭ invitas vin viziti nin ĉe и kundividu vian sperton. Via sperto estas vere grava por la komunumo; ĝi helpos vin kompreni kien moviĝi poste, kiel evoluigi la komponanton en la estonteco.
fonto: www.habr.com