V roku 2017 sme vyhrali súťaž na rozvoj transakčného jadra investičného biznisu Alfa-Bank a začali sme pracovať (na HighLoad++ 2018 so správou o jadre investičného biznisu Vladimir Drynkin, vedúci transakčného jadra investičného podnikania Alfa Bank). Tento systém mal agregovať transakčné dáta z rôznych zdrojov v rôznych formátoch, prinášať dáta do jednotnej podoby, uchovávať ich a poskytovať k nim prístup.
Počas vývojového procesu sa systém vyvíjal a získaval funkčnosť a v určitom bode sme si uvedomili, že kryštalizujeme niečo oveľa viac než len aplikačný softvér vytvorený na riešenie presne definovaného okruhu problémov: podarilo sa nám to systém na vytváranie distribuovaných aplikácií s trvalým ukladaním. Skúsenosti, ktoré sme získali, tvorili základ nového produktu – (TDG).
Chcem hovoriť o architektúre TDG a riešeniach, ku ktorým sme dospeli počas procesu vývoja, predstaviť vám hlavnú funkcionalitu a ukázať, ako sa náš produkt môže stať základom pre budovanie kompletných riešení.
Architektonicky sme systém rozdelili na samostatné rolí, z ktorých každý je zodpovedný za riešenie určitého okruhu problémov. Jedna inštancia spustenej aplikácie implementuje jeden alebo viac typov rolí. V klastri môže byť niekoľko rolí rovnakého typu:
konektor
Connector je zodpovedný za komunikáciu s vonkajším svetom; jeho úlohou je prijať požiadavku, analyzovať ju a ak sa to podarí, odoslať dáta na spracovanie vstupnému procesoru. Podporujeme formáty HTTP, SOAP, Kafka, FIX. Architektúra vám umožňuje jednoducho pridať podporu pre nové formáty, pričom podpora pre IBM MQ príde čoskoro. Ak analýza požiadavky zlyhá, konektor vráti chybu; v opačnom prípade odpovie, že požiadavka bola úspešne vybavená, aj keď pri jej ďalšom spracovaní došlo k chybe. Bolo to urobené špeciálne kvôli práci so systémami, ktoré nevedia opakovať požiadavky - alebo naopak, robia to príliš vytrvalo. Aby sa nestratili údaje, používa sa front na opravu: objekt sa do neho najskôr dostane a až po úspešnom spracovaní sa z neho odstráni. Administrátor môže dostávať upozornenia na objekty zostávajúce vo fronte opráv a po odstránení softvérovej chyby alebo zlyhania hardvéru to skúste znova.
Vstupný procesor
Vstupný procesor klasifikuje prijaté dáta podľa charakteristických vlastností a volá príslušné procesory. Obslužné programy sú kód Lua, ktorý beží v karanténe, takže nemôžu ovplyvniť fungovanie systému. V tejto fáze je možné údaje zredukovať na požadovanú formu a v prípade potreby spustiť ľubovoľný počet úloh, ktoré dokážu implementovať potrebnú logiku. Napríklad v produkte MDM (Master Data Management) postavenom na Tarantool Data Grid pri pridávaní nového používateľa, aby sa nespomalilo spracovanie požiadavky, spúšťame vytváranie zlatého záznamu ako samostatnú úlohu. Sandbox podporuje požiadavky na čítanie, zmenu a pridávanie údajov, umožňuje vykonávať niektoré funkcie na všetkých rolách typu úložiska a agregovať výsledok (mapovať/zmenšiť).
Manipulátory môžu byť opísané v súboroch:
sum.lua
local x, y = unpack(...)
return x + yA potom deklarované v konfigurácii:
functions:
sum: { __file: sum.lua }
Prečo Lua? Lua je veľmi jednoduchý jazyk. Na základe našich skúseností, pár hodín po tom, čo sa s tým zoznámia, ľudia začnú písať kód, ktorý vyrieši ich problém. A to nie sú len profesionálni vývojári, ale napríklad aj analytici. Navyše vďaka kompilátoru jit beží Lua veľmi rýchlo.
Uskladnenie
Úložisko uchováva trvalé údaje. Pred uložením sa údaje overia podľa dátovej schémy. Na popis obvodu používame rozšírený formát ... Príklad:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Na základe tohto popisu sa automaticky vygeneruje DDL (Data Definition Language) pre databázový systém Tarantula a schému prístupu k údajom.
Podporuje sa asynchrónna replikácia údajov (plánuje sa pridať synchrónnu).
Výstupný procesor
Niekedy je potrebné upozorniť externých spotrebiteľov na príchod nových dát, na tento účel je tu rola Výstupný procesor. Po uložení údajov môžu byť odovzdané príslušnému spracovateľovi (napríklad, aby boli privedené do formulára požadovaného spotrebiteľom) - a potom odovzdané konektoru na odoslanie. Tu sa tiež používa front na opravu: ak nikto neprijal objekt, správca to môže skúsiť znova neskôr.
Škálovanie
Roly konektora, vstupného procesora a výstupného procesora sú bezstavové, čo nám umožňuje horizontálne škálovať systém jednoduchým pridávaním nových inštancií aplikácie s povoleným požadovaným typom roly. Úložisko sa používa na horizontálne škálovanie na organizovanie klastra pomocou virtuálnych bucketov. Po pridaní nového servera sa niektoré buckety zo starých serverov presunú na nový server na pozadí; deje sa to transparentne pre používateľov a neovplyvňuje to chod celého systému.
Vlastnosti údajov
Objekty môžu byť veľmi veľké a môžu obsahovať ďalšie objekty. Atómickosť pridávania a aktualizácie dát zabezpečujeme uložením objektu so všetkými závislosťami do jedného virtuálneho vedra. To zabraňuje tomu, aby sa objekt „rozložil“ na niekoľko fyzických serverov.
Verzia je podporovaná: každá aktualizácia objektu vytvorí novú verziu a vždy si môžeme vziať časový úsek a zistiť, ako vtedy svet vyzeral. Pre dáta, ktoré nepotrebujú dlhú históriu, môžeme obmedziť počet verzií alebo dokonca uložiť len jednu – najnovšiu – teda v podstate zakázať verzovanie pre určitý typ. Históriu môžete obmedziť aj časovo: napríklad vymazať všetky objekty určitého typu staršie ako 1 rok. Podporovaná je aj archivácia: môžeme uvoľniť objekty staršie ako zadaný čas, čím sa uvoľní miesto v klastri.
úlohy
Medzi zaujímavé funkcie stojí za zmienku schopnosť spúšťať úlohy podľa plánu, na žiadosť používateľa alebo programovo z karantény:
Tu vidíme ďalšiu rolu – bežca. Táto rola je bezstavová a podľa potreby možno do klastra pridať ďalšie inštancie aplikácie s touto rolou. Zodpovednosťou bežca je plniť úlohy. Ako už bolo spomenuté, zo sandboxu je možné generovať nové úlohy; uložia sa do frontu v úložisku a potom sa vykonajú na bežeckom zariadení. Tento typ úlohy sa nazýva Job. Máme tiež typ úlohy nazývaný Task – ide o používateľom definované úlohy, ktoré sa spúšťajú podľa plánu (pomocou syntaxe cron) alebo na požiadanie. Na spustenie a sledovanie takýchto úloh máme pohodlného správcu úloh. Aby bola táto funkcia dostupná, musíte povoliť rolu plánovača; táto rola má stav, teda neškáluje, čo sa však nevyžaduje; zároveň, ako všetky ostatné roly, môže mať repliku, ktorá začne fungovať, ak majster náhle odmietne.
logger
Ďalšia úloha sa nazýva logger. Zhromažďuje protokoly od všetkých členov klastra a poskytuje rozhranie na ich nahrávanie a prezeranie cez webové rozhranie.
Služby
Za zmienku stojí, že systém uľahčuje vytváranie služieb. V konfiguračnom súbore môžete určiť, ktoré požiadavky sa odošlú používateľmi napísanému obslužnému programu, ktorý beží v karanténe. V tomto obslužnom programe môžete napríklad spustiť nejaký analytický dotaz a vrátiť výsledok.
Služba je popísaná v konfiguračnom súbore:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
Rozhranie GraphQL API sa generuje automaticky a služba je dostupná na volanie:
query {
sum(x: 1, y: 2)
}
Toto zavolá psovoda sumktorý vráti výsledok:
3
Profilovanie dopytov a metriky
Na pochopenie fungovania systému a požiadaviek na profilovanie sme implementovali podporu protokolu OpenTracing. Systém môže na požiadanie odoslať informácie nástrojom, ktoré podporujú tento protokol, ako je napríklad Zipkin, čo vám umožní pochopiť, ako bola požiadavka vykonaná:
Prirodzene, systém poskytuje interné metriky, ktoré je možné zbierať pomocou Prometheus a vizualizovať pomocou Grafany.
Nasadiť
Tarantool Data Grid je možné nasadiť z RPM balíčkov alebo archívu, pomocou utility z distribúcie alebo Ansible, nechýba ani podpora pre Kubernetes ().
Aplikácia, ktorá implementuje obchodnú logiku (konfigurácia, handlery) sa načíta do nasadeného klastra Tarantool Data Grid formou archívu cez UI alebo pomocou skriptu cez nami poskytnuté API.
Vzorové aplikácie
Aké aplikácie je možné vytvoriť pomocou Tarantool Data Grid? V skutočnosti väčšina obchodných úloh nejakým spôsobom súvisí so spracovaním, ukladaním a prístupom k toku údajov. Preto, ak máte veľké toky údajov, ktoré je potrebné bezpečne uložiť a pristupovať k nim, potom vám náš produkt môže ušetriť veľa času na vývoj a zamerať sa na vašu obchodnú logiku.
Chceme napríklad zbierať informácie o realitnom trhu, aby sme v budúcnosti mali napríklad informácie o najlepších ponukách. V tomto prípade zdôrazníme nasledujúce úlohy:
- Našimi zdrojmi údajov budú roboty, ktoré zhromažďujú informácie z otvorených zdrojov. Tento problém môžete vyriešiť pomocou hotových riešení alebo napísaním kódu v akomkoľvek jazyku.
- Potom Tarantool Data Grid prijme a uloží údaje. Ak je formát údajov z rôznych zdrojov odlišný, môžete napísať kód v Lua, ktorý vykoná konverziu do jedného formátu. Vo fáze predspracovania budete môcť napríklad aj filtrovať duplicitné ponuky alebo dodatočne aktualizovať informácie o agentoch pôsobiacich na trhu v databáze.
- Teraz už máte škálovateľné riešenie v klastri, ktoré možno naplniť údajmi a vykonať výber údajov. Potom môžete implementovať novú funkcionalitu, napríklad napísať službu, ktorá požiada o dáta a poskytne najvýhodnejšiu ponuku za deň - bude to vyžadovať niekoľko riadkov v konfiguračnom súbore a trochu kódu Lua.
Čo bude ďalej?
Našou prioritou je zlepšiť jednoduchosť používania pri vývoji . Ide napríklad o IDE s podporou obslužných programov profilovania a ladenia spustených v karanténe.
Veľkú pozornosť venujeme aj otázkam bezpečnosti. Práve teraz prechádzame certifikáciou ruskou spoločnosťou FSTEC, aby sme potvrdili vysokú úroveň bezpečnosti a splnili požiadavky na certifikáciu softvérových produktov používaných v informačných systémoch osobných údajov a vládnych informačných systémoch.
Zdroj: hab.com