I 2017 vant vi en konkurranse for å utvikle den transaksjonelle kjernen i Alfa-Banks investeringsvirksomhet og begynte arbeidet (på HighLoad++ 2018 med en rapport om kjernen i investeringsvirksomheten Vladimir Drynkin, leder for den transaksjonelle kjernen i investeringsvirksomheten til Alfa Bank). Dette systemet skulle samle transaksjonsdata fra forskjellige kilder i forskjellige formater, bringe dataene inn i en enhetlig form, lagre dem og gi tilgang til dem.
I løpet av utviklingsprosessen utviklet systemet seg og fikk funksjonalitet, og på et tidspunkt innså vi at vi krystalliserte noe mye mer enn bare applikasjonsprogramvare laget for å løse et strengt definert spekter av oppgaver: vi lyktes. system for å bygge distribuerte applikasjoner med vedvarende lagring. Erfaringen vi fikk dannet grunnlaget for et nytt produkt - (TDG).
Jeg vil snakke om TDG-arkitekturen og løsningene vi kom frem til under utviklingsprosessen, introdusere deg for hovedfunksjonaliteten og vise hvordan produktet vårt kan bli grunnlaget for å bygge komplette løsninger.
Arkitektonisk delte vi systemet inn i separate roller, som hver er ansvarlig for å løse en viss rekke problemer. En enkelt kjørende applikasjonsforekomst implementerer én eller flere rolletyper. Det kan være flere roller av samme type i en klynge:
Connector
Connector er ansvarlig for kommunikasjon med omverdenen; dens oppgave er å akseptere forespørselen, analysere den, og hvis dette lykkes, sende dataene for behandling til inndataprosessoren. Vi støtter HTTP, SOAP, Kafka, FIX-formater. Arkitekturen lar deg ganske enkelt legge til støtte for nye formater, med støtte for IBM MQ kommer snart. Hvis parsing av forespørselen mislyktes, vil koblingen returnere en feil. ellers vil den svare at forespørselen ble behandlet, selv om det oppstod en feil under den videre behandlingen. Dette ble gjort spesifikt for å jobbe med systemer som ikke vet hvordan de skal gjenta forespørsler – eller tvert imot, gjør det for vedvarende. For ikke å miste data, brukes en reparasjonskø: objektet kommer først inn i det og først etter vellykket behandling fjernes det fra det. Administratoren kan motta varsler om gjenværende gjenstander i reparasjonskøen, og etter å ha eliminert en programvarefeil eller maskinvarefeil, prøv på nytt.
Inndataprosessor
Inndataprosessoren klassifiserer de mottatte dataene i henhold til karakteristiske egenskaper og kaller opp passende prosessorer. Håndtere er Lua-kode som kjører i en sandkasse, så de kan ikke påvirke funksjonen til systemet. På dette stadiet kan dataene reduseres til ønsket form, og om nødvendig kan et vilkårlig antall oppgaver startes som kan implementere den nødvendige logikken. For eksempel, i MDM (Master Data Management)-produktet bygget på Tarantool Data Grid, når vi legger til en ny bruker, for ikke å bremse behandlingen av forespørselen, lanserer vi opprettelsen av en gylden post som en egen oppgave. Sandkassen støtter forespørsler om å lese, endre og legge til data, lar deg utføre noen funksjoner på alle roller av lagringstypen og aggregering av resultatet (kart/reduser).
Håndtere kan beskrives i filer:
sum.lua
local x, y = unpack(...)
return x + yOg så, erklært i konfigurasjonen:
functions:
sum: { __file: sum.lua }
Hvorfor Lua? Lua er et veldig enkelt språk. Basert på vår erfaring, et par timer etter å ha blitt kjent med det, begynner folk å skrive kode som løser problemet deres. Og dette er ikke bare profesjonelle utviklere, men for eksempel analytikere. I tillegg, takket være jit-kompilatoren, kjører Lua veldig raskt.
oppbevaring
Lagring lagrer vedvarende data. Før lagring blir data validert mot dataskjemaet. For å beskrive kretsen bruker vi et utvidet format ... Eksempel:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Basert på denne beskrivelsen genereres DDL (Data Definition Language) automatisk for Tarantula DBMS og skjema for datatilgang.
Asynkron datareplikering støttes (det er planer om å legge til en synkron).
Utgangsprosessor
Noen ganger er det nødvendig å varsle eksterne forbrukere om ankomsten av nye data; for dette formålet er det utdatabehandlerrollen. Etter å ha lagret dataene, kan de sendes til den tilsvarende behandleren (for eksempel for å bringe dem til skjemaet som kreves av forbrukeren) - og deretter sendes til koblingen for sending. En reparasjonskø brukes også her: hvis ingen godtok objektet, kan administratoren prøve igjen senere.
skalering
Koblingen, inngangsprosessoren og utgangsprosessorrollene er tilstandsløse, og lar oss skalere systemet horisontalt ved ganske enkelt å legge til nye applikasjonsforekomster med ønsket rolletype aktivert. Lagring brukes til horisontal skalering å organisere en klynge ved hjelp av virtuelle bøtter. Etter å ha lagt til en ny server, flyttes noen av bøttene fra de gamle serverne til den nye serveren i bakgrunnen; dette skjer transparent for brukere og påvirker ikke driften av hele systemet.
Dataegenskaper
Objekter kan være svært store og inneholde andre objekter. Vi sikrer atomitet ved å legge til og oppdatere data ved å lagre et objekt med alle avhengigheter i en virtuell bøtte. Dette forhindrer at objektet blir "spredt ut" over flere fysiske servere.
Versjonsstyring støttes: hver oppdatering av et objekt skaper en ny versjon, og vi kan alltid ta en tid og se hvordan verden så ut da. For data som ikke trenger en lang historikk, kan vi begrense antall versjoner eller til og med lagre bare én – den siste – det vil si i hovedsak deaktivere versjonskontroll for en bestemt type. Du kan også begrense historikken etter tid: for eksempel slett alle objekter av en bestemt type eldre enn 1 år. Arkivering støttes også: vi kan laste ut objekter som er eldre enn den angitte tiden, og frigjøre plass i klyngen.
oppgaver
Blant de interessante funksjonene er det verdt å merke seg muligheten til å starte oppgaver på en tidsplan, på brukerens forespørsel, eller programmatisk fra sandkassen:
Her ser vi en annen rolle - løper. Denne rollen er statsløs, og flere applikasjonsforekomster med denne rollen kan legges til klyngen etter behov. Løperens ansvar er å gjennomføre oppgaver. Som nevnt er det mulig å generere nye oppgaver fra sandkassen; de lagres i en kø på lagring og kjøres deretter på løperen. Denne typen oppgaver kalles Job. Vi har også en oppgavetype som heter Task - dette er brukerdefinerte oppgaver som kjører på en tidsplan (ved hjelp av cron-syntaks) eller på forespørsel. For å starte og spore slike oppgaver har vi en praktisk oppgavebehandling. For at denne funksjonaliteten skal være tilgjengelig, må du aktivere planlegger-rollen; denne rollen har en tilstand, så den skalerer ikke, noe som imidlertid ikke er nødvendig; samtidig, som alle andre roller, kan den ha en replika som begynner å fungere hvis mesteren plutselig nekter.
logger
En annen rolle kalles logger. Den samler inn logger fra alle medlemmer av klyngen og gir et grensesnitt for opplasting og visning av dem gjennom nettgrensesnittet.
tjenester
Det er verdt å nevne at systemet gjør det enkelt å lage tjenester. I konfigurasjonsfilen kan du spesifisere hvilke forespørsler som sendes til en brukerskrevet behandler som kjører i sandkassen. I denne behandleren kan du for eksempel kjøre en slags analytisk spørring og returnere resultatet.
Tjenesten er beskrevet i konfigurasjonsfilen:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
GraphQL API genereres automatisk og tjenesten blir tilgjengelig for å ringe:
query {
sum(x: 1, y: 2)
}
Dette vil ringe til behandleren sumsom vil returnere resultatet:
3
Søkeprofilering og beregninger
For å forstå driften av systemet og profileringsforespørsler, implementerte vi støtte for OpenTracing-protokollen. Systemet kan sende informasjon på forespørsel til verktøy som støtter denne protokollen, for eksempel Zipkin, som lar deg forstå hvordan forespørselen ble utført:
Naturligvis gir systemet interne beregninger som kan samles inn ved hjelp av Prometheus og visualiseres ved hjelp av Grafana.
Utplassere
Tarantool Data Grid kan distribueres fra RPM-pakker eller et arkiv, ved å bruke et verktøy fra distribusjonen eller Ansible, det er også støtte for Kubernetes ().
Applikasjonen som implementerer forretningslogikken (konfigurasjon, behandlere) lastes inn i den distribuerte Tarantool Data Grid-klyngen i form av et arkiv gjennom brukergrensesnittet eller ved å bruke et skript gjennom API-en som er levert av oss.
Grunnleggere av filosofi
Hvilke applikasjoner kan opprettes med Tarantool Data Grid? Faktisk er de fleste forretningsoppgaver på en eller annen måte relatert til behandling, lagring og tilgang til dataflyt. Derfor, hvis du har store datastrømmer som må lagres sikkert og få tilgang til, kan produktet vårt spare deg for mye utviklingstid og fokusere på forretningslogikken din.
Vi ønsker for eksempel å samle informasjon om eiendomsmarkedet, slik at vi for eksempel i fremtiden skal ha informasjon om de beste tilbudene. I dette tilfellet vil vi fremheve følgende oppgaver:
- Roboter som samler inn informasjon fra åpne kilder vil være våre datakilder. Du kan løse dette problemet ved å bruke ferdige løsninger eller skrive kode på et hvilket som helst språk.
- Deretter vil Tarantool Data Grid godta og lagre dataene. Hvis dataformatet fra forskjellige kilder er forskjellig, kan du skrive kode i Lua som vil utføre konverteringen til et enkelt format. På forhåndsbehandlingsstadiet vil du også for eksempel kunne filtrere dupliserte tilbud eller i tillegg oppdatere informasjon om agenter som jobber i markedet i databasen.
- Nå har du allerede en skalerbar løsning i en klynge som kan fylles med data og gjøre datavalg. Da kan du implementere ny funksjonalitet, for eksempel skrive en tjeneste som vil forespørre data og gi det mest fordelaktige tilbudet per dag - dette vil kreve noen linjer i konfigurasjonsfilen og litt Lua-kode.
Hva blir det neste?
Vår prioritet er å gjøre det enklere å utvikle bruk . For eksempel er dette en IDE med støtte for profilering og feilsøking av behandlere som kjører i en sandkasse.
Vi legger også stor vekt på sikkerhetsspørsmål. Akkurat nå gjennomgår vi sertifisering av FSTEC i Russland for å bekrefte det høye sikkerhetsnivået og oppfylle kravene til sertifisering av programvareprodukter som brukes i informasjonssystemer for personopplysninger og offentlige informasjonssystemer.
Kilde: www.habr.com