Apache Ignite Null Deployments: tõesti Null?

Me oleme jaemüügi tehnoloogia arenduse osakond. Ükskord pani juhtkond ülesande kiirendada mahukaid arvutusi, kasutades Apache Ignite'i koos MSSQL-iga, näidates suurepäraseid illustreerimisi ja Java-koodi näiteid veebilehel. Veebileht meeldis kohe. Zero Deployment, mille kirjeldus lubab imesid: te ei pea oma Java või Scala koodi igal node'il käsitsi paigaldama ja seda iga kord, kui see muutub, uuesti paigaldama. Töö käigus selgus, et Zero Deployment'il on kasutamise eripära, mille spetsiifikaga soovin jagada. Edasi järgnevad mõtted ja rakenduse üksikasjad.

1. Probleemi määratlemine

Probleemi olemus on järgmine. On olemas müügikohtade register SalesPoint ja toodete register Sku (Stock Keeping Unit). Müügikohal on atribuut „tüüpmüügikoht” väärtustega „väike” ja „suur”. Iga müügikoha juurde on ühendatud (laaditud andmebaasist) sortiment (toodete nimekiri müügikohast) ning esitatakse teave selle kohta, et alates kindlast kuupäevast antud toode
kustutatakse sortimendist või lisatakse sortimenti.

Tuleb korraldada müügikohtade partitsioneeritud vahemälu ja salvestada sinna informatsioon ühendatud toodete kohta kuu ette. Sõjalise süsteemi ühilduvus nõuab, et kliendi sõlm Ignite laadib andmed, arvutab agregaat (poetüüp, tootekood, päev, müügikohtade arv) ja eksportib selle tagasi andmebaasi.

2. Kirjanduse uurimine

Kogemust veel ei ole, seega alustan nullist. St. alustan väljaannete ülevaatest.

2016. aasta artikkel Tutvumine Apache Ignite'iga: esimesed sammud sisaldab viidet Apache Ignite projekti dokumentatsioonile ja samas kriitikat selle ebamugava selguse osas. Lugesin paar korda uuesti, selgus ei tule. Pöördun ametliku õpetuse poole getting-started, mis
optimistlikult lubab, et "Sa saad kiiresti käima!". Uurin keskkonnamuutujate seadeid, vaatan kahte videot Apache Ignite Essentials, mis olid minu konkreetse ülesande jaoks mitte eriti kasulikud. Käivitan Ignite'i edukalt käsurealt standardfailiga "example-ignite.xml", loon esimese rakenduse Compute Application Maveniga. Rakendus töötab ja kasutab Zero Deployment'i, kui ilus!

Lugen edasi, seal on näide, mis kasutab kohe affinityKey (varasemalt loodud SQL-päringu kaudu) ja kohaldatakse salapärast BinaryObjecti:

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

Lugesin veidi: binaarne formaat — midagi nagu refleksioon, juurdepääs objekti väljadele nime järgi. Saab lugeda välja välja väärtust ilma objekti täieliku deserialiseerimiseta (mäluefektiivne). Miks kasutada BinaryObject'i, kui on olemas Zero Deployment? Miks IgniteCache<Key, Person> muudetakse IgniteCache<BinaryObject, BinaryObject>? Praegu pole selge.

Kohanen Compute Applicationi oma juhtumiga. Müügikohtade registri peamine võti MSSQL-is on määratletud kui [id] [int] NOT NULL, loon sarnase cache'i

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

Xml-konfiguratsioonis märgin, et cache on jagatud

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

Müügikohtade jagamine eeldab, et vajalik agregaat ehitatakse iga klastris oleva sõlme jaoks olemasolevatele salesPointCache kirjadele, pärast mida kliendisõlm teostab lõppsummeerimise.

Lugen siin õppematerjali Esimene Ignite Compute Application, teen seda tehes. Käivitame IgniteRunnable() iga klastripeal, umbes nii:

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

Lisaan agregatsiooni ja väljastamise põhiloogika, käivitan testkomplektiga. Kohalikul arendusserveril töötab kõik.

Käitan kaks testserverit CentOs, määran IP-aadressid default-config.xml, täidan igal serveril

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

Mõlemad Ignite noodid käivitatakse ja nad näevad teineteist. Määran vajalikud aadressid kliendi rakenduse xml-konfiguratsioonis, see käivitub, lisab kolmanda sõlme topoloogiasse ja kohe on neid jälle kaks. Logis on kirjas „ClassNotFoundException: model.SalesPoint“ real

SalesPoint sp=salesPointCache.get(spId);

StackOverflow ütleb, et vea põhjus on see, et CentOsi serverites puudub kasutajate klass SalesPoint. Oleme hädas. Kuidas on siis „you don’t have to manually deploy your Java code on each node“ ja edasi? Või „your Java code“ ei kehti SalesPointi kohta?

Tõenäoliselt olen midagi maha maganud — hakkan jälle otsima, lugema ja taas otsima. Aja möödudes tekib tunne, et olen teema kohta kõik lugenud, midagi uut enam ei ole. Otsimise käigus leidsin mõned huvitavad tähelepanekud.

Valentin Kulichenko, GridGain Systems'i peaarhitekt, vastuse StackOverflow'is, aprill 2016:

Mudeli klasse ei ole rakendatud, kuid saate kasutada withKeepBinary() lippu
mälus ja pärida BinaryObjecte. Nii väldite deserialiseerimist
serveripoolsel ja ei saa ClassNotFoundException'i.

Veel üks autoriteetne arvamus: Denis Magda, toote juhtimise direktor, GridGain Systems.

Artikkel Habrus mikroteenustest viitab Denis Magda kolmele artiklile: Mikroteenused I osa, Mikroteenused II osa, Mikroteenused III osa 2016-2017. aastal. Teises artiklis soovitab Denis käivitada klastrisõlme kasutades MaintenanceServiceNodeStartup.jar. Samuti saab kasutada käivitamist xml-konfiguratsiooni ja käsureaga, kuid siis tuleb iga klastrisse paigaldatava sõlme jaoks käsitsi lisada kasutaja klassid:

Nii ongi. Käivita (..) sõlm kasutades MaintenanceServiceNodeStartup faili või edasta
maintenance-service-node-config.xml Apache Ignite'i ignite.sh/bat skriptidele.
Kui eelistate teist, siis veenduge, et ehitate jar faili, mis sisaldab
kõiki klasse java/app/common ja java/services/maintenance kaustadest.
Jar peab olema lisatud iga sõlme classpath'i, kuhu teenus
võib olla paigaldatud.

Tõepoolest, see on see. Siin see on, näib, miks see salapärane binaarvorming on!

3. SingleJar

Denis on minu isiklikus edetabelis esikohal, minu arvates kõige kasulikum õpetus kõikidest saadaval olevatest. Tema MicroServicesExample GitHubis on täielik näide klastrisõlmede seadistamisest, mis kompileerib ilma igasuguste täiendavate üllatusteta.

Teen sarnaselt ning saan ühe jar-faili, mis käivitab 'data node' või 'client node' sõltuvalt käsurea argumendist. Kogumine käivitub ja töötab. Zero Deployment on alistatud.

Muutumine megabaidist testandmetest kümneteks gigabaitide tootmisandmeteks tõestas, et binaarvorming on olemas olulistel põhjustel. Oli vajalik optimeerida mälukasutust sõlmedes ning siin osutus BinaryObject väga kasulikuks.

4. Järeldused

Esimene kohtunud kriitika Apache Ignite projekti dokumentatsiooni ebaselguse osas osutus õigeks, alates 2016. aastast ei ole palju muutunud. Uuel tulijal on keeruline luua toimivat prototüüpi veebisaidi ja/või hoidla alusel.

Töödelt järeldusena tekkis mul mulje, et Zero Deployment töötab, kuid ainult süsteemitasemel. Umbes nii: BinaryObjectit kasutatakse, et õpetada kaugusõlmedel töötama kasutaja klassidega; Zero Deployment on Apache Ignite'i sisemine mehhanism ja levitab klastris süsteemi objekte.
Apache Ignite'i enda ja levitab klastris süsteemseid objekte.

Loodan, et minu kogemus on uutele Apache Ignite kasutajatele kasulik.

Allikas: habr.com