🥇Apache Ignite Zero Deployment: për të vërtetë Zero?

Ne jemi departamenti i zhvillimit të teknologjisë së rrjetit me pakicë. Njëherë, drejtuesit vendosën një detyrë për të përshpejtuar llogaritjet voluminoze duke përdorur Apache Ignite në lidhje me MSSQL, dhe treguan një faqe me ilustrime të shkëlqyera dhe shembuj të kodit Java. Në faqen e internetit më pëlqeu menjëherë Zero Deployment, një përshkrim i të cilit premton mrekulli: nuk duhet të bëni manualisht vendosjen e kodit tuaj Java ose Scala në çdo nyje në rrjet dhe ta rinstaloni atë çdo herë që ndryshon. Gjatë punës, doli se Zero Deployment ka specifika përdorimi, për të cilat dua të ndajoj mendimet e mia. Më poshtë janë refleksionet dhe detajet e realizimit.

1. Vendosja e detyrës

Qëllimi i detyrës është si më poshtë. Ka një regjistër prej pikash shitjeje SalesPoint dhe një regjistër të produkteve Sku (Stock Keeping Unit). Pika e shitjes ka një atribut 'tipi i dyqanit' me vlere 'i vogël' dhe 'i madh'. Çdo pikë e shitjes lidhet (për nga ngarkesa nga baza e të dhënave) me një asortiment (listë produktesh të pikës së shitjes) dhe merret informacioni se që nga data e caktuar, produkti i caktuar
ekskludohet nga asortimenti ose shtohet në asortiment.

Duhet të organizohet një cache e ndarë për pikat e shitjes dhe të ruhet informacioni mbi produktet e lidhura për një muaj përpara. Kompatibiliteti me sistemin operativ kërkon që nyja klientike Ignite të ngarkojë të dhënat, të llogaritë agregatin e tipit (tipi i dyqanit, kodi i produktit, dita, numri i pikave të shitjes) dhe ta shokëzojë atë prapë në bazën e të dhënave.

2. Studimi i literaturës

Përvoja deri tani nuk kam, kështu që filloj të punoj nga baza. Domethënë, me një përmbledhje publikimesh.

Artikulli i vitit 2016 Njoftimi me Apache Ignite: hapat e parë përmban një lidhje me dokumentacionin e projektit Apache Ignite dhe gjithashtu një kritikë ndaj paqartësisë së këtij dokumentacioni. E lexova disa herë, nuk e kam qartësinë. Po e drejtoj vëmendjen time në tutorialin zyrtar getting-started, i cili
premton optimistisht 'Do të jeni gati në një çast!'. Po merrem me konfigurimin e variablave të mjedisit, shikoj dy video mbi thelbin e Apache Ignite, për problemin tim të veçantë ato nuk ishin shumë të dobishme. Duke e стартуар Igniten nga linja e komandës duke përdorur skedarin standard 'example-ignite.xml', devizoj aplikacionin e parë Compute Application me Maven. Aplikacioni punon dhe përdor Zero Deployment, çfarë bukurie!

Lexoj më tej, dhe aty shembulli menjëherë përdor affinityKey (krijuar më parë përmes një SQL-query), duke aplikuar gjithashtu një BinaryObject misterioz:

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

Lexova pakëz: formati binar - diçka si refleksion, qasje në fushat e objektit sipas emrit. Mund të lexojë vlerën e fushës pa deserializimin e plotë të objektit (kursim memorjeje). Por pse përdoret BinaryObject në vend të Person, kur ekziston Zero Deployment? Pse IgniteCache<Key,Person> përkthehet në IgniteCache<BinaryObject, BinaryObject>? Ende nuk është e qartë.

Po rregulloj aplikacionin Compute për rastin tim. Çelësi primar i regjistrit të pikave të shitjes në MSSQL është përcaktuar si [id] [int] NOT NULL, po krijoj cache sipas një modeli të ngjashëm

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

Në konfigurimin xml, specifikoj se cache është i ndarë

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

Për ndarjen sipas pikave të shitjes, supozohet se agregati i nevojshëm do të ndërtuar në çdo nyje të klasterit për regjistrat e disponueshëm në salesPointCache, pas së cilës nyja klient do të kryejë shënimin përfundimtar.

Po lexoj një tutoriel Aplikacioni i Parë i Llogaritjes në Ignite, po bëj sipas një modeli të ngjashëm. Në çdo nyje të klasterit filloj IgniteRunnable(), diçka si kjo:

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

Po shtoj logjikën e agregatës dhe eksportit, po e provoja me një grup të dhënash testuese. Lokal në serverin e zhvillimit, gjithçka funksionon.

Po ekzekutoj dy servera testues CentOs, specifikoj adresat ip në default-config.xml, e realizoj në secilin

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

Të dy nyjat Ignite fillojnë dhe shohin njëra-tjetrën. Specifikoj adresat e nevojshme në konfigurimin xml të aplikacionit klient, ai fillon, shton një nyjë të tretë në topologji dhe menjëherë numri i nyjeve bëhet përsëri dy. Në log shënohet 'ClassNotFoundException: model.SalesPoint' në linjën

SalesPoint sp=salesPointCache.get(spId);

StackOverflow thotë se arsyeja e gabimit është se në serverat CentOs nuk ka klasën e përdoruesit SalesPoint. E mbyllëm. Si ndodhi 'nuk është e nevojshme të implementoni manualisht kodin tuaj Java në çdo nyje' dhe kështu me radhë? Apo 'kodin tuaj Java' nuk e ka fjalën për SalesPoint?

Ndoshta kam humbur diçka - sërish filloj të kërkoj, lexoj dhe përsëri kërkoj. Pas një kohe, krijohet ndjenja se kam lexuar gjithçka mbi temën, nuk ka asgjë të re. Ndërsa kërkoja, gjeta disa vërejtje interesante.

Valentin Kulichenko, Arkitekt Kyç në GridGain Systems, përgjigje në StackOverflow, prill 2016:

Model klasat nuk janë të shërbimit të ndërsjellë, por mund të përdorni flamurin withKeepBinary() në cache dhe të kërkoni BinaryObjects. Kështu do të shmangni deserializimin në anën e serverit dhe nuk do të merrni ClassNotFoundException.

Një tjetër mendim autoritar: Denis Magda, Drejtor i menaxhimit të produktit, GridGain Systems.

Artikull në Habrë për mikroshërbimet i refero tri artikuj Denis Magda: Pjesa I e Mikrosherbimeve, Pjesa II e Mikrosherbimeve, Pjesa III e Mikrosherbimeve 2016-2017. Në artikullin e dytë, Denis sugjeron të filloni një nyje klasteri përmes MaintenanceServiceNodeStartup.jar. Mund të përdorni edhe nisjen me konfigurimin XML dhe komandën, por atëherë duhet të vendosni manualisht klasat e përdoruesit në çdo nyje të klasterit që deploy-n.

Kaq është. Filloni (..) nyjen duke përdorur skedarin MaintenanceServiceNodeStartup ose kaloni maintenance-service-node-config.xml në skriptet ignite.sh/bat të Apache Ignite. Nëse preferoni këtë të fundit, sigurohuni të ndihmoni një skedë jar që do të përmbajë të gjitha klasat nga java/app/common dhe java/services/maintenance. Jar-i duhet të shtohet në classpath e çdo nyje ku shërbimi mund të deploy-ohet.

Në të vërtetë, kjo është. Ja ai, duket, përse, ky format binar misterioz!

3. SingleJar

Denis zuri vendin e parë në renditjen time personale, imho tutoriali më i dobishëm nga të gjithë. Në të MicroServicesExample në GitHub përmban një shembull të plotë të konfigurimit të nyjeve të klasterit, që kompiloheshin pa asnjë përpjekje shtesë.

Po punoj sipas shembullit, duke marrë një skedë të vetme jar që aktivizon "data node" ose "client node" në përputhje me argumentin në komandë. Ndërtimi fillon dhe punon. Zero Deployment është mposhtur.

Kalimi nga megabajt të dhënash testuese në dhjetëra gigabajt të dhënash prodhuese tregon se formati binar nuk ekziston pa arsye. Duhej të optimizohej konsumi i memorjes në nyje, dhe këtu BinaryObject u tregua shumë i dobishëm.

4. Përfundime

Akuza e parë që ndesha në paqartësinë e dokumentacionit të projektit Apache Ignite ishte e drejtë, që nga viti 2016 ka ndryshuar pak.

Pas punës së bërë, mbeta me përshtypjen se Zero Deployment funksionon, por vetëm në nivel sistemor. Njëlloj si kjo: BinaryObject përdoret për t'i mësuar nyjet e largëta të klasterit të punojnë me klasat e përdoruesit; Zero Deployment - mekanizmi i brendshëm
i vetë Apache Ignite dhe shpërndan objekte sistemorë në klaster.

Shpresoj që eksperienca ime do të jetë e dobishme për përdoruesit e rinj të Apache Ignite.

Burimi: habr.com