Apache Ignite Zero Deployment: tõesti Zero?

Me oleme jaemüügitehnoloogia arenduse osakond. Ühel päeval andis juhtkond ülesande kiirendada ulatuslikke arvutusi, kasutades Apache Ignite'i koos MSSQL-iga, ja näitas veebilehte suurepäraste illustreerimise ja Java koodinäidistega. Veebileht meeldis mulle kohe. Zero Deployment, mille kirjeldus lubab imesid: sa ei pea oma Java või Scala koodi iga võrgu sõlme käsitsi rakendama ja seda uuesti rakendama igal korral, kui see muutub. Töö käigus selgus, et Zero Deployment’il on oma kasutusspetsiifika, millega soovin jagada. Alustuseks mõtted ja teostuse üksikasjad.

1. Probleemi püstitamine

Probleemi sisu on järgmine. On olemas müügikohtade register SalesPoint ja kaupade register Sku (Stock Keeping Unit). Müügikohas on atribuut „tyüpMaja” väärtustega „väike” ja „suur”. Iga müügikohaga on ühendatud (laaditakse andmebaasist) kaubavalik (müügikoha kaupade loetelu) ja edastatakse teave, et alates määratud kuupäevast tuleb määratud kaup
välja jätta kaubavalikust või lisada kaubavalikusse.

On vajalik korraldada müügikohtade partitsioneeritud vahemälu ja hoida selles teavet ühendatud kaupade kohta kuu ette. Ühilduvus tootmissüsteemiga nõuab klientühenduse Ignite kirje laadimist, andmete arvutamist agregaatide tüübi (tyüpMaja, kauba kood, päev, müügikohtade arv) järgi ja selle väljastamist tagasi andmebaasi.

2. Kirjanduse uurimine

Kogemus puudub, seega hakkan alt üles minema. Ehkki alustan publikatsioonide ülevaate tegemisest.

2016. aasta artikkel Tutvumine Apache Ignite'iga: esimesed sammud sisaldab viidet Apache Ignite projekti dokumentatsioonile ja samas ka kriitikat selle dokumentatsiooni segasuse kohta. Lugesin mitu korda, selgus ei tule. Jätan tähelepanu ametlikule õpetusele getting-started, mis
optimistlikult lubab, et "Sa saad kiiresti hakkama!". Teen keskkonnamuutujate seadistustega tutvust, vaatan kahte videot Apache Ignite Essentials, mis osutusid minu konkreetse ülesande jaoks mitte eriti kasulikuks. Käivitan Ignite'i edukalt käsurealt standardfailiga "example-ignite.xml", kogun esimese rakenduse Compute Application Maveniga. Rakendus töötab ja kasutab Zero Deployment'i, milline ilu!

Lugesin edasi, seal oli näide, mis juba kasutas affinityKey (loodi varem SQL-päringu kaudu), ja sealjuures kummaline BinaryObject:

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

Lugesin edasi veidi: binaarne formaat — midagi sellist nagu refleksioon, juurdepääs objekti väljadele nime järgi. Saab lugeda välja väljade väärtusi täielikku objekti deserialiseerimist tegemata (mäluefektiivsus). Kuid miks kasutatakse Person'i asemel BinaryObject, kui on olemas Zero Deployment? Miks IgniteCache<Key,Person> tõlgitakse IgniteCache<BinaryObject, BinaryObject>? Praegu pole selge.

Muudan Compute Application'i enda juhtumi jaoks. Müügipunktide registri põhivõti MSSQL-is on määratud kui [id] [int] NOT NULL, loon sarnase caching.

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

XML-konfiguratsioonis määran, et cache on jaotatud.

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

Jaotamine müügipunktide järgi tähendab, et vajalik aggregaat koostatakse igas klastris, kus on olemas salesPointCache kirjed, seejärel täidab kliendi sõlme lõpliku summeerimise.

Lugesin õpetust. Esimene Ignite Compute Application., teen sarnaselt. Igal klastrisõlmel käivitan IgniteRunnable(), enam-vähem selliselt:

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

Lisaan kogumise ja eksportimise logika, käivitan testkomplekti andmetega. Kohalikult arendusserveris töötab kõik.

Käitan kaks testserverit CentOs, määran IP-aadressid default-config.xml-is, täidan igas:

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

Mõlemad Ignite sõlmed käivituvad ja näevad üksteist. Määran vajalikud aadressid klientrakenduse XML-konfiguratsioonis, see käivitub, lisab kolmanda sõlme topoloogiasse ja kohe on sõlmi taas kaks. Logis on kirjas „ClassNotFoundException: model.SalesPoint” reas.

SalesPoint sp=salesPointCache.get(spId);

StackOverflow ütleb, et vea põhjus on see, et CentOs serverites pole kasutaja klassi SalesPoint. Sõime. Kuidas on võimalik, et „you don’t have to manually deploy your Java code on each node” ja edasi? Või „your Java code” — see ei kehti SalesPoint'i kohta?

Tõenäoliselt olen midagi unustanud — hakkan taas otsima, lugema ja taas otsima. Aja jooksul tekib tunne, et olen teema kohta kõik juba läbi lugenud, midagi uut pole. Otsides leidsin mõned huvitavad märkused.

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

Mudelklassid ei ole omavahel juurutatud, kuid saab kasutada keepBinary() lipu
cache'is ja küsida BinaryObjects. Sel viisil väldid deserialiseerimist
serveripoolel ja ei saa ClassNotFoundException'i.

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

Artikkel Habr mikroteenuste kohta viitab kolmele artiklile Denis Magda: Mikroteenused Osa I, Mikroteenused Osa II, Mikroteenused Osa III 2016-2017. Teises artiklis pakub Denis algatada klastrisõlme kaudu MaintenanceServiceNodeStartup.jar. Võib kasutada ka käivitamist xml-konfiguratsiooni ja käsureaga, kuid siis tuleb igas klastrisõlmes iseseisvalt paigutada kasutajaklassid:

See ongi kõik. Käivita (..) sõlm, kasutades MaintenanceServiceNodeStartup faili või edasta
maintenance-service-node-config.xml Apache Ignite'i ignite.sh/bat skriptidele.
Kui eelistad viimast, siis veendu, et lood jar-faili, mis sisaldab
kõiki klasse java/app/common ja java/services/maintenance kataloogidest.
Jar peab olema lisatud iga sõlme klassiteele, kuhu teenus
võib olla paigaldatud.

Tõepoolest, see ongi kõik. Näe, tundub, et just selleks on olemas see salapärane binaarformaat!

3. SingleJar

Denis kaasas minu isiklikus edetabelis esimese koha, minu arvates on see kõige kasulikum õpetus kõigist saadaolevatest. MicroServicesExample on GitHubis täielikult valmis klastrisõlmede seadistamise näidis, mis kompileerub ilma igasuguste lisategevusteta.

Teen kopeerides ja modifitseerides, saan ühe jar-faili, mis käivitab "data node" või "client node" sõltuvalt käskluse argumendist. Kogumine käivitub ja töötab. Zero Deployment on võidetud.

Üleminek megabaidist testandmetest kümnete gigabaidini tootmisnäitas, et binaarformaadi olemasolu on põhjendatud. Pidi optimeerima mälu kasutust sõlmedes ja siin osutus BinaryObject väga kasulikuks.

4. Järeldused

Esimene koht, kus projekt Apache Ignite'i dokumentatsiooni ebatäpsuse kohta kriitika osutus õigeks, on alates 2016. aastast vähe muutunud. Algajale on keeruline tööle panna toimivat prototüüpi saidi ja/või hoidla põhjal.

Kogu tehtud töö tulemusena tekkis vaade, et Zero Deployment töötab, kuid ainult süsteemi tasandil. Umbes nii: BinaryObject'i kasutatakse, et õpetada kaugklastrisõlmi töötama kasutajaklassidega; Zero Deployment on Apache Ignite'i sisemine mehhanism
ja levitab klastris süsteemseid objekte.

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

Allikas: habr.com