Under 2017 vann vi en tävling för att utveckla transaktionskärnan i Alfa-Banks investeringsverksamhet och började arbeta (på HighLoad++ 2018 med en rapport om kärnan i investeringsverksamheten Vladimir Drynkin, chef för transaktionskärnan i Alfa Banks investeringsverksamhet). Detta system var tänkt att aggregera transaktionsdata från olika källor i olika format, föra data till en enhetlig form, lagra den och ge tillgång till den.
Under utvecklingsprocessen utvecklades systemet och fick funktionalitet, och vid något tillfälle insåg vi att vi kristalliserade något mycket mer än bara applikationsmjukvara skapad för att lösa ett strikt definierat antal uppgifter: vi lyckades system för att bygga distribuerade applikationer med beständig lagring. Erfarenheterna vi fick låg till grund för en ny produkt - (TDG).
Jag vill prata om TDG-arkitekturen och de lösningar vi kom fram till under utvecklingsprocessen, introducera dig för huvudfunktionaliteten och visa hur vår produkt kan bli grunden för att bygga kompletta lösningar.
Arkitektoniskt delade vi upp systemet i separata roller, som var och en ansvarar för att lösa ett visst antal problem. En enda körande applikationsinstans implementerar en eller flera rolltyper. Det kan finnas flera roller av samma typ i ett kluster:
kontakt
Connector ansvarar för kommunikationen med omvärlden; dess uppgift är att acceptera begäran, analysera den, och om detta lyckas, skicka sedan data för bearbetning till indataprocessorn. Vi stöder HTTP, SOAP, Kafka, FIX-format. Arkitekturen låter dig helt enkelt lägga till stöd för nya format, med stöd för IBM MQ kommer snart. Om analysen av begäran misslyckades returnerar anslutaren ett fel; I annat fall kommer den att svara att begäran behandlades framgångsrikt, även om ett fel inträffade under den fortsatta bearbetningen. Detta gjordes specifikt för att arbeta med system som inte vet hur man upprepar förfrågningar – eller tvärtom, gör det för ihärdigt. För att inte förlora data används en reparationskö: objektet kommer först in i det och först efter framgångsrik bearbetning tas det bort från det. Administratören kan ta emot varningar om objekt som finns kvar i reparationskön, och efter att ha eliminerat ett programvaru- eller maskinvarufel, försök igen.
Ingångsprocessor
Inmatningsprocessorn klassificerar mottagna data enligt karakteristiska egenskaper och anropar lämpliga processorer. Hanterare är Lua-kod som körs i en sandlåda, så de kan inte påverka systemets funktion. I detta skede kan data reduceras till önskad form, och vid behov kan ett godtyckligt antal uppgifter startas som kan implementera den nödvändiga logiken. Till exempel, i MDM (Master Data Management)-produkten byggd på Tarantool Data Grid, när vi lägger till en ny användare, för att inte sakta ner behandlingen av begäran, lanserar vi skapandet av en gyllene rekord som en separat uppgift. Sandlådan stöder förfrågningar om att läsa, ändra och lägga till data, låter dig utföra vissa funktioner på alla roller av lagringstyp och aggregering av resultatet (karta/förminska).
Hanterare kan beskrivas i filer:
sum.lua
local x, y = unpack(...)
return x + yOch sedan, deklarerade i konfigurationen:
functions:
sum: { __file: sum.lua }
Varför Lua? Lua är ett väldigt enkelt språk. Baserat på vår erfarenhet börjar folk ett par timmar efter att ha lärt känna det att skriva kod som löser deras problem. Och det här är inte bara professionella utvecklare, utan till exempel analytiker. Dessutom, tack vare jit-kompilatorn, kör Lua mycket snabbt.
lagring
Lagring lagrar beständig data. Innan du sparar valideras data mot dataschemat. För att beskriva kretsen använder vi ett utökat format . Exempel:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Baserat på denna beskrivning genereras DDL (Data Definition Language) automatiskt för Tarantula DBMS och schema för dataåtkomst.
Asynkron datareplikering stöds (det finns planer på att lägga till en synkron).
Utgångsprocessor
Ibland är det nödvändigt att meddela externa konsumenter om att nya uppgifter kommer in, för detta ändamål finns rollen som utdatabehandlare. Efter att ha sparat data kan den skickas till motsvarande hanterare (till exempel för att få den till den form som krävs av konsumenten) - och sedan skickas till anslutningen för sändning. En reparationskö används också här: om ingen accepterade objektet kan administratören försöka igen senare.
Skalning
Anslutnings-, ingångsprocessor- och utgångsprocessorrollerna är tillståndslösa, vilket gör att vi kan skala systemet horisontellt genom att helt enkelt lägga till nya applikationsinstanser med den önskade rolltypen aktiverad. Förvaring används för horisontell skalning att organisera ett kluster med hjälp av virtuella hinkar. Efter att ha lagt till en ny server flyttas några av hinkarna från de gamla servrarna till den nya servern i bakgrunden; detta sker öppet för användarna och påverkar inte driften av hela systemet.
Dataegenskaper
Objekt kan vara mycket stora och innehålla andra objekt. Vi säkerställer atomicitet för att lägga till och uppdatera data genom att lagra ett objekt med alla beroenden i en virtuell hink. Detta förhindrar att objektet "sprids ut" över flera fysiska servrar.
Versionering stöds: varje uppdatering av ett objekt skapar en ny version, och vi kan alltid ta en tid och se hur världen såg ut då. För data som inte behöver en lång historik kan vi begränsa antalet versioner eller till och med lagra bara en – den senaste – det vill säga i princip inaktivera versionshantering för en viss typ. Du kan också begränsa historiken efter tid: till exempel radera alla objekt av en viss typ äldre än 1 år. Arkivering stöds också: vi kan ladda bort objekt som är äldre än den angivna tiden, vilket frigör utrymme i klustret.
uppgifter
Bland de intressanta funktionerna är det värt att notera möjligheten att starta uppgifter enligt ett schema, på användarens begäran eller programmatiskt från sandlådan:
Här ser vi en annan roll - löpare. Den här rollen är tillståndslös och ytterligare applikationsinstanser med den här rollen kan läggas till i klustret efter behov. Löparens ansvar är att utföra uppgifter. Som nämnt är det möjligt att generera nya uppgifter från sandlådan; de sparas i en kö på lagring och exekveras sedan på löparen. Den här typen av uppgifter kallas Job. Vi har också en uppgiftstyp som heter Task - det här är användardefinierade uppgifter som körs enligt ett schema (med hjälp av cron-syntax) eller på begäran. För att starta och spåra sådana uppgifter har vi en bekväm uppgiftshanterare. För att denna funktionalitet ska vara tillgänglig måste du aktivera schemaläggarrollen; denna roll har ett tillstånd, så den skalas inte, vilket dock inte krävs; samtidigt, som alla andra roller, kan den ha en replika som börjar fungera om mästaren plötsligt vägrar.
logger
En annan roll kallas logger. Den samlar in loggar från alla medlemmar i klustret och tillhandahåller ett gränssnitt för uppladdning och visning av dem via webbgränssnittet.
Tjänster
Värt att nämna är att systemet gör det enkelt att skapa tjänster. I konfigurationsfilen kan du ange vilka förfrågningar som skickas till en användarskriven hanterare som körs i sandlådan. I den här hanteraren kan du till exempel köra någon form av analytisk fråga och returnera resultatet.
Tjänsten beskrivs i konfigurationsfilen:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
GraphQL API genereras automatiskt och tjänsten blir tillgänglig för anrop:
query {
sum(x: 1, y: 2)
}
Detta kommer att anropa hanteraren sumsom kommer att returnera resultatet:
3
Frågeprofilering och mätvärden
För att förstå hur systemet fungerar och profileringsförfrågningar implementerade vi stöd för OpenTracing-protokollet. Systemet kan skicka information på begäran till verktyg som stöder detta protokoll, såsom Zipkin, vilket gör att du kan förstå hur begäran utfördes:
Naturligtvis tillhandahåller systemet interna mått som kan samlas in med Prometheus och visualiseras med Grafana.
Distribuera
Tarantool Data Grid kan distribueras från RPM-paket eller ett arkiv, med hjälp av ett verktyg från distributionen eller Ansible, det finns också stöd för Kubernetes ().
Applikationen som implementerar affärslogiken (konfiguration, hanterare) laddas in i det distribuerade Tarantool Data Grid-klustret i form av ett arkiv via användargränssnittet eller med hjälp av ett skript via API:et som tillhandahålls av oss.
Exempel på applikationer
Vilka applikationer kan skapas med Tarantool Data Grid? Faktum är att de flesta affärsuppgifter på något sätt är relaterade till bearbetning, lagring och åtkomst av dataflöde. Därför, om du har stora strömmar av data som måste lagras och nås säkert, då kan vår produkt spara dig mycket utvecklingstid och fokusera på din affärslogik.
Vi vill till exempel samla information om fastighetsmarknaden, så att vi i framtiden till exempel har information om de bästa erbjudandena. I det här fallet kommer vi att belysa följande uppgifter:
- Robotar som samlar in information från öppna källor kommer att vara våra datakällor. Du kan lösa detta problem genom att använda färdiga lösningar eller skriva kod på vilket språk som helst.
- Därefter kommer Tarantool Data Grid att acceptera och spara data. Om dataformatet från olika källor är olika, kan du skriva kod i Lua som utför konverteringen till ett enda format. I förbearbetningsstadiet kommer du även att till exempel kunna filtrera dubbletter av erbjudanden eller dessutom uppdatera information om agenter som arbetar på marknaden i databasen.
- Nu har du redan en skalbar lösning i ett kluster som kan fyllas med data och göra dataval. Sedan kan du implementera ny funktionalitet, till exempel skriva en tjänst som gör en begäran om data och ger det mest fördelaktiga erbjudandet per dag - detta kommer att kräva några rader i konfigurationsfilen och lite Lua-kod.
Vad händer nu?
Vår prioritet är att förbättra användarvänligheten i utvecklingen . Detta är till exempel en IDE med stöd för profilering och felsökning av hanterare som körs i en sandlåda.
Vi lägger också stor vikt vid säkerhetsfrågor. Just nu genomgår vi certifiering av Rysslands FSTEC för att bekräfta den höga säkerhetsnivån och uppfylla kraven för certifiering av mjukvaruprodukter som används i informationssystem för personuppgifter och statliga informationssystem.
Källa: will.com