2017-ben megnyertük az Alfa-Bank befektetési üzletágának tranzakciós magjának fejlesztésére kiírt pályázatot, és megkezdtük a munkát (a HighLoad++ 2018-ban a befektetési üzletág magjáról szóló beszámolóval Vladimir Drynkin, az Alfa Bank befektetési üzletágának tranzakciós magjának vezetője). Ennek a rendszernek a különböző forrásokból származó tranzakciós adatokat különböző formátumokban kellett összesítenie, egységes formába hozni, tárolni és hozzáférést biztosítani.
A fejlesztési folyamat során a rendszer fejlődött, funkcionalitást szerzett, és egy ponton rájöttünk, hogy sokkal többet kristályosítunk ki, mint egy szigorúan meghatározott feladatkör megoldására létrehozott alkalmazásszoftvert: sikerült rendszer állandó tárhellyel rendelkező elosztott alkalmazások építésére. A megszerzett tapasztalataink egy új termék alapját képezték - (TDG).
Szeretnék beszélni a TDG architektúráról és azokról a megoldásokról, amelyekhez a fejlesztési folyamat során eljutottunk, bemutatni a főbb funkciókat, és megmutatni, hogyan válhat termékünk a teljes megoldások építésének alapjává.
Építészetileg külön részekre osztottuk a rendszert szerepek, amelyek mindegyike egy bizonyos problémakör megoldásáért felelős. Egyetlen futó alkalmazáspéldány egy vagy több szerepkörtípust valósít meg. Egy fürtben több azonos típusú szerep is lehet:
Connector
A Connector felelős a külvilággal való kommunikációért; feladata a kérés elfogadása, elemzése, és ha ez sikerül, akkor az adatokat feldolgozásra elküldi a beviteli feldolgozónak. Támogatjuk a HTTP, SOAP, Kafka, FIX formátumokat. Az architektúra lehetővé teszi, hogy egyszerűen hozzáadja az új formátumok támogatását, és hamarosan megjelenik az IBM MQ támogatása is. Ha a kérés elemzése nem sikerült, az összekötő hibát ad vissza; ellenkező esetben azt válaszolja, hogy a kérés feldolgozása sikeres volt, még akkor is, ha a további feldolgozás során hiba történt. Ezt kifejezetten azért tették, hogy olyan rendszerekkel dolgozzanak, amelyek nem tudják, hogyan kell megismételni a kéréseket - vagy éppen ellenkezőleg, túl kitartóan teszik ezt. Az adatok elvesztésének elkerülése érdekében javítósort használnak: az objektum először bekerül, és csak a sikeres feldolgozás után távolítják el onnan. Az adminisztrátor riasztásokat kaphat a javítási sorban maradt objektumokról, és a szoftver- vagy hardverhiba elhárítása után próbálkozzon újra.
Bemeneti processzor
A bemeneti processzor a kapott adatokat jellemző tulajdonságok szerint osztályozza, és megfelelő processzorokat hív meg. A kezelők olyan Lua kódok, amelyek homokozóban futnak, így nem befolyásolhatják a rendszer működését. Ebben a szakaszban az adatokat a kívánt formára lehet redukálni, és szükség esetén tetszőleges számú feladatot lehet elindítani, amelyek megvalósíthatják a szükséges logikát. Például a Tarantool Data Gridre épített MDM (Master Data Management) termékben új felhasználó felvételekor, hogy ne lassítsuk a kérés feldolgozását, külön feladatként elindítjuk az aranyrekord készítését. A sandbox támogatja az adatok olvasására, módosítására és hozzáadására vonatkozó kéréseket, lehetővé teszi bizonyos funkciók végrehajtását a tárolótípus összes szerepén és az eredmény összesítését (leképezés/kicsinyítés).
A kezelőket fájlokban lehet leírni:
sum.lua
local x, y = unpack(...)
return x + yAztán a konfigurációban deklarálva:
functions:
sum: { __file: sum.lua }
Miért Lua? A lua egy nagyon egyszerű nyelv. Tapasztalataink alapján a megismerés után pár órával az emberek elkezdenek olyan kódot írni, ami megoldja a problémájukat. És ezek nem csak professzionális fejlesztők, hanem például elemzők. Ráadásul a jit fordítónak köszönhetően a Lua nagyon gyorsan fut.
Tárolás
A tároló állandó adatokat tárol. Mentés előtt az adatokat az adatséma alapján ellenőrzik. Az áramkör leírására kiterjesztett formátumot használunk ... Példa:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}A leírás alapján a DDL (Data Definition Language) automatikusan generálódik a Tarantula DBMS és adathozzáférési séma.
Az aszinkron adatreplikáció támogatott (tervek vannak szinkron hozzáadására).
Kimeneti processzor
Időnként szükség van a külső fogyasztók értesítésére az új adatok érkezéséről, erre a célra van a Kimeneti feldolgozó szerep. Az adatok mentése után továbbíthatók a megfelelő kezelőhöz (például a fogyasztó által igényelt formára hozva) - majd továbbíthatók a csatlakozóhoz küldésre. Itt javítási sor is használatos: ha senki nem fogadta el az objektumot, a rendszergazda később újra próbálkozhat.
Méretezés
A csatlakozó, a bemeneti processzor és a kimeneti processzor szerepkörei állapot nélküliek, lehetővé téve a rendszer vízszintes méretezését azáltal, hogy egyszerűen hozzáadunk új alkalmazáspéldányokat a kívánt szerepkörtípussal. A tárolás a vízszintes méretezéshez használatos fürt megszervezéséhez virtuális vödrök segítségével. Új szerver hozzáadása után a régi szerverek gyűjtőhelyeinek egy része a háttérben átkerül az új szerverre; ez a felhasználók számára átláthatóan történik, és nem befolyásolja a teljes rendszer működését.
Adattulajdonságok
Az objektumok nagyon nagyok lehetnek, és más objektumokat is tartalmazhatnak. Az adatok hozzáadásának és frissítésének atomiitását úgy biztosítjuk, hogy egy objektumot minden függőséggel egy virtuális vödörben tárolunk. Ez megakadályozza, hogy az objektum „terjedjen” több fizikai szerverre.
A verziószámítás támogatott: egy objektum minden frissítése új verziót hoz létre, és bármikor megtekinthetjük, hogyan nézett ki a világ akkoriban. A hosszú előzményt nem igénylő adatoknál korlátozhatjuk a verziók számát, vagy akár csak egyet - a legújabbat - tárolhatunk, vagyis lényegében letilthatjuk egy bizonyos típus verziószámát. Az előzményeket idő szerint is korlátozhatja: például töröljön egy bizonyos típusú, 1 évnél régebbi objektumot. Az archiválás is támogatott: a megadott időnél régebbi objektumokat kirakhatjuk, így helyet szabadítunk fel a klaszterben.
feladatok
Az érdekes funkciók közül érdemes megemlíteni, hogy a feladatok ütemezetten, a felhasználó kérésére vagy programozottan a sandboxból indíthatók:
Itt egy másik szerepet látunk - futó. Ez a szerepkör állapot nélküli, és szükség szerint további alkalmazáspéldányok is hozzáadhatók a fürthöz ezzel a szerepkörrel. A futó felelőssége a feladatok elvégzése. Mint említettük, lehetőség van új feladatok generálására a sandboxból; egy sorba kerülnek a tárhelyen, majd a futón végrehajtódnak. Ezt a fajta feladatot munkának nevezik. Van egy Task nevű feladattípusunk is – ezek a felhasználó által meghatározott feladatok, amelyek ütemezetten (cron szintaxissal) vagy igény szerint futnak. Az ilyen feladatok elindításához és követéséhez kényelmes feladatkezelőnk van. Ahhoz, hogy ez a funkció elérhető legyen, engedélyeznie kell az ütemező szerepkört; ennek a szerepnek van állapota, tehát nem skálázódik, ami azonban nem szükséges; ugyanakkor, mint minden más szerepnek, ennek is lehet egy replikája, amely működésbe lép, ha a mester hirtelen visszautasítja.
Naplók
Egy másik szerep a logger. A fürt összes tagjáról összegyűjti a naplókat, és felületet biztosít azok webes felületen keresztüli feltöltéséhez és megtekintéséhez.
Szolgáltatások
Érdemes megemlíteni, hogy a rendszer megkönnyíti a szolgáltatások létrehozását. A konfigurációs fájlban megadhatja, hogy mely kérések legyenek elküldve a sandboxban futó, felhasználó által írt kezelőnek. Ebben a kezelőben például lefuttathat valamilyen elemző lekérdezést, és visszaadhatja az eredményt.
A szolgáltatás leírása a konfigurációs fájlban található:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
A GraphQL API automatikusan generálódik, és a szolgáltatás elérhetővé válik a következő híváshoz:
query {
sum(x: 1, y: 2)
}
Ez felhívja a kezelőt sumami visszaadja az eredményt:
3
Lekérdezés profilozása és mérőszámai
A rendszer működésének és a profilalkotási kéréseknek a megértése érdekében bevezettük az OpenTracing protokoll támogatását. A rendszer kérésre információkat küldhet olyan eszközöknek, amelyek támogatják ezt a protokollt, mint például a Zipkin, amely lehetővé teszi a kérés végrehajtásának megértését:
A rendszer természetesen olyan belső mérőszámokat biztosít, amelyek a Prometheus segítségével gyűjthetők és a Grafana segítségével vizualizálhatók.
Telepítés
A Tarantool Data Grid telepíthető RPM-csomagokból vagy archívumból, a disztribúció vagy az Ansible segédprogramjával, a Kubernetes ().
Az üzleti logikát (konfigurációt, kezelőket) megvalósító alkalmazás archív formában a felhasználói felületen keresztül, vagy az általunk biztosított API-n keresztül script segítségével betöltődik a telepített Tarantool Data Grid klaszterbe.
Mintaalkalmazások
Milyen alkalmazásokat lehet létrehozni a Tarantool Data Grid segítségével? Valójában a legtöbb üzleti feladat valamilyen módon kapcsolódik az adatfolyam feldolgozásához, tárolásához és eléréséhez. Ezért ha nagy adatfolyamokkal rendelkezik, amelyeket biztonságosan kell tárolni és elérni, akkor termékünk sok fejlesztési időt takaríthat meg, és az üzleti logikára összpontosíthat.
Például szeretnénk információkat gyűjteni az ingatlanpiacról, hogy a jövőben például a legjobb ajánlatokról legyen információnk. Ebben az esetben a következő feladatokat emeljük ki:
- A nyílt forrásokból információkat gyűjtő robotok lesznek az adatforrásaink. Ezt a problémát kész megoldásokkal vagy bármilyen nyelvű kód írásával megoldhatja.
- Ezután a Tarantool Data Grid elfogadja és elmenti az adatokat. Ha a különböző forrásokból származó adatformátum eltérő, akkor Lua-ban írhat kódot, amely egyetlen formátumba konvertálja. Az előfeldolgozási szakaszban például kiszűrheti a duplikált ajánlatokat, vagy frissítheti a piacon dolgozó ügynökök információit az adatbázisban.
- Most már van egy méretezhető megoldása egy fürtben, amely feltölthető adatokkal és adatkijelöléseket végezhet. Ezután új funkcionalitást implementálhat, például írhat egy szolgáltatást, amely lekéri az adatokat és a legelőnyösebb ajánlatot adja naponta - ehhez néhány sorra lesz szüksége a konfigurációs fájlban és egy kis Lua kódra.
Mi a következő lépés?
Kiemelt feladatunk a fejlesztés használatának megkönnyítése . Ez például egy olyan IDE, amely támogatja a homokozóban futó profilalkotási és hibakereső kezelőket.
Nagy figyelmet fordítunk a biztonsági kérdésekre is. Jelenleg az orosz FSTEC tanúsításán megyünk keresztül, amely megerősíti a magas szintű biztonságot és megfelel a személyes adatok információs rendszereiben és a kormányzati információs rendszerekben használt szoftvertermékek tanúsítási követelményeinek.
Forrás: will.com