26. februára sme usporiadali stretnutie Apache Ignite GreenSource, na ktorom vystúpili prispievatelia do projektu s otvoreným zdrojovým kódom . Dôležitou udalosťou v živote tejto komunity bola reštrukturalizácia zložky , ktorý vám umožňuje nasadiť vlastné mikroslužby priamo do klastra Ignite. Na stretnutí hovoril o tomto náročnom procese , softvérový inžinier a prispievateľ Apache Ignite už viac ako dva roky.
Začnime tým, čo je Apache Ignite vo všeobecnosti. Ide o databázu, ktorá je distribuovaným úložiskom kľúča/hodnoty s podporou SQL, transakcií a ukladania do vyrovnávacej pamäte. Okrem toho vám Ignite umožňuje nasadiť vlastné služby priamo do klastra Ignite. Vývojár má prístup ku všetkým nástrojom, ktoré Ignite poskytuje – distribuované dátové štruktúry, Messaging, Streaming, Compute a Data Grid. Napríklad pri použití Data Gridu odpadá problém so správou samostatnej infraštruktúry na ukladanie dát a v dôsledku toho aj výsledné režijné náklady.
Pomocou API Service Grid môžete službu nasadiť jednoduchým zadaním schémy nasadenia a podľa toho aj samotnej služby v konfigurácii.
Schéma nasadenia zvyčajne označuje počet inštancií, ktoré by sa mali nasadiť na klastrové uzly. Existujú dve typické schémy nasadenia. Prvým je Cluster Singleton: v každom danom čase je zaručené, že v klastri bude dostupná jedna inštancia používateľskej služby. Druhým je Node Singleton: jedna inštancia služby je nasadená na každom uzle klastra.
Užívateľ môže tiež zadať počet inštancií služby v celom klastri a definovať predikát na filtrovanie vhodných uzlov. V tomto scenári sám Service Grid vypočíta optimálnu distribúciu pre nasadenie služieb.
Okrem toho existuje taká funkcia ako služba Affinity. Afinita je funkcia, ktorá definuje vzťah kľúčov k oddielom a vzťah strán k uzlom v topológii. Pomocou kľúča môžete určiť primárny uzol, na ktorom sú uložené údaje. Týmto spôsobom môžete priradiť svoju vlastnú službu k vyrovnávacej pamäti kľúčov a funkcií afinity. Ak sa funkcia afinity zmení, dôjde k automatickému premiestneniu. Týmto spôsobom bude služba vždy umiestnená blízko údajov, s ktorými potrebuje manipulovať, a teda zníži réžiu prístupu k informáciám. Túto schému možno nazvať akýmsi spoločným výpočtom.
Teraz, keď sme zistili, v čom spočíva krása Service Grid, poďme sa rozprávať o histórii jeho vývoja.
Čo sa stalo predtým
Predchádzajúca implementácia Service Grid bola založená na transakčnej replikovanej systémovej vyrovnávacej pamäti Ignite. Slovo "cache" v Ignite sa týka úložiska. To znamená, že to nie je niečo dočasné, ako by ste si mohli myslieť. Napriek tomu, že vyrovnávacia pamäť je replikovaná a každý uzol obsahuje celú množinu údajov, vo vnútri vyrovnávacej pamäte má rozdelené zobrazenie. Dôvodom je optimalizácia úložiska.
Čo sa stalo, keď chcel používateľ službu nasadiť?
- Všetky uzly v klastri sa prihlásili na aktualizáciu údajov v úložisku pomocou vstavaného mechanizmu nepretržitého dopytovania.
- Iniciačný uzol v rámci transakcie s potvrdením čítania vytvoril záznam v databáze, ktorý obsahoval konfiguráciu služby vrátane serializovanej inštancie.
- Po upozornení na nový záznam koordinátor vypočítal rozdelenie na základe konfigurácie. Výsledný objekt bol zapísaný späť do databázy.
- Ak bol uzol súčasťou distribúcie, koordinátor ho musel nasadiť.
Čo nám nevyhovovalo
V určitom momente sme dospeli k záveru: takto sa so službami nepracuje. Dôvodov bolo viacero.
Ak sa pri nasadzovaní vyskytla nejaká chyba, tak sa to dalo zistiť len z protokolov uzla, kde sa všetko stalo. Došlo len k asynchrónnemu nasadeniu, takže po vrátení kontroly používateľovi z metódy nasadenia bol potrebný ďalší čas na spustenie služby – a počas tejto doby používateľ nemohol nič ovládať. Aby sme mohli ďalej rozvíjať Service Grid, vytvárať nové funkcie, priťahovať nových používateľov a uľahčovať život všetkým, je potrebné niečo zmeniť.
Pri navrhovaní nového Service Gridu sme chceli v prvom rade poskytnúť záruku synchrónneho nasadenia: hneď ako používateľ vrátil kontrolu z API, mohol služby okamžite využívať. Chcel som tiež dať iniciátorovi schopnosť zvládnuť chyby nasadenia.
Okrem toho som chcel zjednodušiť implementáciu, a to preč od transakcií a vyvažovania. Napriek tomu, že cache je replikovaná a nedochádza k balansovaniu, pri veľkom nasadení s mnohými uzlami nastali problémy. Keď sa zmení topológia, uzly si potrebujú vymieňať informácie a pri veľkom nasadení môžu tieto údaje zavážiť veľa.
Keď bola topológia nestabilná, koordinátor potreboval prepočítať distribúciu služieb. A vo všeobecnosti, keď musíte pracovať s transakciami na nestabilnej topológii, môže to viesť k ťažko predvídateľným chybám.
Problémy
Aké sú globálne zmeny bez sprievodných problémov? Prvým z nich bola zmena topológie. Musíte pochopiť, že kedykoľvek, dokonca aj v okamihu nasadenia služby, môže uzol vstúpiť do klastra alebo ho opustiť. Navyše, ak sa v čase nasadenia uzol pripojí do klastra, bude potrebné dôsledne prenášať všetky informácie o službách do nového uzla. A to nehovoríme len o tom, čo už bolo nasadené, ale aj o súčasných a budúcich nasadeniach.
Toto je len jeden z problémov, ktoré možno zhromaždiť v samostatnom zozname:
- Ako nasadiť staticky nakonfigurované služby pri spustení uzla?
- Opustenie uzla z klastra – čo robiť, ak uzol hostil služby?
- Čo robiť, ak sa zmenil koordinátor?
- Čo robiť, ak sa klient znova pripojí ku klastru?
- Je potrebné spracovať žiadosti o aktiváciu/deaktiváciu a ako?
- Čo keby požadovali zničenie vyrovnávacej pamäte a my by sme s tým mali spojené afinitné služby?
A to nie je všetko.
rozhodnutie
Ako cieľ sme zvolili Event Driven prístup s implementáciou procesnej komunikácie pomocou správ. Ignite už implementuje dva komponenty, ktoré umožňujú uzlom preposielať si správy medzi sebou – communication-spi a discovery-spi.
Communication-spi umožňuje uzlom komunikovať priamo a posielať správy ďalej. Je vhodný na odosielanie veľkého množstva dát. Discovery-spi vám umožňuje poslať správu všetkým uzlom v klastri. V štandardnej implementácii sa to robí pomocou kruhovej topológie. Nechýba ani integrácia so Zookeeperom, v tomto prípade je použitá hviezdicová topológia. Ďalším dôležitým bodom, ktorý stojí za zmienku, je, že discovery-spi poskytuje záruky, že správa bude určite doručená v správnom poradí do všetkých uzlov.
Pozrime sa na protokol nasadenia. Všetky požiadavky používateľov na nasadenie a zrušenie rozmiestnenia sa odosielajú cez discovery-spi. To dáva nasledujúce záruka:
- Požiadavku prijmú všetky uzly v klastri. To umožní pokračovať v spracovaní žiadosti, keď sa zmení koordinátor. To tiež znamená, že v jednej správe bude mať každý uzol všetky potrebné metadáta, ako je konfigurácia služby a jej serializovaná inštancia.
- Prísne usporiadanie doručovania správ pomáha vyriešiť konflikty konfigurácie a konkurenčné požiadavky.
- Keďže vstup uzla do topológie sa spracováva aj cez discovery-spi, nový uzol dostane všetky údaje potrebné na prácu so službami.
Keď je požiadavka prijatá, uzly v klastri ju overia a vytvoria úlohy spracovania. Tieto úlohy sú zaradené do frontu a potom spracované v inom vlákne samostatným pracovníkom. Toto je implementované týmto spôsobom, pretože nasadenie môže trvať značné množstvo času a neúnosne oneskoriť tok drahých objavov.
Všetky požiadavky z frontu spracuje manažér nasadenia. Má špeciálneho pracovníka, ktorý stiahne úlohu z tohto frontu a inicializuje ju, aby sa mohla začať nasadzovať. Potom sa vykonajú nasledujúce akcie:
- Každý uzol nezávisle vypočíta rozdelenie vďaka novej funkcii deterministického priradenia.
- Uzly vygenerujú správu s výsledkami nasadenia a pošlú ju koordinátorovi.
- Koordinátor agreguje všetky správy a generuje výsledok celého procesu nasadenia, ktorý sa posiela cez discovery-spi do všetkých uzlov v klastri.
- Po prijatí výsledku sa proces nasadenia ukončí, po ktorom sa úloha odstráni z frontu.
Nový dizajn riadený udalosťami: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ak sa počas nasadenia vyskytne chyba, uzol túto chybu okamžite zahrnie do správy, ktorú pošle koordinátorovi. Po agregácii správ bude mať koordinátor informácie o všetkých chybách počas nasadenia a pošle túto správu cez discovery-spi. Informácie o chybe budú k dispozícii na akomkoľvek uzle v klastri.
Všetky dôležité udalosti v Service Grid sú spracované pomocou tohto operačného algoritmu. Napríklad zmena topológie je tiež správou cez discovery-spi. A vo všeobecnosti, v porovnaní s tým, čo bolo predtým, sa protokol ukázal ako pomerne ľahký a spoľahlivý. Dosť na zvládnutie akejkoľvek situácie počas nasadenia.
Čo bude ďalej
Teraz o plánoch. Akákoľvek väčšia zmena projektu Ignite je dokončená ako iniciatíva na zlepšenie Ignite, nazývaná IEP. Redizajn Service Grid má tiež IEP - s posmešným názvom „Výmena oleja v servisnej sieti“. V skutočnosti sme však nevymenili motorový olej, ale celý motor.
Úlohy v IEP sme rozdelili do 2 fáz. Prvá je hlavná fáza, ktorá pozostáva z prepracovania protokolu nasadenia. Je už súčasťou mastera, môžete vyskúšať nový Service Grid, ktorý sa objaví vo verzii 2.8. Druhá fáza zahŕňa mnoho ďalších úloh:
- Hot redislokácia
- Verzia služby
- Zvýšená odolnosť voči chybám
- Tenký klient
- Nástroje na sledovanie a výpočet rôznych metrík
Nakoniec vám môžeme poradiť ohľadom Service Grid na budovanie systémov odolných voči chybám a vysokej dostupnosti. Pozývame vás tiež navštíviť nás na и podeľte sa o svoje skúsenosti. Vaša skúsenosť je pre komunitu skutočne dôležitá; pomôže vám pochopiť, kam sa posunúť ďalej, ako rozvíjať komponent v budúcnosti.
Zdroj: hab.com