El 2017, vam guanyar un concurs per desenvolupar el nucli transaccional del negoci d'inversió d'Alfa-Bank i vam començar a treballar (a HighLoad++ 2018 amb un informe sobre el nucli del negoci d'inversió Vladimir Drynkin, cap del nucli de transaccions del negoci d'inversió d'Alfa Bank). Aquest sistema havia d'agregar dades de transaccions de diferents fonts en diversos formats, reunir les dades en una forma unificada, emmagatzemar-les i proporcionar-hi accés.
Durant el procés de desenvolupament, el sistema va evolucionar i va adquirir funcionalitat, i en algun moment ens vam adonar que estàvem cristal·litzant quelcom molt més que un programari d'aplicació creat per resoldre una sèrie de tasques estrictament definides: ho vam aconseguir. sistema per crear aplicacions distribuïdes amb emmagatzematge persistent. L'experiència adquirida va ser la base d'un nou producte: (TDG).
Vull parlar de l'arquitectura TDG i de les solucions a les quals vam arribar durant el procés de desenvolupament, presentar-vos la funcionalitat principal i mostrar com el nostre producte pot esdevenir la base per construir solucions completes.
Arquitectònicament, vam dividir el sistema en separats paper, cadascun dels quals s'encarrega de resoldre un determinat conjunt de problemes. Una única instància d'aplicació en execució implementa un o més tipus de rol. Hi pot haver diversos rols del mateix tipus en un clúster:
connector
Connector és responsable de la comunicació amb el món exterior; la seva tasca és acceptar la sol·licitud, analitzar-la i, si això té èxit, enviar les dades per processar-les al processador d'entrada. Admetem els formats HTTP, SOAP, Kafka i FIX. L'arquitectura us permet simplement afegir suport per a nous formats, amb suport per a IBM MQ properament. Si l'anàlisi de la sol·licitud falla, el connector retornarà un error; en cas contrari, respondrà que la sol·licitud s'ha processat correctament, encara que s'hagi produït un error durant el seu posterior processament. Això s'ha fet específicament per treballar amb sistemes que no saben repetir sol·licituds -o, per contra, fer-ho amb massa insistència. Per no perdre dades, s'utilitza una cua de reparació: l'objecte hi entra primer i només després d'haver-ne eliminat amb èxit. L'administrador pot rebre alertes sobre objectes que queden a la cua de reparació i, després d'eliminar un error de programari o de maquinari, torneu-ho a provar.
Processador d'entrada
El processador d'entrada classifica les dades rebudes segons els trets característics i crida als processadors adequats. Els controladors són codi Lua que s'executa en una caixa de sorra, de manera que no poden afectar el funcionament del sistema. En aquesta etapa, les dades es poden reduir a la forma requerida i, si és necessari, es pot llançar un nombre arbitrari de tasques que poden implementar la lògica necessària. Per exemple, al producte MDM (Master Data Management) construït a Tarantool Data Grid, en afegir un nou usuari, per no frenar el processament de la sol·licitud, iniciem la creació d'un disc d'or com a tasca independent. El sandbox admet sol·licituds per llegir, canviar i afegir dades, us permet realitzar alguna funció en tots els rols del tipus d'emmagatzematge i l'agregació del resultat (mapa/reducció).
Els gestors es poden descriure en fitxers:
sum.lua
local x, y = unpack(...)
return x + yI després, declarat a la configuració:
functions:
sum: { __file: sum.lua }
Per què Lua? Lua és un llenguatge molt senzill. Segons la nostra experiència, un parell d'hores després de conèixer-lo, la gent comença a escriure codi que resol el seu problema. I aquests no només són desenvolupadors professionals, sinó, per exemple, analistes. A més, gràcies al compilador de jiti, Lua s'executa molt ràpidament.
Dipòsit
L'emmagatzematge emmagatzema dades persistents. Abans de desar, les dades es validen amb l'esquema de dades. Per descriure el circuit fem servir un format estès ... Exemple:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}A partir d'aquesta descripció, DDL (Llenguatge de definició de dades) es genera automàticament per al SGBD de Tarantula i esquema d'accés a les dades.
S'admet la replicació de dades asíncrona (hi ha plans per afegir-ne una de síncrona).
Processador de sortida
De vegades és necessari notificar als consumidors externs l'arribada de noves dades, per a això hi ha la funció de processador de sortida. Després de desar les dades, es poden passar al gestor adequat (per exemple, per portar-les al formulari requerit pel consumidor) i després passar-les al connector per enviar-les. Aquí també s'utilitza una cua de reparació: si ningú ha acceptat l'objecte, l'administrador pot tornar-ho a provar més tard.
Escalat
Els rols de connector, processador d'entrada i processador de sortida són sense estat, la qual cosa ens permet escalar el sistema horitzontalment simplement afegint noves instàncies d'aplicació amb el tipus de rol desitjat habilitat. L'emmagatzematge s'utilitza per a l'escala horitzontal per organitzar un clúster mitjançant cubs virtuals. Després d'afegir un nou servidor, alguns dels cubs dels servidors antics es mouen al nou servidor en segon pla; això passa de manera transparent als usuaris i no afecta el funcionament de tot el sistema.
Propietats de les dades
Els objectes poden ser molt grans i contenir altres objectes. Assegurem l'atomicitat d'afegir i actualitzar dades emmagatzemant un objecte amb totes les dependències en un cub virtual. Això evita que l'objecte es "escampi" per diversos servidors físics.
S'admet el control de versions: cada actualització d'un objecte crea una versió nova, i sempre podem fer una porció de temps i veure com era el món aleshores. Per a dades que no necessiten un historial llarg, podem limitar el nombre de versions o fins i tot emmagatzemar-ne només una, l'última, és a dir, essencialment desactivar el control de versions per a un tipus determinat. També podeu limitar l'historial per temps: per exemple, suprimiu tots els objectes d'un determinat tipus de més d'1 any. També s'admet l'arxiu: podem descarregar objectes més antics que el temps especificat, alliberant espai al clúster.
tasques
Entre les característiques interessants, cal destacar la possibilitat de llançar tasques de manera programada, a petició de l'usuari o programàticament des del sandbox:
Aquí veiem un altre paper: corredor. Aquesta funció és sense estat i es poden afegir instàncies d'aplicació addicionals amb aquesta funció al clúster segons sigui necessari. La responsabilitat del corredor és completar les tasques. Com s'ha dit, és possible generar noves tasques des del sandbox; es guarden en una cua d'emmagatzematge i després s'executen al corredor. Aquest tipus de tasca s'anomena Job. També tenim un tipus de tasca anomenat Tasca: són tasques definides per l'usuari que s'executen segons una programació (utilitzant la sintaxi cron) o sota demanda. Per iniciar i fer un seguiment d'aquestes tasques, tenim un gestor de tasques convenient. Per tal que aquesta funcionalitat estigui disponible, heu d'habilitar la funció de planificador; aquest paper té un estat, per tant no escala, que, però, no és necessari; al mateix temps, com tots els altres rols, pot tenir una rèplica que comenci a funcionar si el mestre es nega de sobte.
Registrador
Un altre paper s'anomena enregistrador. Recull registres de tots els membres del clúster i proporciona una interfície per carregar-los i visualitzar-los a través de la interfície web.
Serveis
Val la pena esmentar que el sistema facilita la creació de serveis. Al fitxer de configuració, podeu especificar quines sol·licituds s'envien a un controlador escrit per l'usuari que s'executa a la caixa de proves. En aquest controlador, podeu, per exemple, executar algun tipus de consulta analítica i retornar el resultat.
El servei es descriu al fitxer de configuració:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
L'API GraphQL es genera automàticament i el servei està disponible per trucar:
query {
sum(x: 1, y: 2)
}
Això trucarà al gestor sumque retornarà el resultat:
3
Perfil de consultes i mètriques
Per entendre el funcionament del sistema i les sol·licituds de perfils, hem implementat suport per al protocol OpenTracing. El sistema pot enviar informació sota demanda a eines que admeten aquest protocol, com ara Zipkin, que us permetran entendre com s'ha executat la sol·licitud:
Naturalment, el sistema proporciona mètriques internes que es poden recopilar amb Prometheus i visualitzar-les amb Grafana.
Desplega
Tarantool Data Grid es pot desplegar des de paquets RPM o un arxiu, utilitzant una utilitat de la distribució o Ansible, també hi ha suport per a Kubernetes ().
L'aplicació que implementa la lògica de negoci (configuració, controladors) es carrega al clúster de Tarantool Data Grid desplegat en forma d'arxiu mitjançant la interfície d'usuari o mitjançant un script a través de l'API proporcionada per nosaltres.
Fonaments de filosofia
Quines aplicacions es poden crear amb Tarantool Data Grid? De fet, la majoria de les tasques empresarials estan relacionades d'alguna manera amb el processament, l'emmagatzematge i l'accés al flux de dades. Per tant, si teniu grans fluxos de dades que cal emmagatzemar i accedir de manera segura, el nostre producte us pot estalviar molt temps de desenvolupament i centrar-vos en la vostra lògica empresarial.
Per exemple, volem recollir informació sobre el mercat immobiliari, de manera que en el futur, per exemple, tinguem informació sobre les millors ofertes. En aquest cas, destacarem les següents tasques:
- Els robots que recullen informació de fonts obertes seran les nostres fonts de dades. Podeu resoldre aquest problema utilitzant solucions ja fetes o escrivint codi en qualsevol idioma.
- A continuació, Tarantool Data Grid acceptarà i desarà les dades. Si el format de dades de diferents fonts és diferent, podeu escriure codi en Lua que realitzarà la conversió a un únic format. En l'etapa de preprocessament, també podreu, per exemple, filtrar ofertes duplicades o actualitzar, addicionalment, la informació dels agents que treballen al mercat a la base de dades.
- Ara ja teniu una solució escalable en un clúster que es pot omplir de dades i fer seleccions de dades. A continuació, podeu implementar una nova funcionalitat, per exemple, escriure un servei que sol·licitarà dades i oferirà l'oferta més avantatjosa per dia; això requerirà unes poques línies al fitxer de configuració i una mica de codi Lua.
Què serà el següent?
La nostra prioritat és millorar la facilitat de desenvolupament d'ús . Per exemple, aquest és un IDE amb suport per a gestors de perfils i depuració que s'executen en una caixa de proves.
També prestem molta atenció als problemes de seguretat. En aquests moments estem sotmesos a la certificació de FSTEC de Rússia per confirmar l'alt nivell de seguretat i complir els requisits de certificació dels productes de programari utilitzats en sistemes d'informació de dades personals i sistemes d'informació governamentals.
Font: www.habr.com