En 2017, gañamos un concurso para desenvolver o núcleo transaccional do negocio de investimento de Alfa-Bank e comezamos a traballar (en HighLoad++ 2018 cun informe sobre o núcleo do negocio de investimento Vladimir Drynkin, xefe do núcleo transaccional do negocio de investimento de Alfa Bank). Este sistema debía agregar datos de transaccións de diferentes fontes en varios formatos, traer os datos nun formulario unificado, almacenalos e proporcionar acceso a eles.
Durante o proceso de desenvolvemento, o sistema evolucionou e adquiriu funcionalidades, e nalgún momento decatámonos de que estabamos a cristalizar algo moito máis que un software de aplicación creado para resolver un abano de tarefas estritamente definido: conseguímolo. sistema para crear aplicacións distribuídas con almacenamento persistente. A experiencia que adquirimos constituíu a base dun novo produto - (TDG).
Quero falar da arquitectura TDG e das solucións ás que chegamos durante o proceso de desenvolvemento, presentarche a funcionalidade principal e mostrar como o noso produto pode converterse na base para construír solucións completas.
Arquitectónicamente, dividimos o sistema en separados papeis, cada un dos cales se encarga de resolver unha serie de problemas. Unha única instancia de aplicación en execución implementa un ou máis tipos de roles. Pode haber varios roles do mesmo tipo nun clúster:
conector
Connector é o responsable da comunicación co mundo exterior; a súa tarefa é aceptar a solicitude, analizala e, se isto ten éxito, enviar os datos para procesar ao procesador de entrada. Admitimos os formatos HTTP, SOAP, Kafka e FIX. A arquitectura permítelle simplemente engadir compatibilidade con novos formatos, coa compatibilidade con IBM MQ en breve. Se fallou a análise da solicitude, o conector devolverá un erro; en caso contrario, responderá que a solicitude foi procesada con éxito, aínda que se producise un erro durante a súa posterior tramitación. Fíxose especialmente para traballar con sistemas que non saben repetir solicitudes -ou, pola contra, facelo con demasiada persistencia. Para non perder datos, utilízase unha cola de reparación: o obxecto entra primeiro nel e só despois de que o procesamento exitoso se elimine. O administrador pode recibir alertas sobre os obxectos que quedan na cola de reparación e, despois de eliminar un erro de software ou de hardware, téntao de novo.
Procesador de entrada
O procesador de entrada clasifica os datos recibidos segundo os trazos característicos e chama aos procesadores axeitados. Os controladores son código Lua que se executa nun sandbox, polo que non poden afectar o funcionamento do sistema. Nesta fase, os datos pódense reducir á forma requirida e, se é necesario, pódese lanzar un número arbitrario de tarefas que poidan implementar a lóxica necesaria. Por exemplo, no produto MDM (Master Data Management) construído sobre Tarantool Data Grid, ao engadir un novo usuario, para non retardar o procesamento da solicitude, lanzamos a creación dun disco de ouro como tarefa separada. O sandbox admite solicitudes para ler, cambiar e engadir datos, permítelle realizar algunha función en todos os roles do tipo de almacenamento e agregación do resultado (mapa/reducir).
Os controladores pódense describir nos ficheiros:
sum.lua
local x, y = unpack(...)
return x + yE despois, declarado na configuración:
functions:
sum: { __file: sum.lua }
Por que Lua? Lua é unha linguaxe moi sinxela. Segundo a nosa experiencia, un par de horas despois de coñecelo, a xente comeza a escribir código que soluciona o seu problema. E estes non son só desenvolvedores profesionais, senón, por exemplo, analistas. Ademais, grazas ao compilador jit, Lua execútase moi rápido.
almacenamento
O almacenamento almacena datos persistentes. Antes de gardar, os datos son validados contra o esquema de datos. Para describir o circuíto utilizamos un formato estendido . Un exemplo:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Con base nesta descrición, DDL (Data Definition Language) xérase automaticamente para o DBMS Tarantula e esquema de acceso a datos.
Admítese a replicación de datos asíncrona (hai plans para engadir unha síncrona).
Procesador de saída
Ás veces é necesario notificar aos consumidores externos a chegada de novos datos; para iso, existe o rol de procesador de saída. Despois de gardar os datos, pódese pasar ao controlador correspondente (por exemplo, para levalos ao formulario que requira o consumidor) e despois pasarse ao conector para o seu envío. Aquí tamén se usa unha cola de reparación: se ninguén aceptou o obxecto, o administrador pode tentalo de novo máis tarde.
Escalado
Os roles do conector, do procesador de entrada e do procesador de saída son sen estado, o que nos permite escalar o sistema horizontalmente simplemente engadindo novas instancias de aplicación co tipo de rol desexado activado. O almacenamento úsase para a escala horizontal para organizar un clúster mediante depósitos virtuais. Despois de engadir un novo servidor, algúns dos depósitos dos antigos servidores móvense ao novo servidor en segundo plano; isto ocorre de forma transparente para os usuarios e non afecta o funcionamento de todo o sistema.
Propiedades de datos
Os obxectos poden ser moi grandes e conter outros obxectos. Aseguramos a atomicidade de engadir e actualizar datos almacenando un obxecto con todas as dependencias nun depósito virtual. Isto evita que o obxecto estea "espandido" por varios servidores físicos.
Admítese o control de versións: cada actualización dun obxecto crea unha nova versión, e sempre podemos tomar un tempo e ver como era o mundo entón. Para os datos que non necesitan un historial longo, podemos limitar o número de versións ou mesmo almacenar só unha, a máis recente, é dicir, esencialmente desactivar a versión para un determinado tipo. Tamén pode limitar o historial por tempo: por exemplo, eliminar todos os obxectos dun determinado tipo de máis de 1 ano. Tamén se admite o arquivo: podemos descargar obxectos máis antigos que o tempo especificado, liberando espazo no clúster.
tarefas
Entre as características interesantes, cabe destacar a posibilidade de iniciar tarefas nunha programación, a petición do usuario ou mediante programación desde o sandbox:
Aquí vemos outro papel: corredor. Este rol é sen estado e pódense engadir instancias de aplicación adicionais con este rol ao clúster segundo sexa necesario. A responsabilidade do corredor é completar as tarefas. Como se mencionou, é posible xerar novas tarefas desde o sandbox; gárdanse nunha cola no almacenamento e despois execútanse no corredor. Este tipo de tarefa chámase Job. Tamén temos un tipo de tarefa chamado Tarefa: son tarefas definidas polo usuario que se executan nunha programación (usando a sintaxe cron) ou baixo demanda. Para iniciar e rastrexar tales tarefas, temos un cómodo xestor de tarefas. Para que esta funcionalidade estea dispoñible, debes activar o rol de planificador; este papel ten un estado, polo que non se escala, que, porén, non é necesario; ao mesmo tempo, como todos os outros papeis, pode ter unha réplica que comeza a funcionar se o mestre rexeita de súpeto.
Xustificador
Outro papel chámase rexistrador. Recolle rexistros de todos os membros do clúster e ofrece unha interface para cargalos e velos a través da interface web.
Servizos
Cabe mencionar que o sistema facilita a creación de servizos. No ficheiro de configuración, pode especificar que solicitudes se envían a un manejador escrito polo usuario que se executa no sandbox. Neste controlador, pode, por exemplo, executar algún tipo de consulta analítica e devolver o resultado.
O servizo descríbese no ficheiro de configuración:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
A API GraphQL xérase automaticamente e o servizo está dispoñible para chamar:
query {
sum(x: 1, y: 2)
}
Isto chamará ao manejador sumque devolverá o resultado:
3
Perfil de consulta e métricas
Para comprender o funcionamento do sistema e as solicitudes de perfilado, implementamos soporte para o protocolo OpenTracing. O sistema pode enviar información baixo demanda a ferramentas que admiten este protocolo, como Zipkin, o que lle permitirá comprender como se executou a solicitude:
Por suposto, o sistema ofrece métricas internas que se poden recoller mediante Prometheus e visualizar mediante Grafana.
Implantar
Tarantool Data Grid pódese implementar desde paquetes RPM ou un arquivo, usando unha utilidade da distribución ou Ansible, tamén hai soporte para Kubernetes ().
A aplicación que implementa a lóxica de negocio (configuración, controladores) cárgase no clúster de Tarantool Data Grid implantado en forma de arquivo a través da IU ou mediante un script a través da API proporcionada por nós.
Aplicacións de mostra
Que aplicacións se poden crear usando Tarantool Data Grid? De feito, a maioría das tarefas empresariais están dalgún xeito relacionadas co procesamento, almacenamento e acceso ao fluxo de datos. Polo tanto, se tes grandes fluxos de datos aos que hai que almacenar e acceder de forma segura, entón o noso produto pode aforrarche moito tempo de desenvolvemento e concentrarse na túa lóxica empresarial.
Por exemplo, queremos recoller información sobre o mercado inmobiliario, para que no futuro, por exemplo, teñamos información sobre as mellores ofertas. Neste caso, destacaremos as seguintes tarefas:
- Os robots que recollen información de fontes abertas serán as nosas fontes de datos. Podes resolver este problema usando solucións preparadas ou escribindo código en calquera idioma.
- A continuación, Tarantool Data Grid aceptará e gardará os datos. Se o formato de datos de diferentes fontes é diferente, pode escribir código en Lua que realizará a conversión a un único formato. Na fase de preprocesamento, tamén poderás, por exemplo, filtrar ofertas duplicadas ou actualizar adicionalmente a información sobre axentes que traballan no mercado na base de datos.
- Agora xa tes unha solución escalable nun clúster que se pode encher de datos e facer seleccións de datos. Entón podes implementar novas funcionalidades, por exemplo, escribir un servizo que fará unha solicitude de datos e ofrecerá a oferta máis vantaxosa ao día; isto requirirá algunhas liñas no ficheiro de configuración e un pouco de código Lua.
Cal é o próximo?
A nosa prioridade é mellorar a facilidade de uso . Por exemplo, este é un IDE con soporte para manejadores de perfís e depuración que se executan nun sandbox.
Tamén prestamos moita atención aos problemas de seguridade. Nestes momentos estamos a recibir a certificación de FSTEC de Rusia para confirmar o alto nivel de seguridade e cumprir os requisitos para a certificación dos produtos de software utilizados nos sistemas de información de datos persoais e nos sistemas de información gobernamentais.
Fonte: www.habr.com