Nel 2017 abbiamo vinto un concorso per sviluppare il nucleo transazionale dell’attività di investimento di Alfa-Bank e abbiamo iniziato a lavorare (a HighLoad++ 2018 con un rapporto sul nucleo dell’attività di investimento Vladimir Drynkin, capo del nucleo transazionale delle attività di investimento di Alfa Bank). Questo sistema avrebbe dovuto aggregare i dati delle transazioni provenienti da diverse fonti in vari formati, riunire i dati in una forma unificata, archiviarli e fornirne l'accesso.
Durante il processo di sviluppo, il sistema si è evoluto e ha acquisito funzionalità, e a un certo punto ci siamo resi conto che stavamo cristallizzando qualcosa di molto più di un semplice software applicativo creato per risolvere una gamma di compiti rigorosamente definiti: ci siamo riusciti sistema per la creazione di applicazioni distribuite con archiviazione persistente. L'esperienza che abbiamo acquisito ha costituito la base di un nuovo prodotto - (TDG).
Voglio parlare dell'architettura TDG e delle soluzioni a cui siamo arrivati durante il processo di sviluppo, presentarvi le funzionalità principali e mostrare come il nostro prodotto può diventare la base per costruire soluzioni complete.
Architettonicamente abbiamo diviso il sistema in parti separate ruolo, ognuno dei quali è responsabile della risoluzione di una certa gamma di problemi. Una singola istanza dell'applicazione in esecuzione implementa uno o più tipi di ruolo. In un cluster possono essere presenti più ruoli dello stesso tipo:
Connettore
Il connettore è responsabile della comunicazione con il mondo esterno; il suo compito è accettare la richiesta, analizzarla e, se ciò ha esito positivo, inviare i dati per l'elaborazione al processore di input. Supportiamo i formati HTTP, SOAP, Kafka, FIX. L'architettura consente di aggiungere semplicemente il supporto per nuovi formati, con il supporto per IBM MQ in arrivo. Se l'analisi della richiesta non è riuscita, il connettore restituirà un errore; in caso contrario, risponderà che la richiesta è stata elaborata con successo, anche se si è verificato un errore durante l'ulteriore elaborazione. Ciò è stato fatto appositamente per lavorare con sistemi che non sanno ripetere le richieste o, al contrario, lo fanno in modo troppo persistente. Per non perdere i dati, viene utilizzata una coda di riparazione: l'oggetto prima vi entra e solo dopo l'elaborazione riuscita viene rimosso da esso. L'amministratore può ricevere avvisi sugli oggetti rimasti nella coda di riparazione e, dopo aver eliminato un errore software o hardware, riprovare.
Processore di input
Il processore di input classifica i dati ricevuti in base alle caratteristiche e chiama i processori appropriati. I gestori sono codice Lua che viene eseguito in una sandbox, quindi non possono influenzare il funzionamento del sistema. In questa fase, i dati possono essere ridotti alla forma richiesta e, se necessario, è possibile avviare un numero arbitrario di attività in grado di implementare la logica necessaria. Ad esempio, nel prodotto MDM (Master Data Management) basato su Tarantool Data Grid, quando si aggiunge un nuovo utente, per non rallentare l'elaborazione della richiesta, avviamo la creazione di un golden record come attività separata. La sandbox supporta richieste di lettura, modifica e aggiunta di dati, consente di eseguire alcune funzioni su tutti i ruoli del tipo di archiviazione e aggregazione del risultato (mappa/riduci).
I gestori possono essere descritti nei file:
sum.lua
local x, y = unpack(...)
return x + yE poi, dichiarato nella configurazione:
functions:
sum: { __file: sum.lua }
Perchè Lua? Lua è un linguaggio molto semplice. In base alla nostra esperienza, un paio d'ore dopo averlo conosciuto, le persone iniziano a scrivere codice che risolve il loro problema. E questi non sono solo sviluppatori professionisti, ma, ad esempio, analisti. Inoltre, grazie al compilatore jit, Lua gira molto velocemente.
Archiviazione
Lo spazio di archiviazione archivia dati persistenti. Prima del salvataggio, i dati vengono convalidati rispetto allo schema dei dati. Per descrivere il circuito utilizziamo un formato esteso . esempio:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Sulla base di questa descrizione, DDL (Data Definition Language) viene generato automaticamente per il DBMS Tarantula e schema per l'accesso ai dati.
È supportata la replica asincrona dei dati (è prevista l'aggiunta di una replica sincrona).
Processore di uscita
A volte è necessario avvisare i consumatori esterni dell'arrivo di nuovi dati; a questo scopo esiste il ruolo Processore di output. Dopo aver salvato i dati, questi possono essere passati al gestore appropriato (ad esempio, per portarli nel modulo richiesto dal consumatore) e quindi passati al connettore per l'invio. Anche qui viene utilizzata una coda di riparazione: se nessuno ha accettato l'oggetto, l'amministratore può riprovare più tardi.
scalata
I ruoli del connettore, del processore di input e del processore di output sono senza stato, consentendoci di scalare il sistema orizzontalmente semplicemente aggiungendo nuove istanze dell'applicazione con il tipo di ruolo desiderato abilitato. Lo spazio di archiviazione viene utilizzato per il ridimensionamento orizzontale all'organizzazione di un cluster utilizzando bucket virtuali. Dopo aver aggiunto un nuovo server, alcuni bucket dei vecchi server vengono spostati sul nuovo server in background; questo avviene in modo trasparente per gli utenti e non pregiudica il funzionamento dell'intero sistema.
Proprietà dei dati
Gli oggetti possono essere molto grandi e contenere altri oggetti. Garantiamo l'atomicità nell'aggiunta e nell'aggiornamento dei dati archiviando un oggetto con tutte le dipendenze in un bucket virtuale. Ciò impedisce che l'oggetto venga "distribuito" su più server fisici.
È supportato il controllo delle versioni: ogni aggiornamento di un oggetto crea una nuova versione e possiamo sempre prendere un intervallo di tempo e vedere come appariva il mondo in quel momento. Per i dati che non necessitano di una lunga cronologia, possiamo limitare il numero di versioni o addirittura memorizzarne solo una, l'ultima, ovvero disabilitare essenzialmente il controllo delle versioni per un determinato tipo. Puoi anche limitare la cronologia in base al tempo: ad esempio, elimina tutti gli oggetti di un certo tipo più vecchi di 1 anno. È supportata anche l'archiviazione: possiamo scaricare oggetti più vecchi del tempo specificato, liberando spazio nel cluster.
compiti
Tra le caratteristiche interessanti, vale la pena notare la possibilità di avviare attività in base a una pianificazione, su richiesta dell'utente o in modo programmatico dalla sandbox:
Qui vediamo un altro ruolo: il corridore. Questo ruolo è senza stato e ulteriori istanze dell'applicazione con questo ruolo possono essere aggiunte al cluster in base alle esigenze. La responsabilità del corridore è completare le attività. Come accennato, è possibile generare nuovi task dalla sandbox; vengono salvati in coda sullo storage e poi eseguiti sul runner. Questo tipo di attività si chiama Lavoro. Abbiamo anche un tipo di attività chiamato Attività: si tratta di attività definite dall'utente che vengono eseguite in base a una pianificazione (utilizzando la sintassi cron) o su richiesta. Per avviare e tenere traccia di tali attività, disponiamo di un comodo task manager. Affinché questa funzionalità sia disponibile è necessario abilitare il ruolo di pianificazione; questo ruolo ha uno stato, quindi non è scalabile, cosa che però non è richiesta; allo stesso tempo, come tutti gli altri ruoli, può avere una replica che inizia a funzionare se il master rifiuta improvvisamente.
Logger
Un altro ruolo è chiamato logger. Raccoglie i log da tutti i membri del cluster e fornisce un'interfaccia per caricarli e visualizzarli tramite l'interfaccia web.
Servizi
Vale la pena ricordare che il sistema semplifica la creazione di servizi. Nel file di configurazione è possibile specificare quali richieste vengono inviate a un gestore scritto dall'utente che viene eseguito nella sandbox. In questo gestore è possibile, ad esempio, eseguire una sorta di query analitica e restituire il risultato.
Il servizio è descritto nel file di configurazione:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
L'API GraphQL viene generata automaticamente e il servizio diventa disponibile per la chiamata:
query {
sum(x: 1, y: 2)
}
Questo chiamerà il gestore sumche restituirà il risultato:
3
Profilazione e metriche delle query
Per comprendere il funzionamento del sistema e le richieste di profilazione, abbiamo implementato il supporto al protocollo OpenTracing. Il sistema può inviare informazioni su richiesta a strumenti che supportano questo protocollo, come Zipkin, che ti permetteranno di capire come è stata eseguita la richiesta:
Naturalmente, il sistema fornisce metriche interne che possono essere raccolte utilizzando Prometheus e visualizzate utilizzando Grafana.
Distribuire
Tarantool Data Grid può essere distribuito da pacchetti RPM o da un archivio, utilizzando un'utilità della distribuzione o Ansible, c'è anche il supporto per Kubernetes ().
L'applicazione che implementa la logica aziendale (configurazione, gestori) viene caricata nel cluster Tarantool Data Grid distribuito sotto forma di archivio tramite l'interfaccia utente o utilizzando uno script tramite l'API da noi fornita.
Applicazioni di esempio
Quali applicazioni si possono creare utilizzando Tarantool Data Grid? In effetti, la maggior parte delle attività aziendali sono in qualche modo legate all’elaborazione, all’archiviazione e all’accesso al flusso di dati. Pertanto, se disponi di grandi flussi di dati che devono essere archiviati e accessibili in modo sicuro, il nostro prodotto può farti risparmiare molto tempo di sviluppo e concentrarti sulla logica aziendale.
Vogliamo, ad esempio, raccogliere informazioni sul mercato immobiliare, in modo da avere in futuro, ad esempio, informazioni sulle migliori offerte. In questo caso, metteremo in evidenza le seguenti attività:
- I robot che raccolgono informazioni da fonti aperte saranno le nostre fonti di dati. Puoi risolvere questo problema utilizzando soluzioni già pronte o scrivendo codice in qualsiasi lingua.
- Successivamente, Tarantool Data Grid accetterà e salverà i dati. Se il formato dei dati provenienti da origini diverse è diverso, puoi scrivere codice in Lua che eseguirà la conversione in un unico formato. Nella fase di pre-elaborazione potrete anche, ad esempio, filtrare le offerte duplicate o aggiornare ulteriormente le informazioni sugli agenti che lavorano nel mercato nel database.
- Ora disponi già di una soluzione scalabile in un cluster che può essere riempito con dati ed effettuare selezioni di dati. Quindi puoi implementare nuove funzionalità, ad esempio scrivere un servizio che effettuerà una richiesta di dati e fornirà l'offerta più vantaggiosa al giorno: ciò richiederà alcune righe nel file di configurazione e un piccolo codice Lua.
Quali sono le prospettive?
La nostra priorità è migliorare la facilità di sviluppo utilizzando . Ad esempio, questo è un IDE con supporto per la profilazione e il debug dei gestori in esecuzione in una sandbox.
Prestiamo grande attenzione anche ai temi della sicurezza. In questo momento siamo in fase di certificazione da parte della FSTEC della Russia per confermare l'elevato livello di sicurezza e soddisfare i requisiti per la certificazione dei prodotti software utilizzati nei sistemi informativi dei dati personali e nei sistemi informativi governativi.
Fonte: habr.com