🥇Apache Ignite Zero Deployment: a është vërtet Zero?

Ne jemi departamenti i zhvillimit të teknologjisë për rrjetin e shitjes me pakicë. Njëherë, drejtuesit vendosën të shpejtojnë llogaritjet voluminoze përmes përdorimit të Apache Ignite bashkë me MSSQL, duke treguar një faqe me ilustra të shkëlqyera dhe shembuj të kodit Java. Në faqen u pëlqyen menjëherë. Zero Deployment, përshkrimi i të cilit premton mrekulli: nuk keni nevojë të shpërndani manualisht kodin tuaj Java ose Scala në çdo nyjë në rrjet dhe ta ripërshkruani atë çdo herë që ndryshon. Gjatë punës, u zbulua se Zero Deployment ka specifika përdorimi, të cilat do të doja t'i ndaja. Nën këtë, reflektime dhe detaje të realizimit.

1. Formulimi i detyrës

Natyra e detyrës është si më poshtë. Ekziston një udhëzues për pikët e shitjes SalesPoint dhe një udhëzues për produktet Sku (Stock Keeping Unit). Pika e shitjes ka një atribut 'tipMëkatari' me vlera 'të vogla' dhe 'të mëdha'. Në çdo pikë shitjeje lidhet (ngarkohet nga DBMS) një gamë (listë produktesh të pikës së shitjes) dhe jepet informata se që nga data e caktuar, produkti i caktuar
përjashtohet nga gamën ose shtohet në gamë.

Duhet të organizoni një memorie me ndarje të pikave të shitjes dhe ta ruani informacionin për produktet e lidhura për një muaj të ardhshëm. Përputhja me sistemin luftarak kërkon nga nyja klienti Ignite të ngarkojë të dhënat, të llogarisë agregatin e formës (llojiDyqani, kodiProdukti, dita, numri_pikave_të_shitjes) dhe ta nxjerrë përsëri në DBMS.

2. Studimi i literaturës

Nuk kam përvojë deri më tani, prandaj filloj nga baza. Domethënë, me një përmbledhje të publikimeve.

Artikulli i vitit 2016 Njohja me Apache Ignite: hapat e parë përmban një lidhje me dokumentacionin e projektit Apache Ignite dhe njëherazi një vërejtje për paqartësinë e këtij dokumentacioni. E lexova disa herë, qartësia nuk vjen. Po i drejtohem tutorial-it zyrtar getting-started, i cili
optimistisht premton "Do jeni të gatshëm shpejt!". Po merrem me cilësimet e variablave të mjedisit, po shoh dy video Apache Ignite Essentials, për detyrën time specifike ato nuk rezultuan shumë të dobishme. Me sukses aktivizoj Ignite nga komanda e linjës me skedarin standard "example-ignite.xml", duke ndërtuar aplikacionin e parë Aplikacioni i Llogaritjes me ndihmën e Maven. Aplikacioni funksionon dhe përdor Zero Deployment, çfarë bukurie!

Po lexoj më tej, aty ka një shembull që përdor menjëherë affinityKey (i krijuar më parë përmes një kërkese SQL), dhe aplikohet një BinaryObject misterioz:

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

Lexova pak: formati binar — diçka si refleksioni, qasje në fushat e objektit me emër. Mund të lexojë vlerën e fushës pa deserializimin e plotë të objektit (kështu kursen memorie). Por pse përdoret BinaryObject në vend të Person, përderisa ka Zero Deployment? Pse IgniteCache<Key,Person> përkthehet në IgniteCache<BinaryObject, BinaryObject>? Ende nuk është e qartë.

Po e riformuloj Compute Application sipas rastit tim. Çelësi primar i referencës për pikat e shitjes në MSSQL është përcaktuar si [id] [int] NOT NULL, po krijoj një cache për analogji.

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

Në konfigurimin xml tregoj se cache-i është i ndarë në pjesë

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

Ndarja në pjesë sipas pikave të shitjes supozon se agregati i kërkuar do të ndërtohet në çdo nyje të klasterit për regjistrimet e atjeshme salesPointCache, e më pas nyja klient do të kryejë përmbledhjen përfundimtare.

Po lexoj tutorialin First Ignite Compute Application, bëj sipas analogjisë. Në çdo nyje të klasterit, ekzekutoj IgniteRunnable(), diçka e tillë:

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

Shtoj logjikën e agregimit dhe eksportit, ekzekutoj në një grup testimi të dhënash. Lokalisht në serverin e zhvillimit gjithçka funksionon.

Ekzekutoj dy serverë testues CentOS, caku i IP-ve në default-config.xml, kryej në secilin

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

Të dy nyjet e Ignite ekzekutohen dhe shohin njëra-tjetrën. Cakto adresat e nevojshme në xml-në e konfigurimit të aplikacionit klient, ai ekzekutohet, shton nyjën e tretë në topologji dhe menjëherë numri i nyjeve rikthehet në dy. Në log është e shënuar «ClassNotFoundException: model.SalesPoint» në rreshtin

SalesPoint sp=salesPointCache.get(spId);

StackOverflow thotë se shkaku i gabimit është — në serverët CentOS mungon klasa përdoruese SalesPoint. Kemi arritur. Si është e mundur që «nuk keni nevojë të vendosni manualisht kodin tuaj Java në çdo nyje» dhe më pas? Apo «kodi juaj Java» nuk ka të bëjë me SalesPoint?

Mund të ketë ndodhur që kam humbur diçka — filloj përsëri të kërkoj, të lexoj dhe përsëri të kërkoj. Pas një kohe, ndjehem sikur kam lexuar gjithçka për temën, nuk ka asgjë të re. Ndërsa kërkoja, gjeta disa vërejtje interesante.

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

Modelet e klasës nuk janë të vendosur nga ana jonë, por mund të përdorni flagun 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 autoritativ: Denis Magda, Drejtor i menaxhimit të produktit, GridGain Systems.

Artikulli në Habr për mikroshërbimet referon tri artikuj nga Denis Magda: Mikroshërbimet Pjesa I, Mikroshërbimet Pjesa II, Mikroshërbimet Pjesa III të vitit 2016-2017. Në artikullin e dytë, Denis sugjeron të filloni një nyje klasteri përmes MaintenanceServiceNodeStartup.jar. Mund të përdorni gjithashtu fillimin me konfigurimin xml dhe komandën e shiritit, por atëherë duhet të vendosni manualisht klasat përdoruese në çdo nyje klasteri që vendosni:

Këtu është. Filloni (..) nyjen duke përdorur skedarin MaintenanceServiceNodeStartup ose dërgoni maintenance-service-node-config.xml në skriptet e Apache Ignite's ignite.sh/bat. Nëse preferoni këtë të fundit, sigurohuni të ndërtoni një skedar jar që do të përmbajë të gjitha klasat nga java/app/common dhe java/services/maintenance direktoresh.

Vërtet, kjo është. Ja përse, ky format misterioz binar!

3. SingleJar

Denis zuri vendin e parë në renditjen time personale, mendoj se është tutoriali më i dobishëm nga të gjitha të disponueshmet. Në të MicroServicesExample Në GitHub ka një shembull të plotë për konfigurimin e nyjeve të grupit, i cili kompilon pa asnjë pengesë të tepërt.

Po krijoj në përputhje me modelin, duke marrë një skedar të vetëm jar, i cili ndez «data node» ose «client node» në varësi të argumentit të linjës së komandës. Ndërfaqja nis dhe funksionon. Zero Deployment është mundur.

Kalimi nga megabajt të dhënash testuese në dhjetëra gigabajt të dhënash reale tregoi se formati binar ka një qëllim. Duhej të optimizohej konsumimi i memories në nyje dhe aty BinaryObject u tregua shumë i dobishëm.

4. Përfundime

Kritika e parë për paqartësinë e dokumentacionit të projektit Apache Ignite u tregua e drejtë; që nga viti 2016 ka patur pak ndryshime. Një fillestar ka vështirësi për të ndërtuar një prototip funksionues bazuar në faqen e internetit dhe/ose repositorin.

Si rezultat i punës së kryer, u krijua përshtypja se Zero Deployment funksionon, por vetëm në nivelin sistemor. Më në fund, BinaryObject përdoret për të mësuar nyjet e largëta të grupit të punojnë me klasat përdoruese; Zero Deployment është një mekanizëm i brendshëm
i Apache Ignite dhe shpërndan objekte sistemore në të gjithë grupin.

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

Burimi: habr.com