26. februarja smo izvedli srečanje Apache Ignite GreenSource, na katerem so govorili sodelavci odprtokodnega projekta . Pomemben dogodek v življenju te skupnosti je bilo prestrukturiranje komponente , ki vam omogoča uvajanje mikrostoritev po meri neposredno v gručo Ignite. O tem težkem procesu je spregovoril na srečanju , programski inženir in sodelavec Apache Ignite že več kot dve leti.
Začnimo s tem, kaj je Apache Ignite na splošno. To je zbirka podatkov, ki je porazdeljena shramba ključev/vrednosti s podporo za SQL, transakcije in predpomnjenje. Poleg tega vam Ignite omogoča uvajanje storitev po meri neposredno v gručo Ignite. Razvijalec ima dostop do vseh orodij, ki jih ponuja Ignite – porazdeljene podatkovne strukture, sporočanje, pretakanje, računanje in podatkovna mreža. Na primer, pri uporabi Data Grid odpade problem upravljanja ločene infrastrukture za shranjevanje podatkov in posledično posledično režijski stroški.
Z API-jem Service Grid lahko uvedete storitev tako, da preprosto določite shemo uvedbe in s tem tudi samo storitev v konfiguraciji.
Običajno je shema razmestitve pokazatelj števila primerkov, ki jih je treba razmestiti v vozliščih gruče. Obstajata dve tipični shemi uvajanja. Prvi je Cluster Singleton: v katerem koli trenutku je zajamčeno, da je v gruči na voljo en primerek uporabniške storitve. Drugi je Node Singleton: en primerek storitve je nameščen na vsakem vozlišču gruče.
Uporabnik lahko določi tudi število instanc storitve v celotni gruči in definira predikat za filtriranje ustreznih vozlišč. V tem scenariju bo Service Grid sam izračunal optimalno porazdelitev za uvajanje storitev.
Poleg tega obstaja funkcija Affinity Service. Afiniteta je funkcija, ki definira odnos ključev do particij in odnos strank do vozlišč v topologiji. S ključem lahko določite primarno vozlišče, na katerem so shranjeni podatki. Na ta način lahko svojo lastno storitev povežete s predpomnilnikom funkcij ključa in afinitete. Če se funkcija afinitete spremeni, bo prišlo do samodejne prerazporeditve. Tako se bo storitev vedno nahajala blizu podatkov, s katerimi mora manipulirati, in s tem zmanjšala stroške dostopa do informacij. To shemo lahko imenujemo neke vrste kolokirano računalništvo.
Zdaj, ko smo ugotovili, v čem je lepota Service Grid, se pogovorimo o njegovi zgodovini razvoja.
Kaj se je zgodilo prej
Prejšnja izvedba Service Grid je temeljila na Ignitejevem transakcijskem podvojenem sistemskem predpomnilniku. Beseda "predpomnilnik" v Ignite se nanaša na shranjevanje. To pomeni, da to ni nekaj začasnega, kot bi si morda mislili. Kljub dejstvu, da je predpomnilnik podvojen in vsako vozlišče vsebuje celoten nabor podatkov, ima znotraj predpomnilnika particionirano predstavitev. To je posledica optimizacije shranjevanja.
Kaj se je zgodilo, ko je uporabnik želel uvesti storitev?
- Vsa vozlišča v gruči so naročena na posodabljanje podatkov v pomnilniku z uporabo vgrajenega mehanizma neprekinjenih poizvedb.
- Začetno vozlišče je pod transakcijo, odobreno za branje, naredilo zapis v bazi podatkov, ki je vseboval konfiguracijo storitve, vključno s serializiranim primerkom.
- Ob obvestilu o novem vnosu je koordinator izračunal porazdelitev na podlagi konfiguracije. Nastali objekt je bil zapisan nazaj v bazo podatkov.
- Če je bilo vozlišče del distribucije, ga je moral koordinator namestiti.
Kaj nam ni ustrezalo
Na neki točki smo prišli do zaključka: tako se s storitvami ne dela. Razlogov je bilo več.
Če je med uvajanjem prišlo do kakšne napake, je to mogoče ugotoviti le iz dnevnikov vozlišča, kjer se je vse zgodilo. Obstajala je le asinhrona uvedba, tako da je bilo po vrnitvi nadzora uporabniku iz metode uvajanja potrebno nekaj dodatnega časa za zagon storitve – v tem času pa uporabnik ni mogel nadzorovati ničesar. Za nadaljnji razvoj Service Grid, ustvarjanje novih funkcij, privabljanje novih uporabnikov in olajšanje življenja vseh, je treba nekaj spremeniti.
Pri snovanju novega servisnega grida smo najprej želeli zagotoviti jamstvo za sinhrono uvajanje: takoj ko uporabnik vrne nadzor iz API-ja, lahko takoj uporablja storitve. Prav tako sem želel pobudniku dati možnost, da obravnava napake pri uvajanju.
Poleg tega sem želel poenostaviti implementacijo, namreč pobegniti od transakcij in rebalansa. Kljub dejstvu, da je predpomnilnik podvojen in ni uravnoteženja, so se težave pojavile med veliko uvedbo s številnimi vozlišči. Ko se topologija spremeni, morajo vozlišča izmenjati informacije, pri veliki umestitvi pa lahko ti podatki veliko tehtajo.
Ko je bila topologija nestabilna, je moral koordinator ponovno izračunati porazdelitev storitev. In na splošno, ko morate delati s transakcijami na nestabilni topologiji, lahko to privede do težko predvidljivih napak.
Težave
Kaj so globalne spremembe brez spremljajočih težav? Prva od teh je bila sprememba topologije. Razumeti morate, da lahko vozlišče kadar koli, tudi v trenutku uvedbe storitve, vstopi v gručo ali jo zapusti. Poleg tega, če se vozlišče ob uvedbi pridruži gruči, bo treba dosledno prenašati vse informacije o storitvah v novo vozlišče. In ne govorimo samo o tem, kar je že bilo uvedeno, ampak tudi o trenutnih in prihodnjih uvajanjih.
To je le ena od težav, ki jih je mogoče zbrati na ločenem seznamu:
- Kako razmestiti statično konfigurirane storitve ob zagonu vozlišča?
- Zapuščanje vozlišča iz gruče – kaj storiti, če vozlišče gosti storitve?
- Kaj storiti, če se je koordinator zamenjal?
- Kaj storiti, če se odjemalec znova poveže z gručo?
- Ali je treba zahteve za aktivacijo/deaktivacijo obdelati in kako?
- Kaj če bi zahtevali uničenje predpomnilnika, mi pa bi imeli s tem povezane storitve afinitete?
In to še ni vse.
odločitev
Kot cilj smo izbrali Event Driven pristop z implementacijo procesne komunikacije s pomočjo sporočil. Ignite že implementira dve komponenti, ki omogočata vozliščem, da med seboj posredujejo sporočila - komunikacijski-spi in odkrivanje-spi.
Communication-spi omogoča vozliščem neposredno komunikacijo in posredovanje sporočil. Zelo je primeren za pošiljanje velikih količin podatkov. Discovery-spi vam omogoča pošiljanje sporočila vsem vozliščem v gruči. V standardni izvedbi se to izvede z uporabo topologije obroča. Obstaja tudi integracija z Zookeeperjem, v tem primeru je uporabljena zvezdasta topologija. Druga pomembna točka, ki jo je treba omeniti, je, da odkrivanje-spi zagotavlja jamstva, da bo sporočilo zagotovo dostavljeno v pravilnem vrstnem redu vsem vozliščem.
Oglejmo si protokol uvajanja. Vse uporabniške zahteve za uvedbo in neuvedbo so poslane prek Discovery-spi. To daje naslednje garancije:
- Zahtevo bodo prejela vsa vozlišča v gruči. To bo omogočilo nadaljevanje obdelave zahteve, ko se koordinator zamenja. To tudi pomeni, da bo imelo vsako vozlišče v enem sporočilu vse potrebne metapodatke, kot je konfiguracija storitve in njen serijski primerek.
- Strogo vrstni red dostave sporočil pomaga razrešiti konfiguracijske konflikte in konkurenčne zahteve.
- Ker se vstop vozlišča v topologijo obdeluje tudi preko discovery-spi, bo novo vozlišče prejelo vse potrebne podatke za delo s storitvami.
Ko prejmejo zahtevo, jo vozlišča v gruči potrdijo in ustvarijo naloge obdelave. Ta opravila so postavljena v čakalno vrsto in jih nato v drugi niti obdela ločen delavec. Izvaja se na ta način, ker lahko uvedba traja precej časa in nevzdržno odloži drag tok odkrivanja.
Vse zahteve iz čakalne vrste obdela upravitelj razmestitve. Ima posebnega delavca, ki potegne nalogo iz te čakalne vrste in jo inicializira za začetek uvajanja. Po tem se zgodijo naslednja dejanja:
- Vsako vozlišče neodvisno izračuna porazdelitev zahvaljujoč novi deterministični funkciji dodelitve.
- Vozlišča ustvarijo sporočilo z rezultati razmestitve in ga pošljejo koordinatorju.
- Koordinator združi vsa sporočila in ustvari rezultat celotnega postopka uvajanja, ki se pošlje prek Discovery-spi vsem vozliščem v gruči.
- Ko je rezultat prejet, se postopek uvajanja konča, po katerem se naloga odstrani iz čakalne vrste.
Nova zasnova, ki temelji na dogodkih: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Če med razmestitvijo pride do napake, vozlišče to napako takoj vključi v sporočilo, ki ga pošlje koordinatorju. Po združevanju sporočil bo imel koordinator informacije o vseh napakah med uvajanjem in bo to sporočilo poslal prek Discovery-spi. Informacije o napakah bodo na voljo na katerem koli vozlišču v gruči.
Vsi pomembni dogodki v Service Grid so obdelani s tem algoritmom delovanja. Na primer, sprememba topologije je tudi sporočilo prek Discovery-spi. In na splošno se je v primerjavi s prejšnjim protokol izkazal za precej lahkega in zanesljivega. Dovolj za obvladovanje kakršne koli situacije med uvajanjem.
Kaj se bo zgodilo naprej
Zdaj pa o načrtih. Vsaka večja sprememba projekta Ignite se zaključi kot pobuda za izboljšanje Ignite, imenovana IEP. Prenova Service Grid ima tudi IEP - s posmehljivim naslovom “Menjava olja v servisni rešetki”. A v resnici nismo menjali motornega olja, ampak kar cel motor.
Naloge v IEP smo razdelili v 2 fazi. Prva je glavna faza, ki vključuje predelavo protokola uvajanja. Vključen je že v master, preizkusite lahko novo Service Grid, ki se bo pojavila v različici 2.8. Druga faza vključuje številne druge naloge:
- Vroča prerazporeditev
- Verzija storitve
- Povečana toleranca napak
- Tanek odjemalec
- Orodja za spremljanje in izračun različnih metrik
Nazadnje vam lahko svetujemo o Service Grid za gradnjo sistemov z visoko razpoložljivostjo, ki so odporni na napake. Vabimo vas tudi, da nas obiščete na и delite svoje izkušnje. Vaše izkušnje so zelo pomembne za skupnost; pomagale vam bodo razumeti, kam naprej, kako razvijati komponento v prihodnosti.
Vir: www.habr.com