26. února jsme uspořádali setkání Apache Ignite GreenSource, kde hovořili přispěvatelé projektu s otevřeným zdrojovým kódem . Důležitou událostí v životě této komunity byla restrukturalizace složky , který umožňuje nasadit vlastní mikroslužby přímo do clusteru Ignite. O tomto obtížném procesu hovořil na setkání , softwarový inženýr a přispěvatel Apache Ignite více než dva roky.
Začněme tím, co je Apache Ignite obecně. Jedná se o databázi, která je distribuovaným úložištěm klíčů/hodnot s podporou SQL, transakcí a ukládáním do mezipaměti. Ignite navíc umožňuje nasadit vlastní služby přímo do clusteru Ignite. Vývojář má přístup ke všem nástrojům, které Ignite poskytuje – distribuované datové struktury, Messaging, Streaming, Compute a Data Grid. Například při použití Data Gridu odpadá problém správy oddělené infrastruktury pro ukládání dat a v důsledku toho i výsledné režijní náklady.
Pomocí Service Grid API můžete nasadit službu jednoduchým zadáním schématu nasazení a podle toho i samotné služby v konfiguraci.
Schéma nasazení obvykle označuje počet instancí, které by měly být nasazeny na uzlech clusteru. Existují dvě typická schémata nasazení. První je Cluster Singleton: v každém daném okamžiku je zaručeno, že v clusteru bude k dispozici jedna instance uživatelské služby. Druhým je Node Singleton: jedna instance služby je nasazena v každém uzlu clusteru.
Uživatel může také určit počet instancí služby v celém clusteru a definovat predikát pro filtrování vhodných uzlů. V tomto scénáři Service Grid sám vypočítá optimální distribuci pro nasazení služeb.
Kromě toho existuje funkce jako služba Affinity. Afinita je funkce, která definuje vztah klíčů k oddílům a vztah stran k uzlům v topologii. Pomocí klíče můžete určit primární uzel, na kterém jsou data uložena. Tímto způsobem můžete přidružit svou vlastní službu k mezipaměti klíčů a funkcí afinity. Pokud se funkce afinity změní, dojde k automatickému přemístění. Tímto způsobem bude služba vždy umístěna v blízkosti dat, s nimiž potřebuje manipulovat, a sníží se tak režie přístupu k informacím. Toto schéma lze nazvat jako druh collocated computingu.
Nyní, když jsme zjistili, v čem spočívá krása Service Gridu, pojďme si promluvit o historii jejího vývoje.
Co bylo předtím
Předchozí implementace Service Grid byla založena na transakční replikované systémové mezipaměti Ignite. Slovo "cache" v Ignite odkazuje na úložiště. To znamená, že to není nic dočasného, jak si možná myslíte. Navzdory skutečnosti, že mezipaměť je replikována a každý uzel obsahuje celou sadu dat, uvnitř mezipaměti má rozdělenou reprezentaci. Důvodem je optimalizace úložiště.
Co se stalo, když chtěl uživatel službu nasadit?
- Všechny uzly v clusteru se přihlásily k aktualizaci dat v úložišti pomocí vestavěného mechanismu průběžného dotazování.
- Iniciační uzel v rámci transakce s potvrzením čtení vytvořil záznam v databázi, který obsahoval konfiguraci služby, včetně serializované instance.
- Po upozornění na nový záznam vypočítal koordinátor rozdělení na základě konfigurace. Výsledný objekt byl zapsán zpět do databáze.
- Pokud byl uzel součástí distribuce, musel jej koordinátor nasadit.
Co nám nevyhovovalo
V určité chvíli jsme došli k závěru: takto se se službami nepracuje. Důvodů bylo několik.
Pokud při nasazení došlo k nějaké chybě, pak se to dalo zjistit pouze z logů uzlu, kde se vše stalo. Docházelo pouze k asynchronnímu nasazení, takže po navrácení kontroly uživateli ze způsobu nasazení byl ke spuštění služby potřeba nějaký čas navíc – a během této doby uživatel nemohl nic ovládat. Aby bylo možné Service Grid dále rozvíjet, vytvářet nové funkce, přitahovat nové uživatele a usnadňovat život všem, je třeba něco změnit.
Při návrhu nového Service Gridu jsme chtěli především poskytnout záruku synchronního nasazení: jakmile uživatel vrátil kontrolu z API, mohl služby okamžitě používat. Také jsem chtěl dát iniciátorovi schopnost zvládnout chyby nasazení.
Kromě toho jsem chtěl zjednodušit implementaci, konkrétně se zbavit transakcí a rebalancování. Navzdory tomu, že se cache replikuje a nedochází k vyvažování, při velkém nasazení s mnoha uzly nastaly problémy. Když se změní topologie, uzly si potřebují vyměňovat informace a při velkém nasazení mohou tato data hodně zavážit.
Když byla topologie nestabilní, potřeboval koordinátor přepočítat rozložení služeb. A obecně, když musíte pracovat s transakcemi na nestabilní topologii, může to vést k těžko předvídatelným chybám.
Problémy
Jaké jsou globální změny bez doprovodných problémů? První z nich byla změna topologie. Musíte pochopit, že kdykoli, dokonce i v okamžiku nasazení služby, může uzel vstoupit nebo opustit cluster. Navíc, pokud se v době nasazení uzel připojí ke clusteru, bude nutné důsledně přenášet všechny informace o službách do nového uzlu. A to se nebavíme jen o tom, co již bylo nasazeno, ale také o současných a budoucích nasazeních.
Toto je jen jeden z problémů, které lze shromáždit v samostatném seznamu:
- Jak nasadit staticky nakonfigurované služby při spuštění uzlu?
- Opuštění uzlu z clusteru – co dělat, pokud uzel hostuje služby?
- Co dělat, když se koordinátor změnil?
- Co dělat, když se klient znovu připojí ke clusteru?
- Je nutné zpracovat požadavky na aktivaci/deaktivaci a jak?
- Co když volali po zničení mezipaměti a my s tím máme spojené afinitní služby?
A to není vše.
rozhodnutí
Jako cíl jsme zvolili Event Driven přístup s implementací procesní komunikace pomocí zpráv. Ignite již implementuje dvě komponenty, které umožňují uzlům předávat zprávy mezi sebou – communication-spi a discovery-spi.
Communication-spi umožňuje uzlům komunikovat přímo a předávat zprávy. Dobře se hodí pro odesílání velkého množství dat. Discovery-spi umožňuje odeslat zprávu všem uzlům v clusteru. Ve standardní implementaci se to provádí pomocí kruhové topologie. Nechybí ani integrace se Zookeeperem, v tomto případě je použita hvězdicová topologie. Dalším důležitým bodem, který stojí za zmínku, je, že discovery-spi poskytuje záruky, že zpráva bude určitě doručena ve správném pořadí všem uzlům.
Podívejme se na protokol nasazení. Všechny požadavky uživatelů na nasazení a zrušení nasazení jsou odesílány přes discovery-spi. To dává následující záruky:
- Požadavek bude přijat všemi uzly v clusteru. To umožní pokračovat ve zpracování žádosti, když se změní koordinátor. To také znamená, že v jedné zprávě bude mít každý uzel všechna potřebná metadata, jako je konfigurace služby a její serializovaná instance.
- Přísné uspořádání doručování zpráv pomáhá vyřešit konflikty v konfiguraci a konkurenční požadavky.
- Vzhledem k tomu, že vstup uzlu do topologie je zpracováván také prostřednictvím discovery-spi, nový uzel obdrží všechna data nezbytná pro práci se službami.
Když je požadavek přijat, uzly v klastru jej ověří a vytvoří úlohy zpracování. Tyto úlohy jsou zařazeny do fronty a poté zpracovány v jiném vlákně samostatným pracovníkem. Je implementován tímto způsobem, protože nasazení může trvat značné množství času a neúnosně zdržovat drahý tok zjišťování.
Všechny požadavky z fronty zpracovává správce implementace. Má speciálního pracovníka, který stáhne úlohu z této fronty a inicializuje ji, aby mohla začít nasazení. Poté proběhnou následující akce:
- Každý uzel nezávisle vypočítá rozdělení díky nové deterministické funkci přiřazení.
- Uzly vygenerují zprávu s výsledky nasazení a odešlou ji koordinátorovi.
- Koordinátor agreguje všechny zprávy a generuje výsledek celého procesu nasazení, který se posílá přes discovery-spi do všech uzlů v clusteru.
- Po obdržení výsledku proces nasazení skončí, po kterém je úloha odstraněna z fronty.
Nový design řízený událostmi: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Pokud během nasazení dojde k chybě, uzel tuto chybu okamžitě zahrne do zprávy, kterou odešle koordinátorovi. Po agregaci zpráv bude mít koordinátor informace o všech chybách během nasazení a pošle tuto zprávu přes discovery-spi. Informace o chybě budou k dispozici na libovolném uzlu v clusteru.
Všechny důležité události v Service Grid jsou zpracovávány pomocí tohoto provozního algoritmu. Například změna topologie je také zprávou přes discovery-spi. A obecně, ve srovnání s tím, co bylo dříve, se protokol ukázal jako docela lehký a spolehlivý. Dost na zvládnutí jakékoli situace během nasazení.
Co se stane příště
Nyní o plánech. Jakákoli větší změna projektu Ignite je dokončena jako iniciativa pro zlepšení Ignite, nazývaná IEP. Redesign Service Grid má také IEP - s posměšným názvem „Výměna oleje v servisní mřížce“. Ale ve skutečnosti jsme neměnili motorový olej, ale celý motor.
Úkoly v IEP jsme rozdělili do 2 fází. První je hlavní fáze, která spočívá v přepracování protokolu nasazení. Je již součástí masteru, můžete vyzkoušet nový Service Grid, který se objeví ve verzi 2.8. Druhá fáze zahrnuje mnoho dalších úkolů:
- Hot přemístění
- Verze služby
- Zvýšená odolnost proti chybám
- Tenký klient
- Nástroje pro sledování a výpočty různých metrik
Nakonec vám můžeme poradit ohledně Service Grid pro budování systémů odolných vůči chybám a vysoké dostupnosti. Zveme vás také k návštěvě na adrese и podělte se o své zkušenosti. Vaše zkušenost je pro komunitu opravdu důležitá, pomůže vám pochopit, kam se dále posunout, jak komponentu v budoucnu vyvinout.
Zdroj: www.habr.com