26. februara održali smo sastanak Apache Ignite GreenSource, na kojem su govorili saradnici projekta otvorenog koda . Važan događaj u životu ove zajednice bilo je restrukturiranje komponente , koji vam omogućava da implementirate prilagođene mikroservise direktno u Ignite klaster. On je na sastanku govorio o ovom teškom procesu , softverski inženjer i Apache Ignite saradnik više od dvije godine.
Počnimo od toga šta je Apache Ignite uopšte. Ovo je baza podataka koja je distribuirana pohrana ključeva/vrijednosti s podrškom za SQL, transakcije i keširanje. Osim toga, Ignite vam omogućava da implementirate prilagođene usluge direktno u Ignite klaster. Programer ima pristup svim alatima koje Ignite pruža - distribuiranim strukturama podataka, razmjeni poruka, strimingu, računanju i mreži podataka. Na primjer, kada se koristi Data Grid, problem administriranja zasebne infrastrukture za pohranu podataka i, kao posljedica toga, rezultujući režijski troškovi nestaju.
Koristeći Service Grid API, možete implementirati uslugu jednostavnim navođenjem šeme implementacije i, shodno tome, samu uslugu u konfiguraciji.
Tipično, shema implementacije je indikacija broja instanci koje bi trebale biti raspoređene na čvorovima klastera. Postoje dvije tipične sheme implementacije. Prvi je Cluster Singleton: u svakom trenutku, jedna instanca korisničkog servisa je zagarantovano dostupna u klasteru. Drugi je Node Singleton: jedna instanca usluge je raspoređena na svakom čvoru klastera.
Korisnik također može odrediti broj instanci usluge u cijelom klasteru i definirati predikat za filtriranje odgovarajućih čvorova. U ovom scenariju, servisna mreža će sama izračunati optimalnu distribuciju za implementaciju usluga.
Osim toga, postoji takva značajka kao što je Affinity Service. Afinitet je funkcija koja definira odnos ključeva prema particijama i odnos strana prema čvorovima u topologiji. Koristeći ključ, možete odrediti primarni čvor na kojem su podaci pohranjeni. Na ovaj način možete povezati svoju vlastitu uslugu s kešom ključeva i funkcija afiniteta. Ako se funkcija afiniteta promijeni, doći će do automatskog ponovnog rasporeda. Na ovaj način, usluga će uvijek biti locirana u blizini podataka s kojima treba manipulirati i, shodno tome, smanjiti troškove pristupa informacijama. Ova šema se može nazvati nekom vrstom kolociranog računarstva.
Sada kada smo shvatili u čemu je ljepota Service Grid-a, hajde da pričamo o istoriji njegovog razvoja.
Šta se desilo ranije
Prethodna implementacija Service Grid bila je zasnovana na Ignite-ovom transakcionom repliciranom sistemskom kešu. Riječ "cache" u Ignite-u se odnosi na skladištenje. Odnosno, ovo nije nešto privremeno, kao što mislite. Uprkos činjenici da je keš repliciran i svaki čvor sadrži cijeli skup podataka, unutar keša ima particioniranu reprezentaciju. To je zbog optimizacije skladištenja.
Šta se dogodilo kada je korisnik htio implementirati uslugu?
- Svi čvorovi u klasteru su se pretplatili na ažuriranje podataka u skladištu koristeći ugrađeni mehanizam kontinuiranog upita.
- Inicijalni čvor, pod transakcijom koja je učitana, napravio je zapis u bazi podataka koji je sadržavao konfiguraciju usluge, uključujući serijaliziranu instancu.
- Kada je obaviješten o novom unosu, koordinator je izračunao distribuciju na osnovu konfiguracije. Rezultirajući objekt je zapisan natrag u bazu podataka.
- Ako je čvor bio dio distribucije, koordinator ga je morao rasporediti.
Šta nam nije odgovaralo
U jednom trenutku smo došli do zaključka: ovo nije način rada sa servisima. Bilo je nekoliko razloga.
Ako je došlo do greške tokom implementacije, onda se to moglo saznati samo iz logova čvora gdje se sve dogodilo. Postojala je samo asinhrona implementacija, tako da je nakon vraćanja kontrole korisniku iz metode implementacije bilo potrebno neko dodatno vrijeme za pokretanje usluge - i za to vrijeme korisnik nije mogao ništa kontrolirati. Da bismo dalje razvijali Servisnu mrežu, kreirali nove funkcije, privukli nove korisnike i svima olakšali život, potrebno je nešto promijeniti.
Prilikom dizajniranja novog Service Grid-a, prije svega smo željeli osigurati garanciju sinkrone implementacije: čim korisnik vrati kontrolu iz API-ja, on je odmah mogao koristiti usluge. Također sam htio dati inicijatoru mogućnost rješavanja grešaka pri postavljanju.
Osim toga, želio sam pojednostaviti implementaciju, odnosno pobjeći od transakcija i rebalansa. Uprkos činjenici da se keš memorija replicira i da nema balansiranja, problemi su nastali tokom velike implementacije sa mnogo čvorova. Kada se topologija promijeni, čvorovi moraju razmjenjivati informacije, a uz veliku primjenu, ovi podaci mogu imati veliku težinu.
Kada je topologija bila nestabilna, koordinator je trebao ponovo izračunati distribuciju usluga. I općenito, kada morate raditi s transakcijama na nestabilnoj topologiji, to može dovesti do teško predvidljivih grešaka.
Problemi
Šta su to globalne promjene bez pratećih problema? Prva od njih bila je promjena topologije. Morate shvatiti da u svakom trenutku, čak iu trenutku postavljanja usluge, čvor može ući ili napustiti klaster. Štaviše, ako se u vrijeme implementacije čvor pridruži klasteru, bit će potrebno dosljedno prenositi sve informacije o uslugama na novi čvor. I ne govorimo samo o onome što je već raspoređeno, već i o sadašnjim i budućim raspoređivanjima.
Ovo je samo jedan od problema koji se mogu sakupiti u posebnu listu:
- Kako implementirati statički konfigurirane usluge pri pokretanju čvora?
- Napuštanje čvora iz klastera - šta učiniti ako je čvor hostirao usluge?
- Šta učiniti ako se promijenio koordinator?
- Šta učiniti ako se klijent ponovo poveže na klaster?
- Da li je potrebno obraditi zahtjeve za aktivaciju/deaktivaciju i kako?
- Šta ako su pozvali na uništavanje keša, a mi imamo usluge afiniteta vezane za to?
I to nije sve.
odluka
Kao cilj smo odabrali Event Driven pristup sa implementacijom procesne komunikacije putem poruka. Ignite već implementira dvije komponente koje omogućavaju čvorovima da prosljeđuju poruke između sebe - communication-spi i discovery-spi.
Communication-spi omogućava čvorovima da komuniciraju direktno i prosleđuju poruke. Pogodan je za slanje velikih količina podataka. Discovery-spi vam omogućava da pošaljete poruku svim čvorovima u klasteru. U standardnoj implementaciji, to se radi pomoću topologije prstena. Postoji i integracija sa Zookeeper-om, u ovom slučaju se koristi topologija zvijezde. Još jedna važna stvar koju vrijedi napomenuti je da discovery-spi daje garancije da će poruka definitivno biti isporučena u ispravnom redoslijedu svim čvorovima.
Pogledajmo protokol implementacije. Svi korisnički zahtjevi za implementaciju i poništavanje se šalju putem discovery-spi. Ovo daje sljedeće garancija:
- Zahtjev će primiti svi čvorovi u klasteru. Ovo će omogućiti nastavak obrade zahtjeva kada se promijeni koordinator. To također znači da će u jednoj poruci svaki čvor imati sve potrebne metapodatke, kao što su konfiguracija usluge i njena serijalizirana instanca.
- Strogo redoslijed isporuke poruka pomaže u rješavanju konfiguracijskih sukoba i konkurentskih zahtjeva.
- Budući da se ulazak čvora u topologiju također obrađuje preko discovery-spi, novi čvor će dobiti sve podatke potrebne za rad sa servisima.
Kada se primi zahtjev, čvorovi u klasteru ga provjeravaju i kreiraju zadatke obrade. Ovi zadaci se stavljaju u red čekanja i zatim obrađuju u drugoj niti od strane zasebnog radnika. Implementira se na ovaj način jer implementacija može potrajati značajno vrijeme i nepodnošljivo odgoditi skupi tok otkrivanja.
Sve zahtjeve iz reda obrađuje upravitelj implementacije. Ima posebnog radnika koji izvlači zadatak iz ovog reda čekanja i inicijalizira ga za početak implementacije. Nakon toga se dešavaju sljedeće radnje:
- Svaki čvor samostalno izračunava distribuciju zahvaljujući novoj determinističkoj funkciji dodjele.
- Čvorovi generiraju poruku s rezultatima implementacije i šalju je koordinatoru.
- Koordinator agregira sve poruke i generira rezultat cijelog procesa implementacije, koji se šalje preko discovery-spi svim čvorovima u klasteru.
- Kada se dobije rezultat, proces implementacije se završava, nakon čega se zadatak uklanja iz reda čekanja.
Novi dizajn vođen događajima: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ako dođe do greške tokom postavljanja, čvor odmah uključuje ovu grešku u poruku koju šalje koordinatoru. Nakon agregacije poruka, koordinator će imati informacije o svim greškama tokom implementacije i poslat će ovu poruku putem discovery-spi. Informacije o grešci će biti dostupne na bilo kojem čvoru u klasteru.
Svi važni događaji u Servisnoj mreži obrađuju se ovim operativnim algoritmom. Na primjer, promjena topologije je također poruka putem discovery-spi. I općenito, u poređenju s onim što je bilo prije, protokol se pokazao prilično laganim i pouzdanim. Dovoljno da se nosi sa bilo kojom situacijom tokom raspoređivanja.
Šta će se sljedeće dogoditi
Sada o planovima. Svaka veća promjena u projektu Ignite je završena kao inicijativa za poboljšanje Ignite, nazvana IEP. Redizajn servisne mreže takođe ima IEP - sa podrugljivim naslovom “Promjena ulja u servisnoj mreži”. Ali u stvari, nismo mijenjali motorno ulje, već cijeli motor.
Zadatke u IEP-u podijelili smo u 2 faze. Prva je velika faza, koja se sastoji od prerade protokola implementacije. Već je uključen u master, možete isprobati novu Service Grid, koja će se pojaviti u verziji 2.8. Druga faza uključuje mnoge druge zadatke:
- Vruće ponovno raspoređivanje
- Verzija servisa
- Povećana tolerancija grešaka
- Tanak klijent
- Alati za praćenje i izračunavanje različitih metrika
Konačno, možemo vas savjetovati u vezi sa servisnom mrežom za izgradnju sistema visoke dostupnosti otpornih na greške. Također vas pozivamo da nas posjetite na и podijelite svoje iskustvo. Vaše iskustvo je zaista važno za zajednicu; pomoći će vam da shvatite kuda dalje, kako razvijati komponentu u budućnosti.
izvor: www.habr.com