Implementazione di Apache Ignite Zero: Daveru Zero?

Semu u dipartimentu di sviluppu tecnologicu di una reta di vendita. Un ghjornu, a gestione hà stabilitu u compitu di accelerà i calculi à grande scala usendu Apache Ignite in cungiunzione cù MSSQL, è mostrò un situ web cù belli illustrazioni è esempi di codice Java. Mi piacia subitu u situ Impiegazione Zero, A descrizzione di quale prumesse miraculi: ùn avete micca bisognu di implementà manualmente u vostru codice Java o Scala nantu à ogni node in a griglia è ripiglià ogni volta chì cambia. Quandu u travagliu avanzava, hè risultatu chì Zero Deployment hà usi specifichi, e caratteristiche di quale vogliu sparte. Sottu u cut sò pinsamenti è dettagli di implementazione.

1. Dichjarazione di u prublema

L'essenza di u prublema hè a siguenti. Ci hè un repertoriu di punti di vendita SalesPoint è un repertoriu di prudutti Sku (Stock Keeping Unit). U puntu di vendita hà un attributu "Tippu Store" cù i valori "picculu" è "grande". Un assortiment (lista di prudutti di u puntu di vendita) hè cunnessu à ogni puntu di vendita (caricatu da u DBMS) è l'infurmazione hè furnita chì da a data specificata u pruduttu specificatu.
esclusu da l'assortimentu o aghjuntu à l'assortiment.

Hè necessariu urganizà una cache partizionata di punti di vendita è almacenà in questu infurmazione nantu à i prudutti cunnessi per un mesi in anticipu. A cumpatibilità cù u sistema di cummattimentu richiede u nodu di u cliente Ignite per carricà e dati, calculà un aggregatu di a forma (Tippu Store, Codice di u produttu, ghjornu, number_of_sales_points) è caricate torna à u DBMS.

2. Studiu di a literatura

Ùn aghju micca una sperienza ancu, cusì cuminciu à ballà da a stufa. Questu hè, da una rivista di publicazioni.

Articulu 2016 Presentazione di Apache Ignite: Primi passi cuntene un ligame à a documentazione di u prughjettu Apache Ignite è à u stessu tempu un rimproveru per a vaguezza di sta documentazione. L'aghju rilettu un paru di volte, a chiarezza ùn vene micca. Mi riferite à u tutoriale ufficiale principiatu, chì
promette ottimista "Sarete attivu in un battitu!" Scuprite i paràmetri di l'ambienti variabili, fighjendu dui video Apache Ignite Essentials, ma ùn eranu micca assai utili per u mo compitu specificu. Aghju lanciatu successu Ignite da a linea di cummanda cù u schedariu standard "example-ignite.xml", custruendu a prima applicazione Applicazione di calculu usendu Maven. L'applicazione funziona è usa Zero Deployment, chì bellezza!

Aghju lettu più, è quì l'esempiu usa immediatamente affinityKey (creatu prima attraversu una query SQL), è ancu usa u misteriosu BinaryObject:

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

Aghju lettu un pocu: formatu binariu - qualcosa cum'è riflessione, accede à i campi di un oggettu per nome. Pudete leghje u valore di un campu senza deserializà cumplettamente l'ughjettu (salvendu memoria). Ma perchè BinaryObject hè utilizatu invece di Person, postu chì ci hè Zero Deployment? Perchè IgniteCache trasferitu à IgniteCache ? Ùn hè ancu chjaru.

Aghju rifacendu l'Applicazione di Compute per adattà à u mo casu. A chjave primaria di u repertoriu di punti di vendita in MSSQL hè definitu cum'è [id] [int] NOT NULL, creanu un cache per analogia.

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

In u xml config indicà chì a cache hè partizionata

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

A particione per u puntu di vendita assume chì l'agregatu necessariu serà custruitu nantu à ogni node di cluster per i registri salesPointCache dispunibuli quì, dopu chì u nodu di u cliente farà a somma finale.

Leghje u tutoriale Prima Applicazione Ignite Compute, Facciu per analogia. Nantu à ogni node di cluster, aghju IgniteRunnable (), qualcosa cum'è questu:

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

Aghju aghjustatu l'agregazione è a logica di carica è eseguite nantu à un set di dati di prova. Tuttu u travagliu locale nantu à u servitore di sviluppu.

Lanciau dui servitori di teste CentOs, specificate l'indirizzi IP in default-config.xml, eseguite nantu à ognunu.

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

I dui nodi Ignite sò in esecuzione è ponu vede l'altru. Specificu l'indirizzi richiesti in a cunfigurazione xml di l'applicazione cliente, cumencia, aghjunghje un terzu node à a topologia è immediatamente ci sò dui nodi di novu. U logu mostra "ClassNotFoundException: model.SalesPoint" in a linea

SalesPoint sp=salesPointCache.get(spId);

StackOverflow dice chì u mutivu di l'errore hè chì ùn ci hè micca una classa SalesPoint persunalizata in i servitori CentOs. Avemu ghjuntu. Chì ne dite di "ùn avete micca bisognu di implementà manualmente u vostru codice Java in ogni node" è cusì? O "u vostru codice Java" ùn hè micca nantu à SalesPoint?

Probabilmente mi mancava qualcosa - cuminciu à circà di novu, leghje è cercà di novu. Dopu qualchì tempu, aghju a sensazione chì aghju lettu tuttu nantu à u tema, ùn ci hè più nunda di novu. Mentre cercava, aghju trovu alcuni cumenti interessanti.

Valentin Kulichenko, Architettu Capu di GridGain Systems, risposta nantu à StackOverflow, aprile 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.

Un altru opinione autoritariu: Denis Magda, Direttore di gestione di u produttu, Sistemi GridGain.

Articulu nantu à Habré circa i microservizi riferenzi trè articuli di Denis Magda: Microservices Part I, Microservices Part II, Microservices Part III 2016-2017. In u sicondu articulu, Denis suggerisce di inizià un node di cluster via MaintenanceServiceNodeStartup.jar. Pudete ancu aduprà u lanciamentu cù a cunfigurazione xml è a linea di cummanda, ma dopu avete bisognu di mette manualmente classi persunalizati in ogni nodu di cluster implementatu:

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.

Infatti, hè questu. Quì si trova, perchè, stu misteriu furmatu binariu!

3.SingleJar

Denis hà pigliatu u primu postu in a mo valutazione persunale, IMHO u tutoriale più utile di tutti i dispunibili. In u so MicroServices Esempiu Github cuntene un esempiu cumpletamente prontu di creazione di nodi di cluster, chì compila senza alcunu squatting supplementu.

Facciu u listessu modu è uttene un unicu schedariu jar chì lancia "node di dati" o "node di cliente" secondu l'argumentu di a linea di cumanda. L'assemblea principia è travaglia. Zero Deployment hè statu scunfittu.

A transizione da megabytes di dati di teste à decine di gigabytes di dati di cummattimentu hà dimustratu chì u formatu binariu esiste per una ragione. Era necessariu di ottimisà u cunsumu di memoria nantu à i nodi, è questu hè induve BinaryObject resultò assai utile.

4. Cunclusioni

U primu rimproveru scontru annantu à a vaguezza di a documentazione di u prughjettu Apache Ignite hè statu ghjustu; pocu hè cambiatu da u 2016. Ùn hè micca faciule per un principiante assemble un prototipu funzionante basatu annantu à un situ web è / o repository.

Basatu nantu à i risultati di u travagliu fattu, l'impressione era chì Zero Deployment travaglia, ma solu à u livellu di u sistema. Qualcosa cum'è questu: BinaryObject hè utilizatu per insignà i nodi di cluster remoti per travaglià cù classi persunalizati; Zero Deployment - mecanismu internu
Apache Ignite stessu è distribuisce l'ogetti di u sistema in tuttu u cluster.

Spergu chì a mo sperienza serà utile à i novi utilizatori Apache Ignite.

Source: www.habr.com