I 2017 vandt vi en konkurrence om at udvikle den transaktionelle kerne af Alfa-Banks investeringsforretning og begyndte arbejdet (på HighLoad++ 2018 med en rapport om kernen i investeringsforretningen Vladimir Drynkin, leder af den transaktionelle kerne af Alfa Banks investeringsvirksomhed). Dette system skulle samle transaktionsdata fra forskellige kilder i forskellige formater, bringe dataene i en samlet form, gemme dem og give adgang til dem.
I løbet af udviklingsprocessen udviklede systemet sig og fik funktionalitet, og på et tidspunkt indså vi, at vi krystalliserede noget meget mere end blot applikationssoftware skabt til at løse en strengt defineret række af opgaver: det lykkedes. system til opbygning af distribuerede applikationer med vedvarende lagring. Den erfaring, vi fik, dannede grundlaget for et nyt produkt - (TDG).
Jeg vil fortælle om TDG-arkitekturen og de løsninger, vi kom frem til under udviklingsprocessen, introducere dig til hovedfunktionaliteten og vise, hvordan vores produkt kan blive grundlaget for at bygge komplette løsninger.
Arkitektonisk delte vi systemet op i separate roller, som hver især er ansvarlig for at løse en vis række af problemer. En enkelt kørende applikationsinstans implementerer en eller flere rolletyper. Der kan være flere roller af samme type i en klynge:
Stik
Connector er ansvarlig for kommunikationen med omverdenen; dens opgave er at acceptere anmodningen, parse den, og hvis dette lykkes, så send dataene til behandling til inputprocessoren. Vi understøtter HTTP, SOAP, Kafka, FIX-formater. Arkitekturen giver dig mulighed for blot at tilføje understøttelse af nye formater, og understøttelse af IBM MQ kommer snart. Hvis parsing af anmodningen mislykkedes, vil connectoren returnere en fejl; ellers vil den svare, at anmodningen blev behandlet med succes, selvom der opstod en fejl under dens videre behandling. Dette blev gjort specifikt for at arbejde med systemer, der ikke ved, hvordan man gentager anmodninger – eller tværtimod gør det for vedvarende. For ikke at miste data, bruges en reparationskø: objektet kommer først ind i det, og først efter vellykket behandling fjernes det fra det. Administratoren kan modtage advarsler om objekter, der er tilbage i reparationskøen, og efter at have elimineret en softwarefejl eller hardwarefejl, prøv igen.
Input processor
Inputprocessoren klassificerer de modtagne data i henhold til karakteristiske træk og kalder passende processorer. Handlere er Lua-kode, der kører i en sandkasse, så de kan ikke påvirke systemets funktion. På dette trin kan dataene reduceres til den ønskede form, og om nødvendigt kan der startes et vilkårligt antal opgaver, der kan implementere den nødvendige logik. For eksempel, i MDM (Master Data Management)-produktet bygget på Tarantool Data Grid, når vi tilføjer en ny bruger, for ikke at bremse behandlingen af anmodningen, lancerer vi oprettelsen af en gylden rekord som en separat opgave. Sandkassen understøtter anmodninger om læsning, ændring og tilføjelse af data, giver dig mulighed for at udføre nogle funktioner på alle roller af lagertypen og aggregering af resultatet (kort/reducer).
Handlere kan beskrives i filer:
sum.lua
local x, y = unpack(...)
return x + yOg så erklæret i konfigurationen:
functions:
sum: { __file: sum.lua }
Hvorfor Lua? Lua er et meget simpelt sprog. Baseret på vores erfaring begynder folk et par timer efter at have lært det at kende at skrive kode, der løser deres problem. Og det er ikke kun professionelle udviklere, men for eksempel analytikere. Derudover, takket være jit-kompileren, kører Lua meget hurtigt.
Opbevaring
Opbevaring gemmer vedvarende data. Inden data gemmes, valideres data i forhold til dataskemaet. Til at beskrive kredsløbet bruger vi et udvidet format . Et eksempel:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Baseret på denne beskrivelse genereres DDL (Data Definition Language) automatisk for Tarantula DBMS og skema for dataadgang.
Asynkron datareplikering understøttes (der er planer om at tilføje en synkron).
Output processor
Nogle gange er det nødvendigt at underrette eksterne forbrugere om ankomsten af nye data; til dette formål er der rollen som outputbehandler. Efter at have gemt dataene, kan de videregives til den relevante behandler (for eksempel for at bringe dem til den form, som forbrugeren kræver) - og derefter videregives til stikket til afsendelse. Her bruges også en reparationskø: hvis ingen accepterede objektet, kan administratoren prøve igen senere.
Skalering
Konnektor-, inputprocessor- og outputprocessorrollerne er statsløse, hvilket giver os mulighed for at skalere systemet horisontalt ved blot at tilføje nye applikationsforekomster med den ønskede rolletype aktiveret. Opbevaring bruges til vandret skalering at organisere en klynge ved hjælp af virtuelle buckets. Efter tilføjelse af en ny server flyttes nogle af buckets fra de gamle servere til den nye server i baggrunden; dette sker gennemsigtigt for brugerne og påvirker ikke driften af hele systemet.
Dataegenskaber
Objekter kan være meget store og indeholde andre objekter. Vi sikrer atomicitet ved tilføjelse og opdatering af data ved at gemme et objekt med alle afhængigheder i én virtuel bøtte. Dette forhindrer objektet i at blive "spredt ud" over flere fysiske servere.
Versionering er understøttet: hver opdatering af et objekt skaber en ny version, og vi kan altid tage et tidsudsnit og se, hvordan verden så ud dengang. For data, der ikke har brug for en lang historie, kan vi begrænse antallet af versioner eller endda kun gemme én - den seneste - det vil sige i det væsentlige deaktivere versionsstyring for en bestemt type. Du kan også begrænse historikken efter tid: Slet for eksempel alle objekter af en bestemt type ældre end 1 år. Arkivering understøttes også: vi kan fjerne objekter, der er ældre end det angivne tidspunkt, hvilket frigør plads i klyngen.
opgaver
Blandt de interessante funktioner er det værd at bemærke muligheden for at starte opgaver på en tidsplan, på brugerens anmodning eller programmatisk fra sandkassen:
Her ser vi en anden rolle - løber. Denne rolle er statsløs, og yderligere applikationsforekomster med denne rolle kan føjes til klyngen efter behov. Løberens ansvar er at udføre opgaver. Som nævnt er det muligt at generere nye opgaver fra sandkassen; de gemmes i en kø på lager og udføres derefter på runneren. Denne type opgave kaldes Job. Vi har også en opgavetype kaldet Task - det er brugerdefinerede opgaver, der kører efter en tidsplan (ved hjælp af cron-syntaks) eller on demand. For at starte og spore sådanne opgaver har vi en praktisk opgavehåndtering. For at denne funktionalitet skal være tilgængelig, skal du aktivere skemalæggerrollen; denne rolle har en tilstand, så den skalerer ikke, hvilket dog ikke er påkrævet; samtidig kan den, ligesom alle andre roller, have en replika, der begynder at virke, hvis mesteren pludselig nægter.
Logger
En anden rolle kaldes logger. Den indsamler logfiler fra alle medlemmer af klyngen og giver en grænseflade til at uploade og se dem via webgrænsefladen.
Services
Det er værd at nævne, at systemet gør det nemt at oprette tjenester. I konfigurationsfilen kan du angive, hvilke anmodninger der sendes til en brugerskrevet behandler, der kører i sandkassen. I denne handler kan du for eksempel køre en form for analytisk forespørgsel og returnere resultatet.
Tjenesten er beskrevet i konfigurationsfilen:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
GraphQL API'en genereres automatisk, og tjenesten bliver tilgængelig for opkald:
query {
sum(x: 1, y: 2)
}
Dette vil kalde handleren sumsom vil returnere resultatet:
3
Forespørgselsprofilering og metrics
For at forstå driften af systemet og profileringsanmodninger implementerede vi understøttelse af OpenTracing-protokollen. Systemet kan sende information efter behov til værktøjer, der understøtter denne protokol, såsom Zipkin, som giver dig mulighed for at forstå, hvordan anmodningen blev udført:
Systemet giver naturligvis interne målinger, der kan indsamles ved hjælp af Prometheus og visualiseres ved hjælp af Grafana.
Indsætte
Tarantool Data Grid kan implementeres fra RPM-pakker eller et arkiv, ved hjælp af et værktøj fra distributionen eller Ansible, der er også understøttelse af Kubernetes ().
Applikationen, der implementerer forretningslogikken (konfiguration, handlere) indlæses i den installerede Tarantool Data Grid-klynge i form af et arkiv gennem brugergrænsefladen eller ved hjælp af et script gennem API'et, som vi har leveret.
Grundlæggende om filosofi
Hvilke applikationer kan oprettes ved hjælp af Tarantool Data Grid? Faktisk er de fleste forretningsopgaver på en eller anden måde relateret til behandling, lagring og adgang til dataflow. Derfor, hvis du har store datastrømme, der skal opbevares og tilgås sikkert, så kan vores produkt spare dig for en masse udviklingstid og fokusere på din forretningslogik.
Vi ønsker for eksempel at indsamle oplysninger om ejendomsmarkedet, så vi i fremtiden fx har information om de bedste tilbud. I dette tilfælde vil vi fremhæve følgende opgaver:
- Robotter, der indsamler information fra åbne kilder, vil være vores datakilder. Du kan løse dette problem ved at bruge færdige løsninger eller skrive kode på ethvert sprog.
- Dernæst vil Tarantool Data Grid acceptere og gemme dataene. Hvis dataformatet fra forskellige kilder er forskelligt, kan du skrive kode i Lua, der udfører konverteringen til et enkelt format. På forbehandlingsstadiet vil du også være i stand til for eksempel at filtrere duplikerede tilbud eller yderligere opdatere information om agenter, der arbejder på markedet i databasen.
- Nu har du allerede en skalerbar løsning i en klynge, der kan fyldes med data og foretage datavalg. Så kan du implementere ny funktionalitet, for eksempel skrive en service, der vil lave en anmodning om data og give det mest fordelagtige tilbud pr. dag - dette vil kræve et par linjer i konfigurationsfilen og lidt Lua-kode.
Hvad er det næste?
Vores prioritet er at forbedre brugervenligheden ved at udvikle . For eksempel er dette en IDE med understøttelse af profilering og fejlfinding af handlere, der kører i en sandkasse.
Vi er også meget opmærksomme på sikkerhedsspørgsmål. Lige nu gennemgår vi certificering af FSTEC i Rusland for at bekræfte det høje sikkerhedsniveau og opfylde kravene til certificering af softwareprodukter, der bruges i persondatainformationssystemer og offentlige informationssystemer.
Kilde: www.habr.com