🥇Apache Ignite Zero Deployment: vai tiešām nulle?

Mēs esam tehnoloģiju attīstības nodaļa mazumtirdzniecības tīklā. Reiz vadība uzdeva uzdevumu paātrināt apjomīgu aprēķinu veikšanu, izmantojot Apache Ignite kopā ar MSSQL, un parādīja vietni ar lieliskām ilustrācijām un Java koda piemēriem. Vietne uzreiz iepatikās. Zero Deployment, kuras apraksts solīja brīnumus: you don’t have to manually deploy your Java or Scala code on each node in the grid and re-deploy it each time it changes. Strādājot, izrādījās, ka Zero Deployment ir izmantošanas specifika, ar kuras īpatnībām es vēlos dalīties. Zemāk ir pārdomas un īstenošanas detaļas.

1. Uzdevuma izvirzīšana

Uzdevuma būtība ir šāda. Pastāv tirdzniecības punktu katalogs SalesPoint un preču katalogs Sku (Stock Keeping Unit). Tirdzniecības punkts ir piešķirts atribūts „veikala tips” ar vērtībām „mazs” un „liels”. Katrai tirdzniecības punktam tiek piekļūts (ielādēts no DB) sortiments (preču saraksts tirdzniecības punktā) un sniegta informācija par to, ka no noteiktās datuma attiecīgā prece
tiek izslēgta no sortimenta vai pievienota sortimentam.

Ir nepieciešams organizēt partionētu tirdzniecības punktu kešu un glabāt tajā informāciju par pieslēgtajām precēm uz mēnesi uz priekšu. Saderība ar ražošanas sistēmu prasa, lai klienta mezglam Ignite tiktu ielādēti dati, aprēķināts agregāts veidā (veikala tips, preces kods, diena, tirdzniecības punktu skaits) un izsūtīts atpakaļ uz DB.

2. Literatūras izpēte

Pieredzes pagaidām nav, tāpēc sāku dejot no krāsns. Tātad, ar publicēto materiālu pārskatu.

Raksts no 2016. gada Iepazīšanās ar Apache Ignite: pirmie soļi ietver saiti uz Apache Ignite projekta dokumentāciju un tāpat norāda uz šīs dokumentācijas neskaidrību. Pārlasīju dažas reizes, skaidrība nenonāk. Vēršos pie oficiālā tutesā getting-started, kas
optimistiski sola „You’ll be up and running in a jiffy!”. Izpētu vides mainīgo iestatījumus, skatos divus video par Apache Ignite Essentials, tie manai konkrētai uzdevumam izbāzti izrādījās ne pārāk noderīgi. Veiksmīgi palaidu Ignite no komandrindas ar standarta failu „example-ignite.xml”, sagatavoju pirmo lietotni Compute Application izmantojot Maven. Lietotne strādā un izmanto Zero Deployment, cik skaisti!

Lasu tālāk, un tur piemērs uzreiz izmanto affinityKey (izveidots iepriekš ar SQL pieprasījumu), un tiek pielietots noslēpumainais BinaryObject:

IgniteCache<BinaryObject, BinaryObject> cilvēki 
        = ignite.cache("Person").withKeepBinary();

Izlasīju mazliet: binārais formāts — kaut kas līdzīgs refleksijai, piekļuve objekta laukiem pēc nosaukuma. Var lasīt lauka vērtību bez pilnīgas objekta deserializācijas (atmiņas taupīšana). Bet kāpēc vietā Person tiek izmantots BinaryObject, ja ir Zero Deployment? Kāpēc IgniteCache<Key,Person> tiek tulkots kā IgniteCache<BinaryObject, BinaryObject>? Kamēr nav skaidrs.

Pārbūvēju Compute Application pēc savām vajadzībām. Primārais atslēgas punkts pārdošanas vietu katalogā MSSQL ir definēts kā [id] [int] NOT NULL, veidoju kešu pēc analoģijas.

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

XML konfigurācijā norādu, ka kešs ir partizēts.

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

Partizēšana pēc pārdošanas vietām paredz, ka nepieciešamais agregāts tiks veidots katrā klastera mezglā attiecībā uz tur esošajiem ierakstiem salesPointCache, pēc tam klients izpildīs galīgo summēšanu.

Lasu pamācību. First Ignite Compute Application, daru pēc analoģijas. Katram klastera mezglam palaižu IgniteRunnable(), aptuveni šādi:

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

Pievienoju agregācijas un eksportēšanas loģiku, palaižu uz testēšanas datu kopas. Vietējā izstrādes serverī viss strādā.

Palaidu divus testēšanas serverus CentOs, norādu IP adreses default-config.xml, izpildīšu katram.

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

Abi Ignite mezgli tiek palaisti un redz viens otru. Norādu vajadzīgās adreses XML konfigurācijā klienta lietotnē, tā tiek palaista, pievieno trešo mezglu topoloģijai un tūlīt kļūst divi mezgli. Žurnālā ir ieraksts «ClassNotFoundException: model.SalesPoint» rindā.

SalesPoint sp=salesPointCache.get(spId);

StackOverflow saka, ka kļūdas cēlonis — CentOs serveros nav lietotāju klases SalesPoint. Esam nonākuši līdz galam. Kā tad ar «you don’t have to manually deploy your Java code on each node» un turpinājumā? Vai «your Java code» nav par SalesPoint?

Iespējams, ka kaut ko esmu palaidis garām — atkal sākšu meklēt, lasīt un atkal meklēt. Pēc laika rodas sajūta, ka esmu izlasījis visu par šo tēmu, nekā jauna vairs nav. Kamēr meklēju, atradu dažas interesantas piezīmes.

Valentin Kulichenko, vadītājs arhitektūras jomā GridGain Systems, atbildi StackOverflow, 2016. gada aprīlis:

Modelu klases netiek izvietotas, bet jūs varat izmantot arKeepBinary() karogu
uz keša un vaicāt BinaryObjects. Šādā veidā jūs izvairīsieties no deserializācijas
servera pusē un neradīsiet ClassNotFoundException.

Vēl viena autoritatīva domas izteikšana: Denis Magda, produktu pārvaldības direktors, GridGain Systems.

Raksts Habrā par mikroservisiem atsaucas uz trim rakstiem Denis Magda: Mikrosistēmas I daļa, Mikrosistēmas II daļa, Mikrosistēmas III daļa 2016.-2017. gads. Otrajā rakstā Denis piedāvā uzsākt klastera mezglu, izmantojot MaintenanceServiceNodeStartup.jar. Var izmantot arī palaišanu ar xml konfigurāciju un komandlīniju, taču šādā gadījumā ir nepieciešams manuāli ievietot lietotāju klases katram izvietotajam klastera mezglam:

Tas ir viss. Sāciet (..) mezglu, izmantojot MaintenanceServiceNodeStartup failu vai pārsūtiet maintenance-service-node-config.xml uz Apache Ignite's ignite.sh/bat skriptiem. Ja izvēlaties otro variantu, tad pārliecinieties, ka izveidojat jar failu, kas saturēs visas klases no java/app/common un java/services/maintenance direktorijām. Jar ir jāpievieno katra mezgla klases ceļam, kur pakalpojums varētu tikt izvietots.

Patiesībā, tas ir viss. Lūk, kāpēc šis noslēpumainais binārais formāts!

3. SingleJar

Denis manā personīgajā reitingā ieņem pirmo vietu, manuprāt, tas ir visnoderīgākais pamācību avots no visiem pieejamajiem. Tā ir viņa MicroServicesExample GitHub satur pilnībā izstrādātu klastera mezglu konfigurācijas piemēru, kas tiek kompilēts bez visādām liekām grūtībām.

Es daru pēc parauga un saņemu vienotu jar failu, kas palaida "data node" vai "client node" atkarībā no komandlīnijas argumenta. Izstrāde tiek uzsākta un strādā. Zero Deployment ir uzvarēts.

Pāreja no megabaitu testa datiem uz desmitiem gigabaitu kaujas datu pierādīja, ka binārais formāts ir pamatots. Bija nepieciešams optimizēt atmiņas patēriņu mezglos, un šeit BinaryObject izrādījās ļoti noderīgs.

4. Secinājumi

Pirmais izteiktais pārmetums par projekta Apache Ignite dokumentācijas neskaidrību izrādījās pamatots, kopš 2016. gada ir mainījies maz. Iesācējam ir grūti izveidot funkcionējošu prototipu, balstoties uz vietni un/vai repozitoriju.

Pēc paveiktā darba secināts, ka Zero Deployment darbojas, bet tikai sistēmas līmenī. Aptuveni tā: BinaryObject tiek izmantots, lai apmācītu attālinātos klastera mezglus strādāt ar lietotāju klasēm; Zero Deployment ir iekšējais mehānisms
pašam Apache Ignite un izplata pa klasteri sistēmas objektus.

Ceru, ka mans pieredze būs noderīga jaunajiem Apache Ignite lietotājiem.

Avots: habr.com