Apache Ignite Zero Deployment: naozaj Zero?

Sme oddelenie zodpovedné za rozvoj technológií maloobchodnej siete. Raz nám vedenie zadalo úlohu urýchliť objemové výpočty použitím Apache Ignite v spojení s MSSQL, ukázali nám webovú stránku s nádhernými ilustráciami a príkladmi Java kódu. Webová stránka sa nám hneď zapáčila. Zero Deployment, ktorého popis sľubuje zázraky: nemusíte manuálne nasadzovať svoj Java alebo Scala kód na každý uzol v sieti a znovu ho nasadzovať vždy, keď sa zmení. Počas práce sa ukázalo, že Zero Deployment má špecifiká použitia, a o týchto špecifikách sa chcem podeliť. Pod katom sú úvahy a podrobnosti implementácie.

1. Stanovenie úlohy

Podstata úlohy je nasledovná. Existuje adresár predajných miest SalesPoint a adresár produktov Sku (Stock Keeping Unit). Predajné miesto má atribút „typObchodu“ so zákonnými hodnotami „malý“ a „veľký“. K každému predajnému miestu je pripojený (načítaný z DB) sortiment (zoznam produktov predajného miesta) a je poskytnutá informácia o tom, že od uvedeného dátumu daný produkt
bude vylúčený z sortimentu alebo pridaný do sortimentu.

Je potrebné organizovať partitioned cache predajných miest a uchovávať v ňom informácie o pripojených produktoch na mesiac dopredu. Kompatibilita s prevádzkovým systémom vyžaduje, aby klientsky uzol Ignite načítaval údaje, počítal agregát vo forme (typObchodu, kódProduktu, deň, počet_predajných_miest) a vyexpedoval ho späť do DB.

2. Štúdium literatúry

Zatiaľ nemám žiadne skúsenosti, takže začínam od základov. To znamená, že sa oboznamujem s publikáciami.

Článok z roku 2016 Zoznámenie sa s Apache Ignite: prvé kroky obsahuje odkaz na dokumentáciu projektu Apache Ignite a zároveň kritiku nejasnosti tejto dokumentácie. Prečítal som si to niekoľkokrát, ale nechápem to. Obraciam sa na oficiálny tutoriál getting-started, ktorý
optimisticky sľubuje „Budete pripravení v okamihu!“. Rozoberám nastavenia environmentálnych premenných, sledujem dve videá Apache Ignite Essentials, pre moju konkrétnu úlohu sa zdali byť nie veľmi užitočné. Úspešne spúšťam Ignite z príkazového riadku so štandardným súborom „example-ignite.xml“, skladám prvú aplikáciu Compute Application s pomocou Maven. Aplikácia funguje a využíva Zero Deployment, aká krása!

Čítam ďalej a tam príklad hneď používa affinityKey (vytvorený skôr cez SQL dotaz), navyše sa tu uplatňuje záhadný BinaryObject:

IgniteCache people 
        = ignite.cache("Person").withKeepBinary(); 

Prečítal som si. trochu: binárny formát — niečo ako reflexia, prístup k poliam objektu podľa mena. Môže čítať hodnotu poľa bez úplnej deserializácie objektu (úspora pamäte). Ale prečo sa namiesto Person používa BinaryObject, veď existuje Zero Deployment? Prečo sa IgniteCache prekladá na IgniteCache? Zatiaľ nie je jasné.

Prepracovávam Compute Application podľa svojho prípadu. Primárny kľúč adresára predajných miest v MSSQL je definovaný ako [id] [int] NOT NULL, vytváram cache analogicky.

IgniteCache salesPointCache=ignite.cache("spCache")

V xml-konfigu uvádzam, že cache je partitioned.

Partitionovanie podľa predajných miest predpokladá, že požadovaný agregát bude postavený na každom uzle clustera pre existujúce záznamy salesPointCache, po čom klientský uzol vykoná konečné sumarovanie.

Čítam tutorial. First Ignite Compute Application, robím analogicky. Na každom uzle clustera spúšťam IgniteRunnable(), približne takto:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

Pridávam logiku agregácie a exportu, spúšťam na testovacom súbore údajov. Lokálne na serveri vývoja všetko funguje.

Spúšťam dva testovacie servery CentOs, uvádzam ip-adresy v default-config.xml, vykonávam na každom

./bin/ignite.sh config/default-config.xml

Oba uzly Ignite sa spúšťajú a vidia navzájom. Uvádzam potrebné adresy v xml-konfigu klientskej aplikácie, tá sa spúšťa, pridáva tretí uzol do topológie a hneď sú opäť len dva uzly. V logu je zaznamenané „ClassNotFoundException: model.SalesPoint“ v riadku

SalesPoint sp=salesPointCache.get(spId);

StackOverflow hovorí, že príčina chyby — na serveroch CentOs nie je používateľská trieda SalesPoint. Prišli sme. Ako je to s „you don’t have to manually deploy your Java code on each node“ a ďalej v texte? Alebo „your Java code“ — to nie je o SalesPoint?

Pravdepodobne som niečo prehliadol — znovu začínam hľadať, čítať a znova hľadať. Po čase vzniká pocit, že som si prečítal všetko, čo sa týka témy, nič nové už nie je. Kým som hľadal, našiel som niekoľko zaujímavých poznámok.

Valentin Kulichenko, Lead Architect at GridGain Systems, odpovedi na StackOverflow, apríl 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

Ešte jeden autoritatívny názor: Denis Magda, Director of product management, GridGain Systems.

Článok na Habbre o mikroslužbách odkazuje na tri články Denis Magda: Mikroslužby Časť I, Mikroslužby Časť II, Mikroslužby Časť III Roky 2016-2017. V druhej časti Denis navrhuje spustiť uzol klastrového systému pomocou súboru MaintenanceServiceNodeStartup.jar. Môžete tiež použiť spustenie s xml-konfiguráciou a príkazovým riadkom, ale v tom prípade musíte ručne umiestniť používateľské triedy na každý nasadzovaný uzol klastrového systému:

To je všetko. Spustite uzol pomocou súboru MaintenanceServiceNodeStartup alebo prejdite
na maintenance-service-node-config.xml v skriptoch ignite.sh/bat Apache Ignite.
Ak uprednostňujete druhú možnosť, uistite sa, že ste vytvorili jar súbor, ktorý obsahuje
všetky triedy z adresárov java/app/common a java/services/maintenance.
Tento jar musíte pridať do classpath každého uzla, na ktorom môže byť služba
nasadená.

Naozaj, to je všetko. Aha, takže preto existuje tento tajomný binárny formát!

3. SingleJar

Denis zaujal prvé miesto v mojom osobnom rebríčku, podľa mňa je to najúžitočnejší tutoriál zo všetkých dostupných. V ňom MicroServicesExample na GitHube sa nachádza úplne pripravený príklad nastavenia uzlov klastrového systému, ktorý sa kompiluje bez akýchkoľvek ďalších problémov.

Robím podľa vzoru a podobizne, dostávam jeden súbor jar, ktorý spúšťa "data node" alebo "client node" v závislosti od argumentu príkazového riadku. Kompilácia prebieha a funguje. Zero Deployment je prekonané.

Prechod od megabajtov testovacích údajov k desiatkam gigabajtov reálnych údajov ukázal, že binárny formát naozaj má zmysel. Bolo potrebné optimalizovať spotrebu pamäte na uzloch, a tu sa BinaryObject ukázal ako veľmi užitočný.

4. Závery

Prvý zaznamenaný neduh v nejasnosti dokumentácie projektu Apache Ignite sa ukázal byť oprávnený, od roku 2016 sa toho veľa nezmenilo. Začiatočník má ťažkosti so zostavením funkčného prototypu na základe webovej stránky a/alebo repozitára.

Na základe vykonanej práce mám pocit, že Zero Deployment funguje, ale len na systémovej úrovni. Približne takto: BinaryObject sa používa na učenie vzdialených uzlov klastrového systému pracovať s používateľskými triedami; Zero Deployment je vnútorný mechanizmus
samého Apache Ignite a distribuovaný po klastre systémové objekty.

Dúfam, že moje skúsenosti budú užitočné novým používateľom Apache Ignite.

Zdroj: habr.com