Leta 2017 smo zmagali na natečaju za razvoj transakcijskega jedra naložbenega poslovanja Alfa-Bank in začeli z delom (na HighLoad++ 2018 s poročilom o jedru naložbenega poslovanja Vladimir Drynkin, vodja transakcijskega jedra investicijskega poslovanja Alfa Bank). Ta sistem naj bi združeval transakcijske podatke iz različnih virov v različnih formatih, jih spravljal v enotno obliko, jih shranjeval in omogočal dostop do njih.
V procesu razvoja se je sistem razvijal in pridobival funkcionalnosti in na neki točki smo spoznali, da kristaliziramo nekaj veliko več kot le aplikativno programsko opremo, ustvarjeno za reševanje strogo določenega obsega nalog: uspelo nam je sistem za gradnjo porazdeljenih aplikacij s trajnim shranjevanjem. Pridobljene izkušnje so bile osnova za nov izdelek - (TDG).
Želim govoriti o arhitekturi TDG in rešitvah, do katerih smo prišli v procesu razvoja, vam predstaviti glavne funkcionalnosti in pokazati, kako lahko naš izdelek postane osnova za gradnjo celovitih rešitev.
Arhitekturno smo sistem razdelili na ločene vlogo, od katerih je vsak odgovoren za reševanje določenega obsega problemov. Posamezen primerek delujoče aplikacije izvaja eno ali več vrst vlog. V gruči je lahko več vlog iste vrste:
priključek
Connector je odgovoren za komunikacijo z zunanjim svetom; njegova naloga je sprejeti zahtevo, jo razčleniti in če to uspe, poslati podatke v obdelavo vhodnemu procesorju. Podpiramo formate HTTP, SOAP, Kafka, FIX. Arhitektura vam omogoča preprosto dodajanje podpore za nove formate, pri čemer bo kmalu na voljo podpora za IBM MQ. Če razčlenjevanje zahteve ni uspelo, bo konektor vrnil napako; v nasprotnem primeru bo odgovoril, da je bila zahteva uspešno obdelana, tudi če je pri nadaljnji obdelavi prišlo do napake. To je bilo storjeno posebej za delo s sistemi, ki ne vedo, kako ponavljati zahteve - ali, nasprotno, to počnejo preveč vztrajno. Da ne bi izgubili podatkov, se uporablja čakalna vrsta za popravilo: predmet najprej pride vanjo in šele po uspešni obdelavi se iz nje odstrani. Skrbnik lahko prejme opozorila o preostalih predmetih v čakalni vrsti za popravilo in po odpravi napake programske opreme ali okvare strojne opreme poskusi znova.
Vhodni procesor
Vhodni procesor razvrsti prejete podatke glede na značilnosti in prikliče ustrezne procesorje. Handlerji so koda Lua, ki teče v peskovniku, zato ne morejo vplivati na delovanje sistema. Na tej stopnji je mogoče podatke zmanjšati na zahtevano obliko in po potrebi zagnati poljubno število nalog, ki lahko izvajajo potrebno logiko. Na primer, v izdelku MDM (Master Data Management), zgrajenem na Tarantool Data Grid, ob dodajanju novega uporabnika, da ne upočasnimo obdelave zahteve, zaženemo ustvarjanje zlatega zapisa kot ločeno nalogo. Peskovnik podpira zahteve za branje, spreminjanje in dodajanje podatkov, omogoča izvajanje nekaterih funkcij na vseh vlogah vrste shranjevanja in združevanje rezultatov (preslikava/zmanjšanje).
Rokovniki so lahko opisani v datotekah:
sum.lua
local x, y = unpack(...)
return x + yIn potem, deklarirano v konfiguraciji:
functions:
sum: { __file: sum.lua }
Zakaj Lua? Lua je zelo preprost jezik. Po naših izkušnjah ljudje nekaj ur po tem, ko so ga spoznali, začnejo pisati kodo, ki rešuje njihov problem. In to niso samo profesionalni razvijalci, ampak na primer analitiki. Poleg tega Lua zaradi prevajalnika jit deluje zelo hitro.
skladiščenje
Shramba shranjuje obstojne podatke. Pred shranjevanjem se podatki preverijo glede na podatkovno shemo. Za opis vezja uporabljamo razširjeno obliko ... Primer:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Na podlagi tega opisa se DDL (Data Definition Language) samodejno ustvari za DBMS Tarantula in shema za dostop do podatkov.
Podprto je asinhrono podvajanje podatkov (obstajajo načrti za dodajanje sinhronega).
Izhodni procesor
Včasih je treba o prihodu novih podatkov obvestiti zunanje porabnike, za to obstaja vloga Izhodni procesor. Ko podatke shranite, jih lahko posredujete ustreznemu upravljavcu (na primer, da jih pripeljete v obliko, ki jo zahteva potrošnik) - in nato posredujete konektorju za pošiljanje. Tukaj se uporablja tudi čakalna vrsta za popravilo: če nihče ni sprejel predmeta, lahko skrbnik poskusi znova pozneje.
Skaliranje
Vloge konektorja, vhodnega procesorja in izhodnega procesorja so brez stanja, kar nam omogoča vodoravno prilagajanje sistema s preprostim dodajanjem novih primerkov aplikacije z omogočeno želeno vrsto vloge. Shramba se uporablja za horizontalno skaliranje organiziranju gruče z uporabo virtualnih veder. Po dodajanju novega strežnika se nekatera vedra iz starih strežnikov premaknejo na nov strežnik v ozadju; to se zgodi pregledno za uporabnike in ne vpliva na delovanje celotnega sistema.
Lastnosti podatkov
Predmeti so lahko zelo veliki in vsebujejo druge predmete. Zagotavljamo atomičnost dodajanja in posodabljanja podatkov s shranjevanjem predmeta z vsemi odvisnostmi v enem virtualnem vedru. To preprečuje, da bi bil predmet "razpršen" po več fizičnih strežnikih.
Podprto je vzdrževanje različic: vsaka posodobitev predmeta ustvari novo različico in vedno lahko vzamemo časovni izrez in vidimo, kako je svet izgledal takrat. Pri podatkih, ki ne potrebujejo dolge zgodovine, lahko omejimo število verzij ali celo shranimo samo eno - najnovejšo - torej v bistvu onemogočimo verzioniranje za določen tip. Zgodovino lahko tudi časovno omejite: na primer izbrišete vse predmete določene vrste, starejše od 1 leta. Podprto je tudi arhiviranje: odstranimo lahko objekte, starejše od določenega časa, in tako sprostimo prostor v gruči.
naloge
Med zanimivimi funkcijami velja omeniti možnost zagona opravil po urniku, na zahtevo uporabnika ali programsko iz peskovnika:
Tu vidimo še eno vlogo - tekač. Ta vloga je brez stanja in po potrebi je mogoče v gručo dodati dodatne primerke aplikacije s to vlogo. Tekačeva odgovornost je dokončanje nalog. Kot že omenjeno, je možno ustvariti nova opravila iz peskovnika; shranijo se v čakalno vrsto v pomnilniku in nato izvedejo v tekalniku. Ta vrsta naloge se imenuje Job. Imamo tudi vrsto opravil, imenovano Naloga – to so uporabniško definirana opravila, ki se izvajajo po urniku (z uporabo sintakse cron) ali na zahtevo. Za zagon in sledenje takim opravilom imamo priročen upravitelj opravil. Da bi bila ta funkcija na voljo, morate omogočiti vlogo razporejevalnika; ta vloga ima stanje, torej se ne meri, kar pa ni potrebno; hkrati pa ima lahko, kot vse druge vloge, repliko, ki začne delovati, če mojster nenadoma zavrne.
Drvar
Druga vloga se imenuje logger. Zbira dnevnike vseh članov gruče in ponuja vmesnik za nalaganje in ogled prek spletnega vmesnika.
Storitve
Omeniti velja, da sistem omogoča preprosto ustvarjanje storitev. V konfiguracijski datoteki lahko določite, katere zahteve se pošljejo uporabniško napisanemu upravljalniku, ki se izvaja v peskovniku. V tem upravljalniku lahko na primer zaženete nekakšno analitično poizvedbo in vrnete rezultat.
Storitev je opisana v konfiguracijski datoteki:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
GraphQL API se ustvari samodejno in storitev postane na voljo za klic:
query {
sum(x: 1, y: 2)
}
To bo poklicalo upravljalca sumki bo vrnil rezultat:
3
Profiliranje poizvedb in meritve
Za razumevanje delovanja sistema in profiliranja zahtev smo implementirali podporo za protokol OpenTracing. Sistem lahko na zahtevo pošlje informacije orodjem, ki podpirajo ta protokol, kot je Zipkin, kar vam bo omogočilo razumevanje, kako je bila zahteva izvedena:
Sistem seveda ponuja notranje meritve, ki jih je mogoče zbrati s Prometheusom in vizualizirati z Grafano.
Razporedi
Tarantool Data Grid je mogoče razmestiti iz paketov RPM ali arhiva, z uporabo pripomočka iz distribucije ali Ansible, obstaja tudi podpora za Kubernetes ().
Aplikacija, ki izvaja poslovno logiko (konfiguracija, upravljalniki), se naloži v nameščeno gručo Tarantool Data Grid v obliki arhiva prek uporabniškega vmesnika ali s pomočjo skripta prek API-ja, ki ga nudimo mi.
Vzorci aplikacij
Katere aplikacije je mogoče ustvariti z uporabo Tarantool Data Grid? Pravzaprav je večina poslovnih nalog nekako povezanih z obdelavo, shranjevanjem in dostopanjem do pretoka podatkov. Če imate torej velike tokove podatkov, ki jih je treba varno shraniti in dostopati do njih, vam lahko naš izdelek prihrani veliko časa pri razvoju in se osredotoči na vašo poslovno logiko.
Želimo na primer zbirati informacije o nepremičninskem trgu, da bomo v prihodnosti na primer imeli informacije o najboljših ponudbah. V tem primeru bomo izpostavili naslednje naloge:
- Naši viri podatkov bodo roboti, ki zbirajo informacije iz odprtih virov. To težavo lahko rešite z že pripravljenimi rešitvami ali pisanjem kode v katerem koli jeziku.
- Nato bo Tarantool Data Grid sprejel in shranil podatke. Če je format podatkov iz različnih virov drugačen, potem lahko v Lua napišete kodo, ki bo izvedla pretvorbo v en sam format. V fazi predhodne obdelave boste lahko na primer tudi filtrirali podvojene ponudbe ali dodatno posodobili podatke o agentih, ki delujejo na trgu v bazi podatkov.
- Zdaj že imate razširljivo rešitev v gruči, ki jo je mogoče napolniti s podatki in izbirati podatke. Nato lahko implementirate novo funkcionalnost, na primer napišete storitev, ki bo zahtevala podatke in dala najugodnejšo ponudbo na dan – to bo zahtevalo nekaj vrstic v konfiguracijski datoteki in malo kode Lua.
Kaj sledi?
Naša prednostna naloga je izboljšati enostavnost uporabe pri razvoju . To je na primer IDE s podporo za profiliranje in odpravljanje napak, ki se izvajajo v peskovniku.
Veliko pozornost namenjamo tudi varnostnim vprašanjem. Prav zdaj smo v fazi certificiranja pri FSTEC Rusije, da potrdimo visoko raven varnosti in izpolnimo zahteve za certificiranje programskih izdelkov, ki se uporabljajo v informacijskih sistemih osebnih podatkov in državnih informacijskih sistemih.
Vir: www.habr.com