Apache Ignite Zero Deployment: Zero talaga?

Apache Ignite Zero Deployment: Zero talaga?

Kami ang departamento ng pagpapaunlad ng teknolohiya ng isang retail network. Isang araw, itinakda ng pamamahala ang gawain ng pagpapabilis ng malakihang mga kalkulasyon sa pamamagitan ng paggamit ng Apache Ignite kasabay ng MSSQL, at nagpakita ng isang website na may magagandang mga guhit at mga halimbawa ng Java code. Nagustuhan ko agad ang site Zero Deployment, ang paglalarawan kung saan nangangako ng mga himala: hindi mo kailangang manu-manong i-deploy ang iyong Java o Scala code sa bawat node sa grid at muling i-deploy ito sa tuwing magbabago ito. Sa pag-unlad ng trabaho, lumabas na ang Zero Deployment ay may mga partikular na gamit, ang mga tampok na gusto kong ibahagi. Sa ibaba ng hiwa ay mga ideya at mga detalye ng pagpapatupad.

1. Paglalahad ng suliranin

Ang kakanyahan ng problema ay ang mga sumusunod. Mayroong isang SalesPoint sales point directory at isang Sku (Stock Keeping Unit) na direktoryo ng produkto. Ang punto ng pagbebenta ay may katangiang "Uri ng tindahan" na may mga halagang "maliit" at "malaki". Ang isang assortment (listahan ng mga produkto ng punto ng pagbebenta) ay konektado sa bawat punto ng pagbebenta (na-load mula sa DBMS) at ang impormasyon ay ibinigay na mula sa tinukoy na petsa ang tinukoy na produkto
hindi kasama sa assortment o idinagdag sa assortment.

Kinakailangan na ayusin ang isang naka-partition na cache ng mga punto ng pagbebenta at mag-imbak dito ng impormasyon tungkol sa mga konektadong produkto sa loob ng isang buwan nang maaga. Ang compatibility sa combat system ay nangangailangan ng Ignite client node na mag-load ng data, kalkulahin ang pinagsama-samang form (Uri ng tindahan, Product code, araw, number_of_sales_points) at i-upload ito pabalik sa DBMS.

2. Pag-aaral ng panitikan

Wala pa akong karanasan, kaya nagsisimula akong sumayaw mula sa kalan. Iyon ay, mula sa isang pagsusuri ng mga publikasyon.

Artikulo 2016 Ipinapakilala ang Apache Ignite: Mga Unang Hakbang naglalaman ng link sa dokumentasyon ng proyektong Apache Ignite at kasabay nito ay isang pagsisisi para sa malabo ng dokumentasyong ito. Binasa ko itong muli ng ilang beses, hindi dumating ang kalinawan. Sumangguni ako sa opisyal na tutorial nagsisimulaAlin
optimistikong nangangako "Babangon ka at tatakbo sa isang iglap!" Inaalam ko ang mga setting ng variable ng kapaligiran, nanonood ng dalawang video ng Apache Ignite Essentials, ngunit hindi ito masyadong kapaki-pakinabang para sa aking partikular na gawain. Matagumpay kong inilunsad ang Ignite mula sa command line na may karaniwang file na "example-ignite.xml", na bumubuo ng unang application Compute Application gamit si Maven. Gumagana ang application at gumagamit ng Zero Deployment, napakaganda!

Nagbasa pa ako, at doon ang halimbawa ay agad na gumagamit ng affinityKey (ginawa nang mas maaga sa pamamagitan ng isang SQL query), at kahit na ginagamit ang mahiwagang BinaryObject:

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

binasa ko medyo: binary format - isang bagay tulad ng pagmuni-muni, pag-access sa mga patlang ng isang bagay sa pamamagitan ng pangalan. Maaaring basahin ang halaga ng isang patlang nang hindi ganap na deserialize ang bagay (nagse-save ng memorya). Ngunit bakit ginagamit ang BinaryObject sa halip na Tao, dahil mayroong Zero Deployment? Bakit IgniteCache inilipat sa IgniteCache ? Hindi pa malinaw.

Ginagawa kong muli ang Compute Application upang umangkop sa aking kaso. Ang pangunahing susi ng direktoryo ng mga punto ng pagbebenta sa MSSQL ay tinukoy bilang [id] [int] HINDI NULL, lumikha ako ng isang cache sa pamamagitan ng pagkakatulad

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

Sa xml config, ipinapahiwatig ko na ang cache ay nahahati

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

Ipinapalagay ng paghahati ayon sa punto ng pagbebenta na ang kinakailangang pinagsama-samang ay bubuo sa bawat cluster node para sa mga talaan ng salesPointCache na available doon, pagkatapos nito ay isasagawa ng client node ang panghuling pagsusuma.

Nagbabasa ako ng tutorial Unang Ignite Compute Application, ginagawa ko ito sa pamamagitan ng pagkakatulad. Sa bawat cluster node pinapatakbo ko ang IgniteRunnable(), tulad nito:

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

Nagdaragdag ako ng pagsasama-sama at pag-upload ng lohika at pinapatakbo ito sa isang set ng data ng pagsubok. Lahat ay gumagana nang lokal sa development server.

Naglulunsad ako ng dalawang CentOs test server, tukuyin ang mga IP address sa default-config.xml, isagawa sa bawat isa

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

Ang parehong Ignite node ay tumatakbo at nakikita ang isa't isa. Tinukoy ko ang mga kinakailangang address sa xml config ng application ng kliyente, magsisimula ito, nagdaragdag ng ikatlong node sa topology at kaagad na mayroong dalawang node muli. Ipinapakita ng log ang "ClassNotFoundException: model.SalesPoint" sa linya

SalesPoint sp=salesPointCache.get(spId);

Sinasabi ng StackOverflow na ang dahilan ng error ay walang custom na klase ng SalesPoint sa mga server ng CentOs. Nakarating na kami. Paano ang tungkol sa "hindi mo kailangang manu-manong i-deploy ang iyong Java code sa bawat node" at iba pa? O ang "iyong Java code" ay hindi tungkol sa SalesPoint?

Malamang na may napalampas ako - nagsimula akong maghanap muli, magbasa at maghanap muli. Maya-maya, feeling ko nabasa ko na lahat sa topic, wala nang bago. Habang naghahanap ako, nakakita ako ng ilang mga interesanteng komento.

Valentin Kulichenko, Lead Architect sa GridGain Systems, sagutin sa StackOverflow, Abril 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.

Isa pang makapangyarihang opinyon: Denis Magda, Direktor ng pamamahala ng produkto, GridGain Systems.

Artikulo sa HabrΓ© tungkol sa mga microservice binanggit ang tatlong artikulo ni Denis Magda: Mga Microservice Bahagi I, Mga Microservice Bahagi II, Mga Microservice Bahagi III 2016-2017. Sa pangalawang artikulo, iminumungkahi ni Denis na simulan ang isang cluster node sa pamamagitan ng MaintenanceServiceNodeStartup.jar. Maaari mo ring gamitin ang paglunsad na may xml configuration at command line, ngunit pagkatapos ay kailangan mong manu-manong maglagay ng mga custom na klase sa bawat naka-deploy na cluster node:

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

Talaga, iyon lang. Dito lumalabas, bakit, ang mahiwagang binary format na ito!

3.SingleJar

Nauna si Denis sa aking personal na rating, IMHO ang pinakakapaki-pakinabang na tutorial sa lahat ng magagamit. Sa kanyang MicroServicesExample Ang Github ay naglalaman ng isang ganap na handa na halimbawa ng pag-set up ng mga cluster node, na nag-compile nang walang anumang karagdagang squatting.

Ginagawa ko ito sa parehong paraan at kumuha ng isang solong jar file na naglulunsad ng "data node" o "client node" depende sa argumento ng command line. Ang pagpupulong ay nagsisimula at gumagana. Ang Zero Deployment ay natalo.

Ang paglipat mula sa megabytes ng data ng pagsubok sa sampu-sampung gigabytes ng data ng labanan ay nagpakita na ang binary na format ay umiiral para sa isang kadahilanan. Ito ay kinakailangan upang i-optimize ang pagkonsumo ng memorya sa mga node, at ito ay kung saan ang BinaryObject ay naging lubhang kapaki-pakinabang.

4. Konklusyon

Ang unang pagsisisi na nakatagpo tungkol sa malabo ng dokumentasyon ng proyekto ng Apache Ignite ay naging patas; kaunti ang nagbago mula noong 2016. Hindi madali para sa isang baguhan na mag-assemble ng gumaganang prototype batay sa isang website at/o repository.

Batay sa mga resulta ng gawaing ginawa, ang impresyon ay gumagana ang Zero Deployment, ngunit sa antas lamang ng system. Isang bagay na tulad nito: BinaryObject ay ginagamit upang turuan ang mga remote cluster node na gumana sa mga custom na klase; Zero Deployment - panloob na mekanismo
Apache Ignite mismo at namamahagi ng mga system object sa buong cluster.

Umaasa ako na ang aking karanasan ay magiging kapaki-pakinabang sa mga bagong gumagamit ng Apache Ignite.

Pinagmulan: www.habr.com

Magdagdag ng komento