Apache Ignite Zero -käyttöönotto: todella nolla?

Olemme vähittäiskauppaverkoston teknologiakehitysosasto. Eräänä päivänä johto asetti tehtäväksi nopeuttaa laajamittaisia ​​laskelmia käyttämällä Apache Ignitea yhdessä MSSQL:n kanssa ja näytti verkkosivuston, jossa oli kauniita kuvia ja esimerkkejä Java-koodista. Pidin heti sivustosta Nolla käyttöönottoa, jonka kuvaus lupaa ihmeitä: sinun ei tarvitse ottaa Java- tai Scala-koodia manuaalisesti käyttöön jokaisessa ruudukon solmussa ja ottaa sitä uudelleen käyttöön aina, kun se muuttuu. Työn edetessä kävi ilmi, että Zero Deploymentilla on erityisiä käyttötarkoituksia, joiden ominaisuudet haluan jakaa. Leikkauksen alla on ajatuksia ja toteutustietoja.

1. Ongelman kuvaus

Ongelman ydin on seuraava. Siellä on SalesPoint-myyntipistehakemisto ja Sku (Stock Keeping Unit) -tuotehakemisto. Myyntipisteessä on "Store type" -attribuutti, jonka arvot ovat "small" ja "large". Jokaiseen myyntipisteeseen liitetään valikoima (myyntipisteen tuoteluettelo) (ladattuna DBMS:stä) ja tiedotetaan, että ilmoitetusta päivästä alkaen määritetty tuote
jätetään pois valikoimasta tai lisätään valikoimaan.

On järjestettävä osioitu myyntipisteiden välimuisti ja tallennettava siihen tiedot yhdistetyistä tuotteista kuukausi etukäteen. Yhteensopivuus taistelujärjestelmän kanssa edellyttää, että Ignite-asiakassolmu lataa tiedot, laskee lomakkeen aggregaatin (myymälätyyppi, tuotekoodi, päivä, myyntipisteiden_määrä) ja lataa sen takaisin DBMS:ään.

2. Kirjallisuuden opiskelu

Minulla ei ole vielä kokemusta, joten aloin tanssimaan liedeltä. Eli julkaisujen katsauksesta.

Artikla 2016 Esittelyssä Apache Ignite: Ensimmäiset askeleet sisältää linkin Apache Ignite -projektin dokumentaatioon ja samalla moitteen tämän dokumentaation epämääräisyydestä. Luin sen pari kertaa uudestaan, selkeyttä ei tule. Viittaan viralliseen opetusohjelmaan päästä alkuunJoka
lupaa optimistisesti "Pääset toimimaan hetkessä!" Selvittelen ympäristömuuttujan asetuksia, katson kahta Apache Ignite Essentials -videota, mutta niistä ei ollut erityistä hyötyä erityistehtävässäni. Käynnistän Igniten onnistuneesti komentoriviltä tavallisella tiedostolla "example-ignite.xml" rakentaen ensimmäisen sovelluksen Laske sovellus käyttämällä Mavenia. Sovellus toimii ja käyttää Zero Deploymentia, mikä kauneus!

Luin edelleen, ja siellä esimerkki käyttää välittömästi affinityKey-koodia (joka luotiin aiemmin SQL-kyselyllä) ja jopa salaperäistä BinaryObjectia:

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

lukea немного: binäärimuoto - jotain heijastuksen kaltaista, objektin kenttiin pääsyä nimellä. Pystyy lukemaan kentän arvon sarjoittamatta objektia kokonaan (muistia säästämättä). Mutta miksi BinaryObjectia käytetään henkilön sijasta, koska siellä on Zero Deployment? Miksi IgniteCache siirretty IgniteCacheen ? Asia ei ole vielä selvä.

Teen Compute Application -sovelluksen uudelleen tapaukseni mukaan. MSSQL:n myyntipistehakemiston ensisijainen avain on määritelty muodossa [id] [int] EI NULL, luon välimuistin analogisesti

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

Ilmoitan xml-kokoonpanossa, että välimuisti on osioitu

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

Osiointi myyntipisteen mukaan olettaa, että vaadittu aggregaatti rakennetaan jokaiseen klusterisolmuun siellä saatavilla oleville salesPointCache-tietueille, minkä jälkeen asiakassolmu suorittaa lopullisen summauksen.

Luen opetusohjelmaa Ensimmäinen Ignite Compute -sovellus, teen sen analogisesti. Suoritan jokaisessa klusterin solmussa IgniteRunnable(), jotain tällaista:

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

Lisään yhdistämis- ja latauslogiikan ja suoritan sen testitietojoukossa. Kaikki toimii paikallisesti kehityspalvelimella.

Käynnistän kaksi CentOs-testipalvelinta, määritän IP-osoitteet default-config.xml:ssä ja suoritan kummallakin

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

Molemmat Ignite-solmut ovat käynnissä ja näkevät toisensa. Määritän tarvittavat osoitteet asiakassovelluksen xml-konfiguraatiossa, se käynnistyy, lisää topologiaan kolmannen solmun ja heti on taas kaksi solmua. Lokin rivillä näkyy "ClassNotFoundException: model.SalesPoint".

SalesPoint sp=salesPointCache.get(spId);

StackOverflow kertoo, että syynä virheeseen on se, että CentOs-palvelimilla ei ole mukautettua SalesPoint-luokkaa. Olemme saapuneet. Entä "sinun ei tarvitse ottaa Java-koodia manuaalisesti käyttöön jokaisessa solmussa" ja niin edelleen? Vai eikö "oma Java-koodisi" koske SalesPointia?

Luultavasti missasin jotain – aloin etsimään uudelleen, lukemaan ja etsimään uudelleen. Hetken kuluttua minusta tulee tunne, että olen lukenut kaiken aiheesta, ei ole enää mitään uutta. Etsiessäni löysin mielenkiintoisia kommentteja.

Valentin Kulichenko, johtava arkkitehti GridGain Systemsissä, vastata StackOverflow, huhtikuu 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.

Toinen arvovaltainen mielipide: Denis Magda, tuotehallinnan johtaja, GridGain Systems.

Artikkeli Habresta mikropalveluista viittaa kolmeen Denis Magdan artikkeliin: Mikropalvelut osa I, Mikropalvelut osa II, Mikropalvelut osa III 2016-2017. Toisessa artikkelissa Denis ehdottaa klusterisolmun käynnistämistä MaintenanceServiceNodeStartup.jar-tiedoston kautta. Voit myös käyttää käynnistystä xml-kokoonpanon ja komentorivin kanssa, mutta sitten sinun on asetettava mukautetut luokat manuaalisesti jokaiseen käyttöön otettuun klusterin solmuun:

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.

Todellakin, siinä se. Tässä käy ilmi, miksi tämä salaperäinen binäärimuoto!

3.SingleJar

Denis sijoittui henkilökohtaisessa luokituksessani ensimmäiseksi, IMHO oli hyödyllisin opetusohjelma kaikista saatavilla olevista. Hänen MicroServicesEsimerkki Github sisältää täysin valmiin esimerkin klusterisolmujen asettamisesta, joka käännetään ilman ylimääräistä squattia.

Teen sen samalla tavalla ja saan yhden jar-tiedoston, joka käynnistää "data node" tai "client node" komentorivin argumentista riippuen. Kokoonpano alkaa ja toimii. Zero Deployment on voitettu.

Siirtyminen megatavuista testidataa kymmeniin gigatavuihin taistelutietoihin osoitti, että binäärimuoto on olemassa syystä. Oli tarpeen optimoida muistin kulutus solmuissa, ja tässä BinaryObject osoittautui erittäin hyödylliseksi.

4. Päätelmät

Ensimmäinen moite Apache Ignite -projektidokumentaation epämääräisyydestä osoittautui oikeudenmukaiseksi, ei juurikaan ole muuttunut vuoden 2016 jälkeen. Aloittelijan ei ole helppoa koota toimivaa prototyyppiä verkkosivuston ja/tai arkiston perusteella.

Tehdyn työn tulosten perusteella vaikutelma, että Zero Deployment toimii, mutta vain järjestelmätasolla. Jotain tällaista: BinaryObjectiä käytetään opettamaan etäklusterisolmuja toimimaan mukautettujen luokkien kanssa; Zero Deployment - sisäinen mekanismi
Apache Ignite itse ja jakaa järjestelmäobjektit koko klusteriin.

Toivon, että kokemukseni on hyödyllinen uusille Apache Ignite -käyttäjille.

Lähde: will.com