26. veljače održali smo sastanak Apache Ignite GreenSource na kojem su govorili suradnici projekta otvorenog koda . Važan događaj u životu ove zajednice bilo je restrukturiranje komponente , koji vam omogućuje implementaciju prilagođenih mikroservisa izravno u Ignite klaster. O ovom teškom procesu govorio je na skupu , softverski inženjer i suradnik Apache Ignitea više od dvije godine.
Počnimo s time što je Apache Ignite općenito. Ovo je baza podataka koja je distribuirana pohrana ključeva/vrijednosti s podrškom za SQL, transakcijsku sposobnost i predmemoriju. Osim toga, Ignite vam omogućuje implementaciju prilagođenih usluga izravno u Ignite klaster. Programer ima pristup svim alatima koje Ignite pruža - distribuiranim podatkovnim strukturama, slanju poruka, strujanju, računanju i podatkovnoj mreži. Na primjer, pri korištenju Data Grid-a nestaje problem administriranja zasebne infrastrukture za pohranu podataka i, kao posljedica toga, posljedični režijski troškovi.
Pomoću Service Grid API-ja možete implementirati uslugu jednostavnim navođenjem sheme implementacije i, sukladno tome, same usluge u konfiguraciji.
Obično je shema postavljanja indikacija broja instanci koje bi se trebale rasporediti na čvorovima klastera. Postoje dvije tipične sheme postavljanja. Prvi je Cluster Singleton: u bilo kojem trenutku zajamčeno je da će jedna instanca korisničke usluge biti 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, Service Grid će sam 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. Pomoću ključa možete odrediti primarni čvor na kojem su podaci pohranjeni. Na taj način možete povezati vlastitu uslugu s predmemorijom ključa i funkcije afiniteta. Ako se funkcija afiniteta promijeni, doći će do automatske preraspodjele. Na taj način servis će uvijek biti lociran u blizini podataka kojima treba manipulirati, a time i smanjiti troškove pristupa informacijama. Ova se shema može nazvati nekom vrstom kolociranog računalstva.
Sada kada smo shvatili u čemu je ljepota Service Grid-a, razgovarajmo o njegovoj povijesti razvoja.
Što se dogodilo prije
Prethodna implementacija Service Grid-a temeljila se na Ignite-ovoj transakcijskoj repliciranoj sistemskoj predmemorije. Riječ "cache" u Igniteu odnosi se na pohranu. Odnosno, ovo nije nešto privremeno, kao što mislite. Unatoč činjenici da je predmemorija replicirana i da svaki čvor sadrži cijeli skup podataka, unutar predmemorije ima particionirani prikaz. To je zbog optimizacije pohrane.
Što se dogodilo kada je korisnik želio implementirati uslugu?
- Svi čvorovi u klasteru pretplaćeni su na ažuriranje podataka u pohrani koristeći ugrađeni mehanizam kontinuiranog upita.
- Početni čvor, pod transakcijom predanom čitanjem, napravio je zapis u bazi podataka koji je sadržavao konfiguraciju usluge, uključujući serijaliziranu instancu.
- Kada je dobio obavijest o novom unosu, koordinator je izračunao distribuciju na temelju konfiguracije. Rezultirajući objekt zapisan je natrag u bazu podataka.
- Ako je čvor bio dio distribucije, koordinator ga je morao postaviti.
Što nam nije odgovaralo
U jednom smo trenutku došli do zaključka: tako se ne radi s uslugama. Bilo je nekoliko razloga.
Ako se dogodi neka greška tijekom implementacije, tada se to može saznati samo iz logova čvora na kojem se sve dogodilo. Postojala je samo asinkrona implementacija, pa je nakon vraćanja kontrole korisniku iz metode implementacije bilo potrebno dodatno vrijeme za pokretanje usluge - a za to vrijeme korisnik nije mogao ništa kontrolirati. Kako bi se Service Grid dalje razvijao, stvarale nove značajke, privukle nove korisnike i svima olakšale život, potrebno je nešto promijeniti.
Prilikom dizajniranja novog Service Grid-a prije svega smo željeli osigurati jamstvo sinkrone implementacije: čim korisnik vrati kontrolu s API-ja, odmah je mogao koristiti usluge. Također sam želio dati inicijatoru mogućnost da se nosi s pogreškama implementacije.
Osim toga, želio sam pojednostaviti implementaciju, naime, pobjeći od transakcija i rebalansiranja. Unatoč činjenici da je predmemorija replicirana i nema balansiranja, problemi su se pojavili tijekom velike implementacije s mnogo čvorova. Kada se topologija promijeni, čvorovi trebaju razmjenjivati informacije, a uz veliku implementaciju, ti podaci mogu puno težiti.
Kada je topologija bila nestabilna, koordinator je trebao ponovno izračunati distribuciju usluga. I općenito, kada morate raditi s transakcijama na nestabilnoj topologiji, to može dovesti do teško predvidljivih pogrešaka.
Problemi
Što su globalne promjene bez popratnih problema? Prva od njih bila je promjena topologije. Morate razumjeti da u bilo kojem trenutku, čak iu trenutku implementacije usluge, čvor može ući ili izaći iz klastera. Štoviše, ako se u trenutku postavljanja č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ć io sadašnjim i budućim implementacijama.
Ovo je samo jedan od problema koji se mogu sakupiti u zasebnom popisu:
- Kako implementirati statički konfigurirane usluge pri pokretanju čvora?
- Napuštanje čvora iz klastera - što učiniti ako je čvor hostirao usluge?
- Što učiniti ako se promijenio koordinator?
- Što učiniti ako se klijent ponovno spoji na klaster?
- Treba li zahtjeve za aktivaciju/deaktivaciju obrađivati i kako?
- Što ako su pozvali na uništavanje predmemorije, a mi imamo usluge afiniteta povezane s tim?
I to nije sve.
odluka
Kao cilj odabrali smo Event Driven pristup s implementacijom procesne komunikacije putem poruka. Ignite već implementira dvije komponente koje dopuštaju čvorovima da međusobno prosljeđuju poruke - komunikacijski-spi i otkriće-spi.
Communication-spi omogućuje čvorovima izravnu komunikaciju i prosljeđivanje poruka. Pogodan je za slanje velikih količina podataka. Discovery-spi vam omogućuje slanje poruke svim čvorovima u klasteru. U standardnoj implementaciji, to se radi pomoću topologije prstena. Postoji i integracija sa Zookeeperom, u ovom slučaju koristi se zvjezdasta topologija. Još jedna važna točka koju vrijedi napomenuti jest da Discovery-spi jamči da će poruka sigurno biti isporučena u ispravnom redoslijedu svim čvorovima.
Pogledajmo protokol postavljanja. Svi korisnički zahtjevi za implementaciju i deployment šalju se putem Discovery-spi. Ovo daje sljedeće jamstva:
- Zahtjev će primiti svi čvorovi u klasteru. To ć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 je konfiguracija usluge i njena serijalizirana instanca.
- Strogi redoslijed isporuke poruka pomaže u rješavanju sukoba konfiguracije i konkurentskih zahtjeva.
- Budući da se ulazak čvora u topologiju također obrađuje putem discovery-spi, novi čvor će dobiti sve podatke potrebne za rad sa servisima.
Kada se primi zahtjev, čvorovi u klasteru provjeravaju ga i stvaraju zadatke obrade. Ovi se zadaci stavljaju u red čekanja, a zatim ih u drugoj niti obrađuje zasebni radnik. Implementiran je na ovaj način jer implementacija može potrajati značajno vrijeme i nedopustivo odgoditi skupi tijek otkrivanja.
Sve zahtjeve iz reda čekanja obrađuje upravitelj implementacije. Ima posebnog radnika koji povlači zadatak iz ovog reda čekanja i inicijalizira ga za početak implementacije. Nakon toga se događaju sljedeće radnje:
- Svaki čvor samostalno izračunava distribuciju zahvaljujući novoj determinističkoj funkciji dodjele.
- Čvorovi generiraju poruku s rezultatima postavljanja i šalju je koordinatoru.
- Koordinator agregira sve poruke i generira rezultat cijelog procesa implementacije, koji se šalje putem Discovery-spi svim čvorovima u klasteru.
- Kada se primi rezultat, proces postavljanja 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 pogreške tijekom postavljanja, čvor odmah uključuje tu pogrešku u poruku koju šalje koordinatoru. Nakon agregacije poruka, koordinator će imati informacije o svim pogreškama tijekom implementacije i poslat će ovu poruku putem Discovery-spi. Informacije o pogrešci bit će dostupne na bilo kojem čvoru u klasteru.
Svi važni događaji u Service Grid-u obrađuju se ovim algoritmom rada. Na primjer, promjena topologije također je poruka putem Discovery-spi. I općenito, u usporedbi s onim što je bilo prije, protokol se pokazao prilično laganim i pouzdanim. Dovoljno za rješavanje bilo koje situacije tijekom postavljanja.
Što će biti dalje
Sada o planovima. Svaka velika promjena projekta Ignite dovršena je kao inicijativa za poboljšanje Ignitea, koja se naziva IEP. Redizajn Service Grid također ima IEP - s podrugljivim naslovom “Izmjena ulja u servisnoj rešetki”. Ali zapravo nismo mijenjali motorno ulje, nego cijeli motor.
Zadaće u IOP-u podijelili smo u 2 faze. Prva je glavna faza, koja se sastoji od prerade protokola implementacije. Već je uključen u master, možete isprobati novi Service Grid, koji će se pojaviti u verziji 2.8. Druga faza uključuje mnoge druge zadatke:
- Vruće ponovno raspoređivanje
- Verzija usluge
- Povećana tolerancija grešaka
- Tanak klijent
- Alati za praćenje i izračunavanje raznih metrika
Konačno, možemo vas savjetovati o servisnoj mreži za izgradnju sustava visoke dostupnosti otpornih na pogreške. Također Vas pozivamo da nas posjetite na и podijeli svoje iskustvo. Vaše iskustvo je stvarno važno za zajednicu; pomoći će vam da shvatite kamo ići dalje, kako razvijati komponentu u budućnosti.
Izvor: www.habr.com