Apache Ignite Zero Deployment: Opravdu nulové?

Jsme oddělení technologického vývoje maloobchodní sítě. Jednoho dne si vedení dalo za úkol urychlit rozsáhlé výpočty pomocí Apache Ignite ve spojení s MSSQL a ukázalo webovou stránku s krásnými ilustracemi a příklady Java kódu. Stránky se mi hned zalíbily Nulové nasazení, jehož popis slibuje zázraky: nemusíte ručně nasazovat svůj kód Java nebo Scala na každý uzel v mřížce a znovu jej nasazovat pokaždé, když se změní. Jak práce postupovaly, ukázalo se, že Zero Deployment má specifické využití, o jehož vlastnosti se chci podělit. Pod řezem jsou myšlenky a detaily implementace.

1. Vyjádření problému

Podstata problému je následující. Existuje adresář prodejních míst SalesPoint a produktový adresář Sku (Stock Keeping Unit). Prodejní místo má atribut „Typ obchodu“ s hodnotami „malý“ a „velký“. Ke každému prodejnímu místu (načtenému z DBMS) je připojen sortiment (seznam produktů prodejního místa) a je uvedena informace, že od uvedeného data je uvedený produkt
vyřazeny ze sortimentu nebo přidány do sortimentu.

Je nutné uspořádat rozdělenou mezipaměť prodejních míst a ukládat do ní informace o připojených produktech na měsíc předem. Kompatibilita s bojovým systémem vyžaduje, aby klientský uzel Ignite načetl data, vypočítal agregaci formuláře (typ obchodu, kód produktu, den, počet_prodejních_bodů) a nahrál je zpět do DBMS.

2. Studium literatury

Ještě nemám žádné zkušenosti, tak začínám tančit od plotny. Tedy z recenze publikací.

Článek 2016 Představujeme Apache Ignite: První kroky obsahuje odkaz na dokumentaci projektu Apache Ignite a zároveň výtku k vágnosti této dokumentace. Přečetl jsem to několikrát znovu, srozumitelnost nepřichází. Odkazuji na oficiální návod začínámeKterý
optimisticky slibuje: "Budete v provozu během okamžiku!" Zjišťuji nastavení proměnných prostředí, sleduji dvě videa Apache Ignite Essentials, ale pro můj konkrétní úkol nebyla příliš užitečná. Úspěšně jsem spustil Ignite z příkazového řádku se standardním souborem „example-ignite.xml“, čímž jsem vytvořil první aplikaci Výpočetní aplikace pomocí Maven. Aplikace funguje a využívá Zero Deployment, jaká krása!

Četl jsem dále a tam příklad okamžitě používá affinityKey (vytvořený dříve prostřednictvím dotazu SQL) a dokonce používá tajemný BinaryObject:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

číst trochu: binární formát - něco jako odraz, přístup k polím objektu podle názvu. Dokáže číst hodnotu pole bez úplné deserializace objektu (úspora paměti). Ale proč se používá BinaryObject místo Person, když je zde nulové nasazení? Proč IgniteCache převedeny do IgniteCache ? Zatím to není jasné.

Předělávám Compute Application tak, aby vyhovovala mému případu. Primární klíč adresáře prodejních míst v MSSQL je definován jako [id] [int] NOT NULL, analogicky vytvářím mezipaměť

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

V xml konfiguraci označuji, že mezipaměť je rozdělena

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

Rozdělení podle prodejního místa předpokládá, že na každém uzlu clusteru bude vytvořen požadovaný agregát pro záznamy salesPointCache, které jsou zde dostupné, a poté klientský uzel provede konečné sečtení.

Čtu návod První aplikace Ignite Compute, dělám to analogicky. Na každém uzlu clusteru spouštím IgniteRunnable(), něco takového:

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

Přidám agregaci a logiku nahrávání a spustím ji na testovací sadě dat. Vše funguje lokálně na vývojovém serveru.

Spustím dva testovací servery CentOs, specifikuji IP adresy v default-config.xml a spustím na každém

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

Oba Ignite uzly běží a vidí se navzájem. V xml configu klientské aplikace zadám požadované adresy, spustí se, přidá třetí uzel do topologie a hned jsou zase dva uzly. Protokol zobrazuje v řádku „ClassNotFoundException: model.SalesPoint“.

SalesPoint sp=salesPointCache.get(spId);

StackOverflow říká, že důvodem chyby je, že na serverech CentOs neexistuje žádná vlastní třída SalesPoint. Přijeli jsme. Co takhle „nemusíte ručně nasazovat svůj kód Java na každý uzel“ a tak dále? Nebo „váš kód Java“ není o SalesPointu?

Asi mi něco uniklo – začínám znovu hledat, číst a znovu hledat. Po chvíli mám pocit, že jsem k tématu přečetl vše, nic nového už není. Když jsem hledal, našel jsem zajímavé komentáře.

Valentin Kulichenko, hlavní architekt ve společnosti GridGain Systems, odpověď na StackOverflow, duben 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.

Další autoritativní názor: Denis Magda, ředitel produktového managementu, GridGain Systems.

Článek o Habrém o mikroslužbách odkazuje na tři články Denise Magdy: Mikroslužby část I, Mikroslužby Část II, Mikroslužby Část III 2016-2017. Ve druhém článku Denis navrhuje spustit uzel clusteru přes MaintenanceServiceNodeStartup.jar. Můžete také použít spuštění s konfigurací xml a příkazovým řádkem, ale pak musíte ručně umístit vlastní třídy na každý nasazený uzel clusteru:

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

Opravdu, to je ono. Tady se ukazuje, proč, tento záhadný binární formát!

3.SingleJar

Denis obsadil první místo v mém osobním hodnocení, IMHO nejužitečnější tutoriál ze všech dostupných. V jeho Příklad mikroslužeb Github obsahuje zcela hotovou ukázku nastavení clusterových uzlů, která se zkompiluje bez dalšího squattingu.

Dělám to stejným způsobem a získám jeden soubor jar, který spouští „datový uzel“ nebo „klientský uzel“ v závislosti na argumentu příkazového řádku. Montáž začíná a funguje. Zero Deployment bylo poraženo.

Přechod od megabajtů testovacích dat k desítkám gigabajtů bojových dat ukázal, že binární formát existuje z nějakého důvodu. Bylo nutné optimalizovat spotřebu paměti na uzlech a právě zde se BinaryObject ukázal jako velmi užitečný.

4. Závěry

První výtka k vágnosti projektové dokumentace Apache Ignite se ukázala jako spravedlivá, od roku 2016 se toho změnilo jen málo. Pro začátečníka není snadné sestavit funkční prototyp založený na webu a/nebo úložišti.

Na základě výsledků odvedené práce vznikl dojem, že Zero Deployment funguje, ale pouze na systémové úrovni. Něco jako toto: BinaryObject se používá k výuce vzdálených uzlů clusteru pracovat s vlastními třídami; Zero Deployment - vnitřní mechanismus
Apache Ignite sám sebe a distribuuje systémové objekty po celém clusteru.

Doufám, že moje zkušenost bude užitečná pro nové uživatele Apache Ignite.

Zdroj: www.habr.com