Apache Ignite Zero Deployment: resnično Zero?

Smo smo oddelek za razvoj tehnologij maloprodajne mreže. Enkrat je vodstvo postavilo nalogo pospešiti obsežne izračune z uporabo Apache Ignite v povezavi z MSSQL, pokazalo je spletno stran s čudovitimi ilustracijami in primeri Java kode. Na spletni strani me je takoj navdušila Zero Deployment, katere opis obljublja čudeže: you don’t have to manually deploy your Java or Scala code on each node in the grid and re-deploy it each time it changes. Med delom se je izkazalo, da Zero Deployment ima posebnosti uporabe, o katerih želim deliti svoje misli. Pod katom so razmišljanja in podrobnosti izvedbe.

1. Postavitev naloge

Namen naloge je naslednji. Obstaja imenik prodajnih mest SalesPoint in imenik izdelkov Sku (Stock Keeping Unit). Prodajno mesto ima atribut „tipTrgovine“ z vrednostmi „majhna“ in „velika“. K vsakemu prodajnemu mestu se priključi (naloži iz SDB) asortiman (seznam izdelkov na prodajnem mestu) in se poda informacija, da se od določenega datuma določen izdelek
izključi iz asortimana ali doda v asortiman.

Potrebno je organizirati particionirano predpomnilnik prodajnih mest in shraniti v njem informacije o priključenih izdelkih za en mesec vnaprej. Združljivost z produkcijskim sistemom od odjemalskega vozlišča Ignite zahteva nalaganje podatkov, izračun agregatne vrste (tipTrgovine, kodaIzdelka, dan, število_prodajnih_mest) in njihovo ponovno nalaganje v SDB.

2. Preučevanje literature

Zdaj nimam še izkušenj, zato začnem od začetka. Torej z pregledom publikacij.

Članek iz leta 2016 Seznanitev z Apache Ignite: prvi koraki vsebuje povezavo do dokumentacije projekta Apache Ignite in hkrati očitek o nejasnosti te dokumentacije. Prebral sem ga parkrat, a jasnost ne pride. Obrnem se na uradni tutorial getting-started, ki
optimistično obljublja «You’ll be up and running in a jiffy!». Razčlenjujem nastavitve okolskih spremenljivk, gledam dva videa Apache Ignite Essentials, za moje specifične naloge se niso izkazali kot zelo koristni. Uspešno zaženem Ignite iz ukazne vrstice s standardno datoteko «example-ignite.xml», sestavim prvo aplikacijo Compute Application s pomočjo Mavena. Aplikacija deluje in uporablja Zero Deployment, kakšna lepota!

Beri naprej, a tam primer takoj uporablja affinityKey (ustvarjen prej preko SQL poizvedbe), pa še uporablja skrivnostni BinaryObject:

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

Prebral sem malo: binarni format — nekaj takega kot refleksija, dostop do polj objekta po imenu. Lahko prebere vrednost polja brez popolne deserializacije objekta (varčevanje s pomnilnikom). Ampak zakaj se namesto Person uporablja BinaryObject, ko pa obstaja Zero Deployment? Zakaj se IgniteCache<Key,Person> prevaja v IgniteCache<BinaryObject, BinaryObject>? Zaenkrat ni jasno.

Predelujem Compute Application za svoj primer. Primarni ključ imenika prodajnih mest v MSSQL je določen kot [id] [int] NOT NULL, ustvarjam predpomnilnik po analogiji

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

V xml-konfiguraciji navajam, da je predpomnilnik deljen

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

Deljenje po prodajnih mestih domneva, da bo zahtevan agregat zgrajen na vsakem vozlišču pomladne za obstoječe zapise salesPointCache, po čemer bo odjemalsko vozlišče izvedlo končno seštevanje.

Beri tutorial Prva Ignite Compute Application, delam po analogiji. Na vsakem vozlišču pomladne zažene IgniteRunnable(), približno takole:

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

Dodajam logiko agregacije in izvažanja, izvajam na testnem naboru podatkov. Lokalno na razvojnem strežniku vse deluje.

Zaganjam dva testna strežnika CentOs, navajam ip-naslove v default-config.xml, izvajam na vsakem

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

Oba vozlišča Ignite se zažgeta in vidita drug drugega. Ustvarim potrebne naslove v xml-konfiguraciji odjemalske aplikacije, zažene se, doda tretje vozlišče v topologijo in takoj postaneta spet dva vozlišča. V dnevniku je zabeleženo „ClassNotFoundException: model.SalesPoint“ v vrstici

SalesPoint sp=salesPointCache.get(spId);

StackOverflow pravi, da je razlog za napako — na strežnikih CentOs ni uporabniške klase SalesPoint. Prispeli smo. Kako potem „you don’t have to manually deploy your Java code on each node“ in tako naprej? Ali „your Java code“ — to ni o SalesPoint?

Verjetno sem nekaj izpustil — znova začnem iskati, brati in znova iskati. Po nekaj času dobim občutek, da sem prebral vse o temi, nič novega ni več. Med iskanjem sem našel nekaj zanimivih opažanj.

Valentin Kulichenko, vodilni arhitekt pri GridGain Systems, odgovor na StackOverflow, april 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 eno avtoritativno mnenje: Denis Magda, direktor upravljanja s produktom, GridGain Systems.

Članek na Habré o mikroservisih obešča tri članka Denis Magda: Mikroservisi Del I, Mikroservisi Del II, Mikroservisi Del III let 2016-2017. V drugem članku Denis predlaga, da se začetna vozlišča grozda zagnajo preko MaintenanceServiceNodeStartup.jar. Prav tako je mogoče uporabiti zagon z xml-konfiguracijo in ukazno vrstico, vendar je treba v tem primeru ročno naložiti uporabniške razrede na vsak razporejeni vozliščni grozd:

To je to. Začnite (..) vozlišče z uporabo datoteke MaintenanceServiceNodeStartup ali prenesite maintenance-service-node-config.xml v Apache Igniteove ignite.sh/bat skripte. Če raje izberete slednje, se prepričajte, da zgradite jar datoteko, ki bo vsebovala vse razrede iz java/app/common in java/services/maintenance direktorijev. Jar mora biti dodan v classpath vsakega vozlišča, kjer se storitev lahko namesti.

Dejansko, to je to. Tu je, očitno, zakaj obstaja ta skrivnostni binarni format!

3. SingleJar

Denis je zasedel prvo mesto v mojem osebnem izboru, po mojem mnenju najkoristnejši vadnica med vsemi na voljo. V njegovem MicroServicesExample na GitHubu je popoln primer nastavitve vozlišč grozda, ki se ustvari brez kakršnih koli dodatnih težav.

Delam po vzoru in podobnosti, dobim enotno jar datoteko, ki zažene "data node" ali "client node" glede na argument ukazne vrstice. Zbirka se zažene in deluje. Zero Deployment je premagan.

Prehod od megabajtnih testnih podatkov k desetinami gigabajtov operativnih je pokazal, da binarni format ni brez razloga. Potrebno je bilo optimizirati porabo pomnilnika na vozliščih, in tu se je BinaryObject izkazal za zelo uporabnega.

4. Zaključki

Prvi zasledovani očitek v smislu nejasnosti dokumentacije projekta Apache Ignite se je izkazal za upravičen, od leta 2016 se je malo spremenilo. Novincu ni lahko sestaviti delujočega prototipa na podlagi spletne strani in/ali repozitorija.

Po opravljenem delu se je zdelo, da Zero Deployment deluje, vendar le na sistemski ravni. Približno tako: BinaryObject se uporablja za poučevanje oddaljenih vozlišč grozda, kako delati z uporabniškimi razredi; Zero Deployment je notranji mehanizem
samo Apache Ignite in razširja sistemske objekte po grozdu.

Upam, da bo moje izkušnje koristilo novim uporabnikom Apache Ignite.

Izvor: habr.com