Apache Ignite Zero telepítés: Tényleg nulla?

Egy kiskereskedelmi hálózat technológiai fejlesztési osztálya vagyunk. Egy napon a vezetőség feladatul tűzte ki a nagyszabású számítások felgyorsítását az Apache Ignite és az MSSQL együttes használatával, és bemutatott egy webhelyet gyönyörű illusztrációkkal és Java kód példákkal. Azonnal megtetszett az oldal Nulla telepítés, melynek leírása csodákat ígér: nem kell manuálisan telepítenie Java vagy Scala kódját a grid minden csomópontjára, és minden egyes változáskor újratelepíteni. A munka előrehaladtával kiderült, hogy a Zero Deploymentnek konkrét felhasználási területei vannak, amelyek funkcióit szeretném megosztani. A vágás alatt gondolatok és a megvalósítás részletei találhatók.

1. A probléma megfogalmazása

A probléma lényege a következő. Létezik egy SalesPoint értékesítési pont-címtár és egy Sku-termékkönyvtár (Stock Keeping Unit). Az értékesítési pontnak van egy „Store type” attribútuma „small” és „large” értékekkel. Minden értékesítési ponthoz (a DBMS-ből betöltve) egy szortiment (az értékesítési pont terméklistája) kapcsolódik, és tájékoztatást ad arról, hogy a megadott dátumtól a megadott termék
kizárják a választékból vagy hozzáadják a választékhoz.

Meg kell szervezni az értékesítési pontok particionált gyorsítótárát, és ebben tárolni kell a csatlakoztatott termékekkel kapcsolatos információkat egy hónapra előre. A harci rendszerrel való kompatibilitás megköveteli, hogy az Ignite kliens csomópont betöltse az adatokat, kiszámítsa az űrlap összesítését (üzlettípus, termékkód, nap, értékesítési_pontok száma) és visszatöltse a DBMS-be.

2. Irodalomtudomány

Még nincs tapasztalatom, ezért elkezdek táncolni a tűzhelyről. Vagyis a kiadványok áttekintéséből.

2016. cikk Bemutatkozik az Apache Ignite: Első lépések tartalmaz egy hivatkozást az Apache Ignite projekt dokumentációjához, és egyben szemrehányást tesz a dokumentáció homályossága miatt. Párszor újraolvastam, nem jön be az egyértelműség. A hivatalos oktatóanyagra hivatkozom elkezdenihogy
optimistán megígéri: „Rendben üzembe kerülsz!” A környezeti változók beállításait találgatom, nézek két Apache Ignite Essentials videót, de nem voltak túl hasznosak a konkrét feladatomhoz. Sikeresen elindítom az Ignite-ot a parancssorból a szabványos „example-ignite.xml” fájllal, létrehozva az első alkalmazást Alkalmazás számítása Maven segítségével. Az alkalmazás működik, és nulla telepítést használ, micsoda szépség!

Tovább olvastam, és ott a példa azonnal az affinityKey-t használja (korábban egy SQL lekérdezéssel jött létre), és még a titokzatos BinaryObject-et is használja:

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

olvas немного: bináris formátum - valami reflexió, egy objektum mezőinek név szerinti elérése. Ki tudja olvasni egy mező értékét az objektum teljes deszerializálása nélkül (memória megtakarítása). De miért használják a BinaryObject-et a Person helyett, mivel nulla telepítés létezik? Miért az IgniteCache átkerült az IgniteCache-be ? Még nem világos.

Átalakítom a Számítási alkalmazást, hogy megfeleljen az esetemnek. Az MSSQL-ben az értékesítési pontok címtárának elsődleges kulcsa [id] [int] NOT NULL, analógia alapján létrehozok egy gyorsítótárat

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

Az xml konfigban jeleztem, hogy a gyorsítótár particionálva van

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

Az értékesítési pont szerinti particionálás azt feltételezi, hogy a szükséges összesítés minden fürtcsomópontra épül az ott elérhető salesPointCache rekordokhoz, majd az ügyfélcsomópont elvégzi a végső összegzést.

Olvasom a tutorialt Az első Ignite Compute alkalmazás, hasonlatosan csinálom. Minden fürtcsomóponton futtatom az IgniteRunnable()-t, valami ilyesmit:

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

Hozzáadom az összesítési és feltöltési logikát, és futtatom egy tesztadatkészleten. Minden helyileg működik a fejlesztői szerveren.

Elindítok két CentOs tesztszervert, megadom az IP-címeket a default-config.xml fájlban, és mindegyiken végrehajtom

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

Mindkét Ignite csomópont fut, és látják egymást. A kliens alkalmazás xml konfigjában megadom a szükséges címeket, elindul, hozzáad egy harmadik csomópontot a topológiához és azonnal újra két csomópont. A naplóban a „ClassNotFoundException: model.SalesPoint” látható a sorban

SalesPoint sp=salesPointCache.get(spId);

A StackOverflow szerint a hiba oka az, hogy nincs egyéni SalesPoint osztály a CentOs szervereken. Megérkeztünk. Mit szólnál ahhoz, hogy „nem kell manuálisan telepítenie a Java kódot minden csomóponton” és így tovább? Vagy az Ön Java-kódja nem a SalesPointról szól?

Valószínűleg kihagytam valamit – újra elkezdek keresni, olvasni és újra keresni. Egy idő után az az érzésem, hogy mindent elolvastam a témában, már nincs újdonság. Miközben keresgéltem, találtam néhány érdekes megjegyzést.

Valentin Kulicsenko, vezető építész a GridGain Systemsnél, válasz a StackOverflow-n, 2016. április:

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.

Egy másik mérvadó vélemény: Denis Magda, a GridGain Systems termékmenedzsment igazgatója.

Cikk Habréról a mikroszolgáltatásokról hivatkozik Denis Magda három cikkére: Mikroszolgáltatások I. rész, Mikroszolgáltatások II. rész, Mikroszolgáltatások III. rész 2016-2017. A második cikkben Denis egy fürtcsomópont indítását javasolja a MaintenanceServiceNodeStartup.jar fájlon keresztül. Használhatja az indítást az xml-konfigurációval és a parancssorral is, de ezután manuálisan kell egyéni osztályokat elhelyeznie minden egyes telepített fürtcsomóponton:

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.

Valóban, ez az. Itt kiderül, miért, ez a titokzatos bináris formátum!

3.SingleJar

Denis az első helyet szerezte meg személyes értékelésemben, az IMHO a leghasznosabb oktatóanyag az összes elérhető közül. Az övében MicroServicesPélda A Github egy teljesen kész példát tartalmaz a fürtcsomópontok beállítására, amely minden további squatting nélkül fordít.

Ugyanúgy csinálom, és kapok egy egyetlen jar fájlt, amely elindítja a „data node” vagy a „client node” parancssori argumentumtól függően. Az összeszerelés elindul és működik. A Zero Deployment vereséget szenvedett.

A megabájt tesztadatokról több tíz gigabájtnyi harci adatra való átállás megmutatta, hogy a bináris formátum okkal létezik. Optimalizálni kellett a memóriafelhasználást a csomópontokon, és itt bizonyult nagyon hasznosnak a BinaryObject.

4. Konklúziók

Az Apache Ignite projektdokumentáció homályosságával kapcsolatos első szemrehányás igazságosnak bizonyult; 2016 óta alig változott. Egy kezdőnek nem könnyű összeállítani egy működő prototípust egy weboldal és/vagy tárhely alapján.

Az elvégzett munka eredményei alapján az volt a benyomás, hogy a Zero Deployment működik, de csak rendszerszinten. Valami ehhez hasonló: A BinaryObject arra szolgál, hogy megtanítsa a távoli fürtcsomópontokat az egyéni osztályokkal való együttműködésre; Zero Deployment - belső mechanizmus
Az Apache Ignite magát, és elosztja a rendszerobjektumokat a fürtben.

Remélem, hogy tapasztalataim hasznosak lesznek az új Apache Ignite felhasználók számára.

Forrás: will.com