Op 26 Februarie het ons 'n Apache Ignite GreenSource-byeenkoms gehou, waar bydraers tot die oopbronprojek gepraat het . 'n Belangrike gebeurtenis in die lewe van hierdie gemeenskap was die herstrukturering van die komponent , wat jou toelaat om pasgemaakte mikrodienste direk in 'n Ignite-kluster te ontplooi. Hy het tydens die ontmoeting oor hierdie moeilike proses gepraat , sagteware-ingenieur en Apache Ignite-bydraer vir meer as twee jaar.
Kom ons begin met wat Apache Ignite in die algemeen is. Dit is 'n databasis wat 'n verspreide sleutel/waarde-berging is met ondersteuning vir SQL, transaksionaliteit en caching. Boonop laat Ignite jou toe om pasgemaakte dienste direk in 'n Ignite-kluster te ontplooi. Die ontwikkelaar het toegang tot al die gereedskap wat Ignite bied - verspreide datastrukture, boodskappe, stroming, bereken en datarooster. Byvoorbeeld, wanneer Data Grid gebruik word, verdwyn die probleem om 'n aparte infrastruktuur vir databerging te administreer en, as gevolg daarvan, die gevolglike oorhoofse koste.
Deur die Service Grid API te gebruik, kan u 'n diens ontplooi deur eenvoudig die ontplooiingskema en dienooreenkomstig die diens self in die konfigurasie te spesifiseer.
Tipies is 'n ontplooiingskema 'n aanduiding van die aantal gevalle wat op groepnodusse ontplooi moet word. Daar is twee tipiese ontplooiingskemas. Die eerste is Cluster Singleton: op enige gegewe tydstip is een geval van 'n gebruikersdiens gewaarborg om in die cluster beskikbaar te wees. Die tweede is Node Singleton: een geval van die diens word op elke groepknoop ontplooi.
Die gebruiker kan ook die aantal diensgevalle in die hele groepie spesifiseer en 'n predikaat definieer vir die filter van geskikte nodusse. In hierdie scenario sal Service Grid self die optimale verspreiding vir die ontplooiing van dienste bereken.
Daarbenewens is daar so 'n kenmerk soos Affinity Service. Affiniteit is 'n funksie wat die verhouding van sleutels tot partisies en die verhouding van partye tot nodusse in die topologie definieer. Deur die sleutel te gebruik, kan jy die primêre nodus bepaal waarop die data gestoor word. Op hierdie manier kan jy jou eie diens assosieer met 'n sleutel- en affiniteitfunksiekas. As die affiniteitsfunksie verander, sal outomatiese herontplooiing plaasvind. Op hierdie manier sal die diens altyd naby die data geleë wees wat dit nodig het om te manipuleer, en dienooreenkomstig die bokoste van toegang tot inligting verminder. Hierdie skema kan 'n soort saamgestelde rekenaar genoem word.
Noudat ons uitgevind het wat die skoonheid van Service Grid is, kom ons praat oor die ontwikkelingsgeskiedenis daarvan.
Wat voorheen gebeur het
Die vorige implementering van Service Grid was gebaseer op Ignite se transaksionele gerepliseerde stelselkas. Die woord "kas" in Ignite verwys na berging. Dit wil sê, dit is nie iets tydeliks, soos jy dalk dink nie. Ten spyte van die feit dat die kas gerepliseer word en elke nodus die hele datastel bevat, het dit binne die kas 'n gepartisioneerde voorstelling. Dit is as gevolg van bergingsoptimalisering.
Wat het gebeur toe die gebruiker die diens wou ontplooi?
- Alle nodusse in die groepering het ingeteken om data in die berging op te dateer met behulp van die ingeboude Deurlopende Navraag-meganisme.
- Die aanvangsnodus, onder 'n leesverbonde transaksie, het 'n rekord in die databasis gemaak wat die dienskonfigurasie bevat, insluitend die geserialiseerde instansie.
- Toe die koördineerder van 'n nuwe inskrywing in kennis gestel is, het die verspreiding op grond van die konfigurasie bereken. Die gevolglike voorwerp is teruggeskryf na die databasis.
- As 'n nodus deel van die verspreiding was, moes die koördineerder dit ontplooi.
Wat het ons nie gepas nie
Op 'n stadium het ons tot die gevolgtrekking gekom: dit is nie die manier om met dienste te werk nie. Daar was verskeie redes.
As 'n fout tydens ontplooiing voorgekom het, kon dit slegs uit die logboeke van die nodus waar alles gebeur het, gevind word. Daar was slegs asynchrone ontplooiing, so nadat beheer aan die gebruiker van die ontplooiingsmetode teruggegee is, was 'n bietjie bykomende tyd nodig om die diens te begin - en gedurende hierdie tyd kon die gebruiker niks beheer nie. Om die Diensrooster verder te ontwikkel, nuwe kenmerke te skep, nuwe gebruikers te lok en almal se lewe makliker te maak, moet iets verander.
Toe ons die nuwe diensrooster ontwerp het, wou ons eerstens 'n waarborg van sinchroniese ontplooiing verskaf: sodra die gebruiker beheer van die API teruggekeer het, kon hy dadelik die dienste gebruik. Ek wou ook die inisieerder die vermoë gee om ontplooiingsfoute te hanteer.
Daarbenewens wou ek die implementering vereenvoudig, naamlik wegkom van transaksies en herbalansering. Ten spyte van die feit dat die kas gerepliseer word en daar geen balansering is nie, het probleme ontstaan tydens 'n groot ontplooiing met baie nodusse. Wanneer die topologie verander, moet nodusse inligting uitruil, en met 'n groot ontplooiing kan hierdie data baie weeg.
Wanneer die topologie onstabiel was, moes die koördineerder die verspreiding van dienste herbereken. En in die algemeen, wanneer jy met transaksies op 'n onstabiele topologie moet werk, kan dit lei tot moeilik-voorspelbare foute.
probleme
Wat is globale veranderinge sonder gepaardgaande probleme? Die eerste hiervan was 'n verandering in topologie. U moet verstaan dat 'n nodus op enige oomblik, selfs op die oomblik van diensontplooiing, die groep kan binnegaan of verlaat. Verder, as die nodus ten tyde van ontplooiing by die groep aansluit, sal dit nodig wees om konsekwent alle inligting oor die dienste na die nuwe nodus oor te dra. En ons praat nie net oor wat reeds ontplooi is nie, maar ook oor huidige en toekomstige ontplooiings.
Dit is net een van die probleme wat in 'n aparte lys versamel kan word:
- Hoe om staties gekonfigureerde dienste te ontplooi by die opstart van die nodus?
- Om 'n nodus uit die groepering te verlaat - wat om te doen as die nodus dienste gehuisves word?
- Wat om te doen as die koördineerder verander het?
- Wat om te doen as die kliënt weer aan die groep koppel?
- Moet aktiverings-/deaktiveringsversoeke verwerk word en hoe?
- Wat as hulle gevra het vir die vernietiging van die kas, en ons het affiniteitsdienste daaraan gekoppel?
En dit is nie al nie.
besluit
As 'n teiken het ons die Gebeurtenisgedrewe benadering gekies met die implementering van proseskommunikasie deur boodskappe te gebruik. Ignite implementeer reeds twee komponente wat nodusse toelaat om boodskappe onder mekaar aan te stuur - kommunikasie-spi en ontdekking-spi.
Kommunikasie-spi laat nodusse toe om direk te kommunikeer en boodskappe aan te stuur. Dit is goed geskik vir die stuur van groot hoeveelhede data. Discovery-spi laat jou toe om 'n boodskap na alle nodusse in die groepie te stuur. In die standaardimplementering word dit gedoen met behulp van 'n ringtopologie. Daar is ook integrasie met Zookeeper, in hierdie geval word 'n stertopologie gebruik. Nog 'n belangrike punt wat die moeite werd is om op te let, is dat discovery-spi waarborge bied dat die boodskap beslis in die regte volgorde aan alle nodusse afgelewer sal word.
Kom ons kyk na die ontplooiingsprotokol. Alle gebruikerversoeke vir ontplooiing en ontplooiing word via discovery-spi gestuur. Dit gee die volgende waarborge:
- Die versoek sal deur alle nodusse in die groepering ontvang word. Dit sal die versoek toelaat om voort te gaan met verwerking wanneer die koördineerder verander. Dit beteken ook dat elke nodus in een boodskap al die nodige metadata sal hê, soos die dienskonfigurasie en sy geserialiseerde instansie.
- Streng ordening van boodskapaflewering help om konfigurasiekonflikte en mededingende versoeke op te los.
- Aangesien die nodus se toetrede tot die topologie ook via discovery-spi verwerk word, sal die nuwe nodus al die data ontvang wat nodig is om met dienste te werk.
Wanneer 'n versoek ontvang word, valideer nodusse in die groep dit en skep verwerkingstake. Hierdie take word in 'n tou geplaas en dan in 'n ander draad deur 'n aparte werker verwerk. Dit word op hierdie manier geïmplementeer omdat ontplooiing 'n aansienlike hoeveelheid tyd kan neem en die duur ontdekkingvloei ondraaglik kan vertraag.
Alle versoeke uit die tou word deur die ontplooiingsbestuurder verwerk. Dit het 'n spesiale werker wat 'n taak uit hierdie tou haal en dit inisialiseer om ontplooiing te begin. Hierna vind die volgende aksies plaas:
- Elke nodus bereken onafhanklik die verspreiding danksy 'n nuwe deterministiese toewysingsfunksie.
- Nodusse genereer 'n boodskap met die resultate van die ontplooiing en stuur dit aan die koördineerder.
- Die koördineerder versamel alle boodskappe en genereer die resultaat van die hele ontplooiingsproses, wat via discovery-spi na alle nodusse in die groep gestuur word.
- Wanneer die resultaat ontvang word, eindig die ontplooiingsproses, waarna die taak uit die tou verwyder word.
Nuwe gebeurtenisgedrewe ontwerp: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
As 'n fout tydens ontplooiing voorkom, sluit die nodus onmiddellik hierdie fout in in 'n boodskap wat dit aan die koördineerder stuur. Na boodskapsamevoeging sal die koördineerder inligting hê oor alle foute tydens ontplooiing en sal hierdie boodskap via discovery-spi stuur. Foutinligting sal beskikbaar wees op enige nodus in die groepering.
Alle belangrike gebeurtenisse in die diensrooster word verwerk deur hierdie bedryfsalgoritme te gebruik. Byvoorbeeld, die verandering van die topologie is ook 'n boodskap via discovery-spi. En in die algemeen, in vergelyking met wat voorheen was, het die protokol baie liggewig en betroubaar geblyk te wees. Genoeg om enige situasie tydens ontplooiing te hanteer.
Wat sal volgende gebeur
Nou oor die planne. Enige groot verandering aan die Ignite-projek word voltooi as 'n Ignite-verbeteringsinisiatief, 'n IEP genoem. Die Service Grid-herontwerp het ook 'n IEP - met die spottende titel “Oil change in the Service Grid”. Maar eintlik het ons nie die enjinolie verander nie, maar die hele enjin.
Ons het die take in die IEP in 2 fases verdeel. Die eerste is 'n groot fase, wat bestaan uit die herbewerking van die ontplooiingsprotokol. Dit is reeds by die meester ingesluit, u kan die nuwe Service Grid probeer, wat in weergawe 2.8 sal verskyn. Die tweede fase sluit baie ander take in:
- Warm herontplooiing
- Diensweergawe
- Verhoogde fouttoleransie
- Dun kliënt
- Gereedskap vir die monitering en berekening van verskeie metrieke
Ten slotte kan ons jou adviseer oor Service Grid vir die bou van foutverdraagsame stelsels met hoë beskikbaarheid. Ons nooi jou ook uit om ons te besoek by и deel jou ervaring. Jou ervaring is baie belangrik vir die gemeenskap; dit sal jou help om te verstaan waarheen om volgende te beweeg, hoe om die komponent in die toekoms te ontwikkel.
Bron: will.com