Apache Ignite Zero Deployment: verkligen Zero?

Vi är en avdelning för teknikutveckling av detaljhandeln. En gång satte ledningen en uppgift att snabba upp storskaliga beräkningar genom att använda Apache Ignite i samband med MSSQL, och visade en webbplats med fantastiska illustrationer och exempel på Java-kod. Jag gillade genast webbplatsen. Zero Deployment, vars beskrivning lovar underverk: du behöver inte manuellt distribuera din Java- eller Scala-kod på varje nod i nätverket och återskapa det varje gång det ändras. Under arbetets gång visade det sig att Zero Deployment har sina egna användningsspecifikationer, som jag vill dela med mig av. Här är mina tankar och detaljer om implementeringen.

1. Problemformulering

Kärnan i uppgiften är följande. Det finns en katalog över försäljningspunkter SalesPoint och en katalog över varor Sku (Stock Keeping Unit). Varje försäljningspunkt har en attribut "butikstyp" med värdena "liten" och "stor". Till varje försäljningspunkt ansluts (laddas från databas) ett sortiment (lista över varor i försäljningspunkten) och information lämnas om att den angivna varan
antingen tas bort från sortimentet eller läggs till i sortimentet.

Det krävs att organisera en partitionerad cache för försäljningspunkter och lagra information om anslutna varor en månad framåt. Kompatibilitet med produktsystemet kräver att klientnoden Ignite laddar data, beräknar aggregatet av typen (butikstyp, varukod, dag, antal försäljningspunkter) och laddar tillbaka den till databasen.

2. Litteraturstudie

Eftersom det ännu inte finns någon erfarenhet, börjar jag med att göra en översikt av publikationerna.

En artikel från 2016 Introduktion till Apache Ignite: första stegen innehåller en länk till dokumentationen för Apache Ignite-projektet och samtidigt en anklagelse om den otydlighet som finns i denna dokumentation. Jag läste igenom den ett par gånger, men förståelsen kommer inte. Jag vänder mig till den officiella handledningen getting-started, som
som optimistiskt lovar "Du kommer snabbt att vara igång!". Jag går igenom inställningarna för miljövariabler, tittar på två videor om Apache Ignite Essentials, som visade sig vara inte så användbara för min specifika uppgift. Jag startar Ignite från kommandoraden med standardfilen "example-ignite.xml", och bygger min första applikation Compute Application med hjälp av Maven. Applikationen fungerar och använder Zero Deployment, vilken skönhet!

Jag läser vidare, och där använder exemplet direkt affinityKey (skapad tidigare via en SQL-fråga), och dessutom tillämpas det mystiska BinaryObject:

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

Jag läste utanför de säkra parametrarna.: binärt format – något i stil med reflektion, åtkomst till objektfält efter namn. Kan läsa fältvärdet utan full deserialisering av objektet (minnesbesparing). Men varför används BinaryObject istället för Person, när det finns Zero Deployment? Varför översätts IgniteCache till IgniteCache? Än så länge oklart.

Jag anpassar Compute Application efter mitt fall. Primärnyckeln för försäljningsställen i MSSQL är definierad som [id] [int] NOT NULL, jag skapar en cache på liknande sätt.

IgniteCache salesPointCache = ignite.cache("spCache")

I xml-konfigurationen anger jag att cachen är partitionerad

Partitionering efter försäljningsställen innebär att den nödvändiga aggregaten kommer att byggas på varje nod i klustret för de upptagna posterna i salesPointCache, varefter klientnoden utför den slutgiltiga summeringen.

Jag läser en tutorial Första Ignite Compute Application, jag gör på liknande sätt. På varje nod i klustret startar jag IgniteRunnable(), ungefär så här:

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

Jag lägger till logik för aggregering och export, kör på en testdatamängd. Lokalt på utvecklingsservern fungerar allt.

Jag startar två testservrar CentOs, anger ip-adresser i default-config.xml, kör på varje

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

Båda Ignite-noderna startar och ser varandra. Jag anger de nödvändiga adresserna i xml-konfigurationen för klientapplikationen, den startar, lägger till en tredje nod i topologin och genast blir antalet noder återigen två. I loggen står "ClassNotFoundException: model.SalesPoint" på raden

SalesPoint sp = salesPointCache.get(spId);

StackOverflow säger att orsaken till felet är att det saknas anpassad klass SalesPoint på CentOs-servrarna. Det är illa. Hur är det med "you don’t have to manually deploy your Java code on each node" och så vidare? Eller är "your Java code" inte om SalesPoint?

Antagligen har jag missat något - börjar leta, läsa och leta igen. Efter en stund får jag känslan av att jag har läst allt om ämnet, inget nytt kvar. Medan jag sökte hittade jag några intressanta observationer.

Valentin Kulichenko, Lead Architect at GridGain Systems, svar på StackOverflow, april 2016:

Modellklasser är inte peer-deployade, men du kan använda withKeepBinary() flaggan på cachen och fråga BinaryObjects. På så sätt undviker du deserialisering på serversidan och får inte ClassNotFoundException.

Ytterligare en auktoritativ åsikt: Denis Magda, Director of product management, GridGain Systems.

Artikel på Habré om mikrotjänster refererar till tre artiklar av Denis Magda: Mikrotjänster Del I, Mikrotjänster Del II, Mikrotjänster Del III 2016-2017. I den andra artikeln föreslår Denis att starta en klusterknut via MaintenanceServiceNodeStartup.jar. Du kan också använda en start med xml-konfiguration och kommandoraden, men då måste du manuellt placera användarklasser på varje distribuerad klusterknut:

Det är allt. Starta (..) knuten med MaintenanceServiceNodeStartup-filen eller skicka
maintenance-service-node-config.xml till Apache Ignites ignite.sh/bat-skript.
Om du föredrar det senare, se till att bygga en jar-fil som kommer att innehålla
alla klasser från java/app/common och java/services/maintenance katalogerna.
Jar-filen måste läggas till classpathen för varje knut där tjänsten
kan distribueras.

Verkligen, det är allt. Här är han, faktiskt, varför, detta mystiska binära format!

3. SingleJar

Denis kom på första plats i min personliga ranking, imo den mest användbara handledningen av alla tillgängliga. I hans MicroServicesExample på GitHub finns det ett helt färdigt exempel på hur man konfigurerar klusterknutorna, vilket kompileras utan några extra krusiduller.

Jag gör efter mönstret och får en enda jar-fil som startar 'data node' eller 'client node' beroende på kommandoradsargumentet. Bygget startar och fungerar. Zero Deployment är besegrat.

Övergången från megabyte testdata till tiotals gigabyte produktionsdata visade att det binära formatet finns där av en anledning. Det krävdes att optimera minnesanvändningen på noderna, och här visade sig BinaryObject vara mycket användbart.

4. Slutsatser

Den första kritiken jag mötte om otydlighet i dokumentationen för Apache Ignite-projektet visade sig vara berättigad, sedan 2016 har det ändrats lite. Det är inte lätt för en nybörjare att samla en fungerande prototyp baserat på webbplatsen och/eller arkivet.

Som en slutsats av det utförda arbetet fick jag intrycket att Zero Deployment fungerar, men endast på systemnivå. Ungefär så: BinaryObject används för att lära avlägsna klusterknutar att arbeta med användarklasser; Zero Deployment är en intern mekanism
för Apache Ignite själv och sprider systemobjekt över klustret.

Jag hoppas att min erfarenhet blir användbar för nya användare av Apache Ignite.

Källa: habr.com