Február 26-án Apache Ignite GreenSource találkozót tartottunk, ahol a nyílt forráskódú projekt közreműködői beszéltek . E közösség életében fontos esemény volt a komponens átalakítása , amely lehetővé teszi az egyéni mikroszolgáltatások közvetlen telepítését egy Ignite-fürtbe. Erről a nehéz folyamatról beszélt a találkozón , szoftvermérnök és Apache Ignite közreműködő több mint két éve.
Kezdjük azzal, hogy mi az Apache Ignite általában. Ez egy olyan adatbázis, amely egy elosztott kulcs/érték tároló, amely támogatja az SQL-t, a tranzakciókat és a gyorsítótárazást. Ezenkívül az Ignite lehetővé teszi az egyéni szolgáltatások közvetlen telepítését egy Ignite-fürtbe. A fejlesztő hozzáfér az Ignite által kínált összes eszközhöz – elosztott adatstruktúrákhoz, üzenetkezeléshez, adatfolyamokhoz, számításokhoz és adatrácsokhoz. Például a Data Grid használatakor megszűnik az adattároláshoz külön infrastruktúra adminisztrálásának problémája, és ennek következtében az ebből eredő rezsiköltségek.
A Service Grid API használatával telepíthet egy szolgáltatást úgy, hogy egyszerűen megadja a telepítési sémát, és ennek megfelelően magát a szolgáltatást a konfigurációban.
A telepítési séma általában a fürtcsomópontokon telepítendő példányok számát jelzi. Két tipikus telepítési séma létezik. Az első a Cluster Singleton: adott időpontban a felhasználói szolgáltatás egy példánya garantáltan elérhető lesz a fürtben. A második a Node Singleton: a szolgáltatás egy példánya minden fürtcsomóponton telepítve van.
A felhasználó megadhatja a szolgáltatáspéldányok számát a teljes fürtben, és meghatározhat egy predikátumot a megfelelő csomópontok szűréséhez. Ebben a forgatókönyvben a Service Grid maga fogja kiszámítani a szolgáltatások üzembe helyezésének optimális eloszlását.
Ezen kívül van egy olyan szolgáltatás, mint az Affinity Service. Az affinitás egy olyan függvény, amely meghatározza a kulcsok kapcsolatát a partíciókkal és a felek kapcsolatát a csomópontokkal a topológiában. A kulccsal meghatározhatja az elsődleges csomópontot, amelyen az adatok tárolódnak. Így társíthatja saját szolgáltatását egy kulcs- és affinitásfüggvény-gyorsítótárral. Ha az affinitási funkció megváltozik, az automatikus újratelepítés megtörténik. Ezáltal a szolgáltatás mindig a kezelendő adatok közelében lesz, és ennek megfelelően csökkenti az információhoz való hozzáférés többletköltségét. Ezt a sémát egyfajta kollokált számítástechnikának nevezhetjük.
Most, hogy rájöttünk, mi a Service Grid szépsége, beszéljünk a fejlesztési történetéről.
Ami korábban történt
A Service Grid korábbi megvalósítása az Ignite tranzakciós replikált rendszer-gyorsítótárán alapult. A "gyorsítótár" szó az Ignite-ban a tárolásra utal. Vagyis ez nem valami átmeneti, ahogy gondolnád. Annak ellenére, hogy a gyorsítótár replikálva van, és minden csomópont tartalmazza a teljes adatkészletet, a gyorsítótáron belül van egy particionált ábrázolása. Ez a tárolás optimalizálásának köszönhető.
Mi történt, amikor a felhasználó telepíteni akarta a szolgáltatást?
- A fürt összes csomópontja feliratkozott a tárolóban lévő adatok frissítésére a beépített folyamatos lekérdezési mechanizmus segítségével.
- A kezdeményező csomópont egy olvasási-végrehajtási tranzakció során rekordot hozott létre az adatbázisban, amely tartalmazza a szolgáltatás konfigurációját, beleértve a soros példányt is.
- Amikor értesítést kapott az új bejegyzésről, a koordinátor a konfiguráció alapján kiszámította az eloszlást. A kapott objektumot visszaírtuk az adatbázisba.
- Ha egy csomópont a disztribúció része volt, a koordinátornak kellett telepítenie.
Ami nekünk nem jött be
Valamikor arra a következtetésre jutottunk: a szolgáltatásokkal nem így kell dolgozni. Több oka is volt.
Ha valamilyen hiba történt a telepítés során, akkor azt csak annak a csomópontnak a naplójából lehetett kideríteni, ahol minden történt. Csak aszinkron üzembe helyezés történt, így miután a telepítési módból visszaadták a felhasználónak az irányítást, némi további időre volt szükség a szolgáltatás elindításához - és ezalatt a felhasználó semmit sem tudott irányítani. A Service Grid továbbfejlesztése, új funkciók létrehozása, új felhasználók vonzása és mindenki életének megkönnyítése érdekében valamit változtatni kell.
Az új Service Grid megtervezésekor mindenekelőtt a szinkron telepítésre kívántunk garanciát adni: amint a felhasználó visszaadta az irányítást az API-ból, azonnal használhatja a szolgáltatásokat. Azt is szerettem volna, hogy a kezdeményező kezelje a telepítési hibákat.
Ezen kívül szerettem volna leegyszerűsíteni a megvalósítást, vagyis megszabadulni a tranzakcióktól és az egyensúlyozástól. Annak ellenére, hogy a gyorsítótár replikálva van, és nincs egyensúlyozás, problémák merültek fel a sok csomópontot tartalmazó nagy telepítés során. Amikor a topológia megváltozik, a csomópontoknak információt kell cserélniük, és nagy telepítés esetén ezek az adatok sokat nyomhatnak.
Amikor a topológia instabil volt, a koordinátornak újra kellett számolnia a szolgáltatások elosztását. És általában, ha instabil topológiájú tranzakciókkal kell dolgoznia, ez nehezen megjósolható hibákhoz vezethet.
Problémák
Mik a globális változások kísérő problémák nélkül? Ezek közül az első a topológia megváltoztatása volt. Meg kell értenie, hogy egy csomópont bármikor, még a szolgáltatás üzembe helyezésének pillanatában is beléphet a fürtbe vagy elhagyhatja azt. Ezenkívül, ha az üzembe helyezéskor a csomópont csatlakozik a fürthöz, akkor következetesen át kell vinni a szolgáltatásokkal kapcsolatos összes információt az új csomóponthoz. És nem csak a már telepítettekről beszélünk, hanem a jelenlegi és a jövőbeni telepítésekről is.
Ez csak egy a külön listában összegyűjthető problémák közül:
- Hogyan telepíthetek statikusan konfigurált szolgáltatásokat a csomópont indításakor?
- Csomópont elhagyása a fürtből – mi a teendő, ha a csomópont szolgáltatásokat tárol?
- Mi a teendő, ha a koordinátor megváltozott?
- Mi a teendő, ha az ügyfél újracsatlakozik a fürthöz?
- Fel kell-e és hogyan kell feldolgozni az aktiválási/deaktiválási kérelmeket?
- Mi van, ha a gyorsítótár megsemmisítését kérik, és ehhez kapcsolódnak affinitási szolgáltatások?
És ez még nem minden.
döntés
Célként az eseményvezérelt megközelítést választottuk az üzenetek segítségével történő folyamatkommunikáció megvalósításával. Az Ignite már megvalósított két olyan komponenst, amelyek lehetővé teszik a csomópontok egymás közötti üzenetek továbbítását – a kommunikációs-spi és a felfedezés-spi.
A Communication-spi lehetővé teszi a csomópontok közvetlen kommunikációját és üzenetek továbbítását. Kiválóan alkalmas nagy mennyiségű adat küldésére. A Discovery-spi lehetővé teszi, hogy üzenetet küldjön a fürt összes csomópontjához. A szabványos megvalósításban ez gyűrű topológia segítségével történik. A Zookeeperrel is van integráció, ebben az esetben csillag topológiát használnak. Egy másik fontos szempont, amit érdemes megjegyezni, hogy a discovery-spi garantálja, hogy az üzenet biztosan a megfelelő sorrendben kerül kézbesítésre az összes csomóponthoz.
Nézzük a telepítési protokollt. Az összes telepítési és telepítési kérelmet a discovery-spi-n keresztül küldik el. Ez a következőt adja garanciákat:
- A kérést a fürt összes csomópontja megkapja. Ez lehetővé teszi a kérés feldolgozásának folytatását, ha a koordinátor megváltozik. Ez azt is jelenti, hogy egy üzenetben minden csomópont rendelkezik az összes szükséges metaadattal, például a szolgáltatás konfigurációjával és a soros példányával.
- Az üzenetkézbesítés szigorú sorrendje segít a konfigurációs ütközések és a versengő kérések megoldásában.
- Mivel a csomópont topológiába való belépése is discovery-spi-n keresztül történik, az új csomópont megkapja a szolgáltatásokkal való együttműködéshez szükséges összes adatot.
Amikor egy kérés érkezik, a fürt csomópontjai érvényesítik azt, és feldolgozási feladatokat hoznak létre. Ezeket a feladatokat sorba állítja, majd egy másik szálban dolgozza fel egy külön dolgozó. Azért valósítják meg így, mert a telepítés jelentős időt vehet igénybe, és elviselhetetlenül késleltetheti a drága felfedezési folyamatot.
A sorból érkező összes kérést a telepítéskezelő dolgozza fel. Van egy speciális feldolgozója, amely lehív egy feladatot ebből a sorból, és inicializálja azt a központi telepítés megkezdéséhez. Ezt követően a következő műveletek történnek:
- Minden csomópont önállóan számítja ki az eloszlást egy új determinisztikus hozzárendelési függvénynek köszönhetően.
- A csomópontok üzenetet generálnak a telepítés eredményeivel, és elküldik a koordinátornak.
- A koordinátor összesíti az összes üzenetet, és létrehozza a teljes üzembe helyezési folyamat eredményét, amelyet a discovery-spi-n keresztül elküld a fürt összes csomópontjához.
- Az eredmény megérkezésekor a telepítési folyamat véget ér, majd a feladatot eltávolítják a sorból.
Új eseményvezérelt kialakítás: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ha hiba történik a telepítés során, a csomópont azonnal belefoglalja ezt a hibát egy üzenetbe, amelyet a koordinátornak küld. Az üzenetösszesítés után a koordinátor minden hibáról információt kap a telepítés során, és ezt az üzenetet a discovery-spi-n keresztül küldi el. A hibainformáció a fürt bármely csomópontján elérhető lesz.
A Service Grid minden fontos eseményét ezzel a működési algoritmussal dolgozzuk fel. Például a topológia megváltoztatása is üzenet a discovery-spi-n keresztül. És általában, a korábbihoz képest a protokoll meglehetősen könnyűnek és megbízhatónak bizonyult. Elegendő bármilyen helyzet kezelésére a telepítés során.
Mi fog ezután történni
Most a tervekről. Az Ignite projekt minden jelentősebb változtatása az Ignite fejlesztési kezdeményezésként, az úgynevezett IEP-ként történik. A Service Grid újratervezése rendelkezik egy IEP-vel is - „Olajcsere a szervizhálózatban” gúnyos címmel. De valójában nem a motorolajat cseréltük, hanem az egész motort.
Az IEP-ben a feladatokat 2 fázisra osztottuk. Az első egy fő fázis, amely a telepítési protokoll átdolgozásából áll. A masterben már benne van, ki lehet próbálni az új Service Grid-et, ami a 2.8-as verzióban fog megjelenni. A második szakasz sok egyéb feladatot is tartalmaz:
- Hot redeploy
- Szolgáltatás verziószámítás
- Fokozott hibatűrés
- Vékony kliens
- Eszközök különféle mutatók figyeléséhez és kiszámításához
Végül tanácsot adunk a Service Griddel kapcsolatban a hibatűrő, magas rendelkezésre állású rendszerek kiépítéséhez. Meghívjuk Önt is, hogy látogasson el hozzánk a címen и ossza meg tapasztalatait. Tapasztalata nagyon fontos a közösség számára, segít megérteni, merre tovább, hogyan fejlesztheti a komponenst a jövőben.
Forrás: will.com