Apache Ignite Zero Deployment: er det virkelig Zero?

Vi er avdelingen for teknologisk utvikling av detaljhandelen. En gang satte ledelsen oss oppgaven med å akselerere stordata-beregninger ved å bruke Apache Ignite sammen med MSSQL, og viste oss en nettside med flotte illustrasjoner og eksempler på Java-kode. Jeg likte med én gang nettsiden, Zero Deployment, beskrivelsen av den lover underverker: du trenger ikke å manuelt distribuere Java- eller Scala-koden din på hver node i nettverket og reinstallere den hver gang den endrer seg. Underveis oppdaget jeg at Zero Deployment har spesifikke bruksområder, som jeg vil dele. Under katteinnlegget mine tanker og detaljer om implementeringen.

1. Oppgaveformulering

Kjernen i oppgaven er som følger. Det finnes en referanse for utsalgssteder SalesPoint og en referanse for varer Sku (Stock Keeping Unit). Utsalgsstedet har en attributt «butikkType» med verdiene «liten» og «stor». Hver utsalgssted kobles (lastes fra databasen) til et sortiment (listen over varer i utsalgsstedet) og tilbys informasjon om at den angitte varen
ekskluderes fra sortimentet eller legges til i sortimentet.

Det er nødvendig å organisere et partisjonert cache for utsalgssteder og lagre informasjon om tilkoblede varer i en måned fremover. Kompatibilitet med produksjonssystemet krever at klientnoden Ignite laster inn data, beregner aggregat av typen (butikkType, varekode, dag, antall_utsalgssteder) og laster det tilbake til databasen.

2. Studere litteratur

Det finnes ingen erfaring så langt, så jeg begynner å danse rundt ovnen. Det vil si med en oversikt over publikasjoner.

Artikkel fra 2016 Bli kjent med Apache Ignite: første skritt inneholder en lenke til dokumentasjonen for prosjektet Apache Ignite og en kritikk av uklarheten i denne dokumentasjonen. Jeg har lest den et par ganger, men klarhet har ikke kommet. Jeg henvender meg til den offisielle tutorialen getting-started, som
optimistisk lover 'Du vil være oppe og kjøre på et blunk!'. Jeg jobber med innstillingene for miljøvariabler, ser på to videoer om Apache Ignite Essentials, og de var ikke veldig nyttige for min spesifikke oppgave. Jeg klarer å starte Ignite fra kommandolinjen med standardfilen 'example-ignite.xml', og jeg lager min første applikasjon Compute Application med Maven. Applikasjonen fungerer og bruker Zero Deployment, så vakkert!

Jeg leser videre, og der er det et eksempel som umiddelbart bruker affinityKey (opprettet tidligere gjennom SQL-forespørsel), og i tillegg brukes det et mystisk BinaryObject:

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

Jeg leste litt немного: binærformat — noe som ligner på refleksjon, tilgang til feltene i et objekt ved navn. Kan lese verdien av et felt uten full deserialisering av objektet (minnebesparelse). Men hvorfor brukes BinaryObject i stedet for Person, når det finnes Zero Deployment? Hvorfor oversettes IgniteCache<Key,Person> til IgniteCache<BinaryObject, BinaryObject>? Foreløpig er det uklart.

Jeg tilpasser Compute Application til mitt tilfelle. Den primære nøkkelen til oppslagsrekken for salgssteder i MSSQL er definert som [id] [int] NOT NULL, jeg oppretter cache på lignende måte.

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

I xml-konfigurasjonen spesifiserer jeg at cachen er partisjonert.

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

Partisjonering basert på salgssteder forutsetter at det nødvendige aggregatet vil bli bygget på hver node i klyngen for de tilgjengelige postene i salesPointCache, etterfulgt av at klientnoden utfører den endelige summen.

Jeg leser en tutorial. First Ignite Compute Application, jeg gjør på samme måte. På hver node i klyngen kjører jeg IgniteRunnable(), omtrent slik:

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

Jeg legger til logikk for aggregering og eksport, kjører på et testsett med data. Lokalt på utviklingsserveren fungerer alt.

Jeg starter to testservere CentOs, angir IP-adressene i default-config.xml, utfører på hver.

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

Begge Ignite nodene starter og ser hverandre. Jeg angir nødvendige adresser i xml-konfigurasjonen av klientapplikasjonen, den starter, legger til en tredje node i topologien, og med en gang blir det igjen to noder. Loggen viser «ClassNotFoundException: model.SalesPoint» i linjen.

SalesPoint sp=salesPointCache.get(spId);

StackOverflow sier at årsaken til feilen er at den tilpassede klassen SalesPoint ikke finnes på serverne CentOs. Her er vi. Hvordan kan det være at «you don’t have to manually deploy your Java code on each node» og videre? Eller er «your Java code» ikke relatert til SalesPoint?

Sannsynligvis har jeg oversett noe — jeg begynner å lete, lese og lete igjen. Etter en stund får jeg følelsen av at jeg har lest alt om emnet, ingenting nytt er tilgjengelig. Mens jeg lette, fant jeg noen interessante observasjoner.

Valentin Kulichenko, Lead Architect at GridGain Systems, response på 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.

En annen autoritativ mening: Denis Magda, Director of product management, GridGain Systems.

Artikkel på Habr om mikrotjenester refererer til tre artikler av Denis Magda: Mikrotjenester Del I, Mikrotjenester Del II, Mikrotjenester Del III 2016-2017. I den andre artikkelen foreslår Denis å starte klyngenoden gjennom MaintenanceServiceNodeStartup.jar. Du kan også bruke oppstart med xml-konfigurasjon og kommandolinje, men da må du manuelt legge brukerklassene til hver distribuerte klyngenode:

Det er det. Start (..) noden ved å bruke MaintenanceServiceNodeStartup-filen eller pass maintenance-service-node-config.xml til Apache Ignites ignite.sh/bat-skript. Hvis du foretrekker det sistnevnte, må du sørge for å bygge en jar-fil som vil inneholde alle klassene fra java/app/common og java/services/maintenance-katalogene. Jar-filen må legges til klasseveien til hver node hvor tjenesten kan distribueres.

Faktisk, det er det. Her er han, denne mystiske binære formatet!

3. SingleJar

Denis tok førsteplassen i min personlige rangering, imo den mest nyttige tutorialen av alle tilgjengelige. I hans MicroServicesExample på GitHub finnes et komplett eksempel på hvordan man setter opp klyngenoder som kompilerer uten noen ekstra problemer.

Jeg følger mønsteret, og får en enkelt jar-fil som starter «data node» eller «client node» avhengig av kommandolinjeargumentet. Bygget fungerer og kjører. Zero Deployment er beseiret.

Overgangen fra megabyte med testdata til titalls gigabyte med produksjonsdata viste at det binære formatet eksisterer av en grunn. Det ble nødvendig å optimalisere minneforbruket på nodene, og her viste BinaryObject seg å være svært nyttig.

4. Konklusjoner

Den første kritikken jeg møtte angående uklart dokumentasjon på prosjektet Apache Ignite viste seg å være berettiget; siden 2016 har det vært lite som har endret seg. Det er ikke enkelt for nybegynnere å sette sammen en fungerende prototype basert på nettstedet og/eller depotet.

Etter det utførte arbeidet fikk jeg inntrykk av at Zero Deployment fungerer, men bare på systemnivå. Omtrent slik: BinaryObject brukes for å lære fjerntliggende klynge noder å jobbe med brukerklasser; Zero Deployment er en intern mekanisme
til selve Apache Ignite og sprer systemobjektene over klyngen.

Jeg håper at min erfaring vil være nyttig for nye brukere av Apache Ignite.

Kilde: habr.com