În 2017, am câștigat un concurs pentru dezvoltarea nucleului tranzacțional al afacerii de investiții a Alfa-Bank și am început lucrul (la HighLoad++ 2018 cu un raport despre nucleul afacerii de investiții Vladimir Drynkin, șeful nucleului tranzacțional al afacerii de investiții a Alfa Bank). Acest sistem trebuia să agregă datele tranzacțiilor din diferite surse în diferite formate, să aducă datele într-o formă unificată, să le stocheze și să ofere acces la ele.
În timpul procesului de dezvoltare, sistemul a evoluat și a dobândit funcționalitate, iar la un moment dat ne-am dat seama că cristalizăm ceva mult mai mult decât doar aplicații software create pentru a rezolva o gamă strict definită de sarcini: am reușit. sistem pentru construirea de aplicații distribuite cu stocare persistentă. Experiența pe care am dobândit-o a stat la baza unui nou produs - (TDG).
Vreau să vorbesc despre arhitectura TDG și soluțiile la care am ajuns în timpul procesului de dezvoltare, să vă prezint principalele funcționalități și să vă arăt cum produsul nostru poate deveni baza pentru construirea de soluții complete.
Din punct de vedere arhitectural, am împărțit sistemul în separat rol, fiecare dintre acestea fiind responsabil pentru rezolvarea unei anumite game de probleme. O singură instanță de aplicație care rulează implementează unul sau mai multe tipuri de rol. Într-un cluster pot exista mai multe roluri de același tip:
Conector
Connector este responsabil pentru comunicarea cu lumea exterioară; sarcina sa este să accepte cererea, să o analizeze și, dacă aceasta reușește, să trimită datele pentru procesare către procesorul de intrare. Suportăm formatele HTTP, SOAP, Kafka, FIX. Arhitectura vă permite să adăugați pur și simplu suport pentru noile formate, iar suportul pentru IBM MQ va veni în curând. Dacă analizarea cererii a eșuat, conectorul va returna o eroare; în caz contrar, va răspunde că cererea a fost procesată cu succes, chiar dacă a apărut o eroare în timpul procesării ulterioare a acesteia. Acest lucru a fost făcut special pentru a lucra cu sisteme care nu știu să repete solicitările - sau, dimpotrivă, o fac prea persistent. Pentru a nu pierde date, se folosește o coadă de reparații: obiectul intră mai întâi în el și numai după ce procesarea cu succes este eliminată din el. Administratorul poate primi alerte despre obiectele rămase în coada de reparații și, după eliminarea unei erori software sau a unei defecțiuni hardware, încercați din nou.
Procesor de intrare
Procesorul de intrare clasifică datele primite în funcție de caracteristicile caracteristice și apelează procesoarele adecvate. Handler-urile sunt cod Lua care rulează într-un sandbox, deci nu pot afecta funcționarea sistemului. În această etapă, datele pot fi reduse la forma necesară și, dacă este necesar, poate fi lansat un număr arbitrar de sarcini care pot implementa logica necesară. De exemplu, în produsul MDM (Master Data Management) construit pe Tarantool Data Grid, la adăugarea unui nou utilizator, pentru a nu încetini procesarea cererii, lansăm crearea unui record de aur ca sarcină separată. Sandbox-ul acceptă solicitări de citire, modificare și adăugare de date, vă permite să efectuați o anumită funcție pe toate rolurile tipului de stocare și agregarea rezultatului (hartă/reducere).
Manipulatorii pot fi descriși în fișiere:
sum.lua
local x, y = unpack(...)
return x + yȘi apoi, declarat în configurație:
functions:
sum: { __file: sum.lua }
De ce Lua? Lua este un limbaj foarte simplu. Pe baza experienței noastre, la câteva ore după ce l-au cunoscut, oamenii încep să scrie cod care le rezolvă problema. Și aceștia nu sunt doar dezvoltatori profesioniști, ci, de exemplu, analiști. În plus, datorită compilatorului jit, Lua rulează foarte repede.
Depozitare
Stocarea stochează date persistente. Înainte de salvare, datele sunt validate în raport cu schema de date. Pentru a descrie circuitul folosim un format extins ... Exemplu:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Pe baza acestei descrieri, DDL (Data Definition Language) este generat automat pentru DBMS-ul Tarantula și schema de acces la date.
Replicarea asincronă a datelor este acceptată (există planuri de adăugare a uneia sincrone).
Procesor de ieșire
Uneori este necesar să se informeze consumatorii externi despre sosirea de date noi; în acest scop, există rolul Procesor de ieșire. După salvarea datelor, acestea pot fi transmise handler-ului corespunzător (de exemplu, pentru a le aduce la forma cerută de consumator) - și apoi transmisă conectorului pentru trimitere. Aici se folosește și o coadă de reparații: dacă nimeni nu a acceptat obiectul, administratorul poate încerca din nou mai târziu.
Scalare
Rolurile conectorului, procesorului de intrare și procesorului de ieșire sunt apatride, permițându-ne să scalam sistemul pe orizontală prin simpla adăugare de noi instanțe de aplicație cu tipul de rol dorit activat. Stocarea este utilizată pentru scalarea orizontală la organizarea unui cluster folosind găleți virtuale. După adăugarea unui nou server, unele dintre gălețile de pe serverele vechi sunt mutate pe noul server în fundal; acest lucru se întâmplă în mod transparent utilizatorilor și nu afectează funcționarea întregului sistem.
Proprietățile datelor
Obiectele pot fi foarte mari și pot conține alte obiecte. Asigurăm atomismul adăugării și actualizării datelor prin stocarea unui obiect cu toate dependențele într-o singură găleată virtuală. Acest lucru împiedică obiectul să fie „împrăștiat” pe mai multe servere fizice.
Versiunea este acceptată: fiecare actualizare a unui obiect creează o nouă versiune și putem oricând să luăm o secțiune de timp și să vedem cum arăta lumea atunci. Pentru datele care nu au nevoie de un istoric lung, putem limita numărul de versiuni sau chiar stocăm doar una - cea mai recentă - adică, în esență, dezactivăm versiunile pentru un anumit tip. De asemenea, puteți limita istoricul în funcție de timp: de exemplu, ștergeți toate obiectele de un anumit tip mai vechi de 1 an. Arhivarea este, de asemenea, acceptată: putem descărca obiecte mai vechi decât timpul specificat, eliberând spațiu în cluster.
sarcini
Printre caracteristicile interesante, merită remarcată capacitatea de a lansa sarcini într-un program, la cererea utilizatorului sau în mod programatic din sandbox:
Aici vedem un alt rol - alergător. Acest rol este apatrid, iar instanțe de aplicație suplimentare cu acest rol pot fi adăugate la cluster după cum este necesar. Responsabilitatea alergătorului este de a îndeplini sarcinile. După cum am menționat, este posibil să generați noi sarcini din sandbox; sunt salvate într-o coadă de stocare și apoi executate pe alergător. Acest tip de sarcină se numește Iov. Avem, de asemenea, un tip de sarcină numit Sarcină - acestea sunt sarcini definite de utilizator care rulează conform unui program (folosind sintaxa cron) sau la cerere. Pentru a lansa și urmări astfel de sarcini, avem un manager de sarcini convenabil. Pentru ca această funcționalitate să fie disponibilă, trebuie să activați rolul de planificator; acest rol are o stare, deci nu se scala, ceea ce, insa, nu este necesar; în același timp, ca toate celelalte roluri, poate avea o replică care începe să funcționeze dacă maestrul refuză brusc.
Logger
Un alt rol se numește logger. Acesta colectează jurnalele de la toți membrii clusterului și oferă o interfață pentru încărcarea și vizualizarea acestora prin interfața web.
Servicii
Merită menționat faptul că sistemul facilitează crearea de servicii. În fișierul de configurare, puteți specifica ce solicitări sunt trimise unui handler scris de utilizator care rulează în sandbox. În acest handler, puteți, de exemplu, să rulați un fel de interogare analitică și să returnați rezultatul.
Serviciul este descris în fișierul de configurare:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
API-ul GraphQL este generat automat și serviciul devine disponibil pentru apelare:
query {
sum(x: 1, y: 2)
}
Acest lucru îl va apela pe handler sumcare va returna rezultatul:
3
Profilarea interogărilor și valorile
Pentru a înțelege funcționarea sistemului și solicitările de profilare, am implementat suport pentru protocolul OpenTracing. Sistemul poate trimite informații la cerere către instrumente care acceptă acest protocol, cum ar fi Zipkin, ceea ce vă va permite să înțelegeți cum a fost executată cererea:
Desigur, sistemul oferă valori interne care pot fi colectate folosind Prometheus și vizualizate folosind Grafana.
Implementează
Tarantool Data Grid poate fi implementat din pachete RPM sau dintr-o arhivă, folosind un utilitar din distribuție sau Ansible, există și suport pentru Kubernetes ().
Aplicația care implementează logica de business (configurare, handlere) este încărcată în clusterul Tarantool Data Grid implementat sub forma unei arhive prin UI sau folosind un script prin API-ul furnizat de noi.
Exemple de aplicații
Ce aplicații pot fi create folosind Tarantool Data Grid? De fapt, majoritatea sarcinilor de afaceri sunt oarecum legate de procesarea, stocarea și accesarea fluxului de date. Prin urmare, dacă aveți fluxuri mari de date care trebuie să fie stocate și accesate în siguranță, atunci produsul nostru vă poate economisi mult timp de dezvoltare și vă poate concentra pe logica dvs. de afaceri.
De exemplu, dorim să colectăm informații despre piața imobiliară, astfel încât pe viitor, de exemplu, să avem informații despre cele mai bune oferte. În acest caz, vom evidenția următoarele sarcini:
- Roboții care colectează informații din surse deschise vor fi sursele noastre de date. Puteți rezolva această problemă folosind soluții gata făcute sau scriind cod în orice limbă.
- Apoi, Tarantool Data Grid va accepta și salva datele. Dacă formatul de date din diferite surse este diferit, atunci puteți scrie cod în Lua care va efectua conversia într-un singur format. În etapa de preprocesare, veți putea, de asemenea, să filtrați oferte duplicate sau să actualizați suplimentar informații despre agenții care lucrează pe piață în baza de date.
- Acum aveți deja o soluție scalabilă într-un cluster care poate fi umplut cu date și poate face selecții de date. Apoi puteți implementa o nouă funcționalitate, de exemplu, scrieți un serviciu care va face o cerere de date și va oferi cea mai avantajoasă ofertă pe zi - acest lucru va necesita câteva rânduri în fișierul de configurare și puțin cod Lua.
Ce urmeaza?
Prioritatea noastră este să îmbunătățim ușurința dezvoltării utilizării . De exemplu, acesta este un IDE cu suport pentru manipulatorii de profilare și depanare care rulează într-un sandbox.
De asemenea, acordăm o mare atenție problemelor de siguranță. În prezent, suntem în curs de certificare de către FSTEC din Rusia pentru a confirma nivelul înalt de securitate și pentru a îndeplini cerințele de certificare a produselor software utilizate în sistemele de informații cu date personale și sistemele de informații guvernamentale.
Sursa: www.habr.com