In 2017 wonnen we een wedstrijd om de transactionele kern van de beleggingsactiviteiten van Alfa-Bank te ontwikkelen en gingen we aan de slag (op HighLoad++ 2018 met een rapport over de kern van de beleggingsactiviteiten Vladimir Drynkin, hoofd van de transactionele kern van de investeringsactiviteiten van Alfa Bank). Dit systeem moest transactiegegevens uit verschillende bronnen in verschillende formaten samenvoegen, de gegevens in een uniforme vorm brengen, opslaan en er toegang toe verschaffen.
Tijdens het ontwikkelingsproces evolueerde het systeem en verwierf het functionaliteit, en op een gegeven moment realiseerden we ons dat we iets veel meer aan het kristalliseren waren dan alleen applicatiesoftware die was gemaakt om een strikt gedefinieerde reeks taken op te lossen: we zijn erin geslaagd systeem voor het bouwen van gedistribueerde applicaties met permanente opslag. De opgedane ervaring vormde de basis van een nieuw product - (TDG).
Ik wil het hebben over de TDG-architectuur en de oplossingen waar we tijdens het ontwikkelingsproces tot zijn gekomen, je kennis laten maken met de belangrijkste functionaliteit en laten zien hoe ons product de basis kan worden voor het bouwen van complete oplossingen.
Architectonisch hebben we het systeem in afzonderlijke delen verdeeld rol, die elk verantwoordelijk zijn voor het oplossen van een bepaald scala aan problemen. Eén actief toepassingsexemplaar implementeert een of meer roltypen. Er kunnen meerdere rollen van hetzelfde type in een cluster voorkomen:
connector
Connector is verantwoordelijk voor de communicatie met de buitenwereld; zijn taak is om het verzoek te accepteren, te parseren en als dit lukt, de gegevens ter verwerking naar de invoerprocessor te sturen. We ondersteunen HTTP-, SOAP-, Kafka- en FIX-formaten. Dankzij de architectuur kunt u eenvoudig ondersteuning voor nieuwe formaten toevoegen, waarbij binnenkort ondersteuning voor IBM MQ beschikbaar komt. Als het parseren van het verzoek mislukt, retourneert de connector een fout; anders zal het antwoorden dat het verzoek met succes is verwerkt, zelfs als er een fout is opgetreden tijdens de verdere verwerking ervan. Dit is specifiek gedaan om te werken met systemen die niet weten hoe ze verzoeken moeten herhalen - of, integendeel, het te volhardend doen. Om geen gegevens te verliezen, wordt een reparatiewachtrij gebruikt: het object komt er eerst in en wordt pas na succesvolle verwerking eruit verwijderd. De beheerder kan waarschuwingen ontvangen over objecten die nog in de reparatiewachtrij staan, en nadat hij een softwarefout of hardwarefout heeft verholpen, kan hij het opnieuw proberen.
Invoerprocessor
De invoerprocessor classificeert de ontvangen gegevens volgens karakteristieke kenmerken en roept geschikte processors op. Handlers zijn Lua-code die in een sandbox draait en dus geen invloed hebben op de werking van het systeem. In dit stadium kunnen de gegevens worden teruggebracht tot de vereiste vorm en, indien nodig, kan een willekeurig aantal taken worden gestart die de noodzakelijke logica kunnen implementeren. In het MDM-product (Master Data Management) dat is gebouwd op Tarantool Data Grid, lanceren we bijvoorbeeld bij het toevoegen van een nieuwe gebruiker het aanmaken van een gouden record als een afzonderlijke taak, om de verwerking van het verzoek niet te vertragen. De sandbox ondersteunt verzoeken voor het lezen, wijzigen en toevoegen van gegevens, stelt u in staat een bepaalde functie uit te voeren op alle rollen van het opslagtype en aggregatie van het resultaat (toewijzen/verminderen).
Handlers kunnen worden beschreven in bestanden:
sum.lua
local x, y = unpack(...)
return x + yEn dan, aangegeven in de configuratie:
functions:
sum: { __file: sum.lua }
Waarom Lua? Lua is een heel eenvoudige taal. Op basis van onze ervaring beginnen mensen een paar uur nadat ze het hebben leren kennen, code te schrijven die hun probleem oplost. En dit zijn niet alleen professionele ontwikkelaars, maar bijvoorbeeld analisten. Bovendien werkt Lua dankzij de jit-compiler erg snel.
Opbergen
Opslag slaat persistente gegevens op. Voordat gegevens worden opgeslagen, worden ze gevalideerd aan de hand van het gegevensschema. Om het circuit te beschrijven gebruiken we een uitgebreid formaat . Voorbeeld:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Op basis van deze beschrijving wordt DDL (Data Definition Language) automatisch gegenereerd voor de Tarantula DBMS en schema voor gegevenstoegang.
Asynchrone gegevensreplicatie wordt ondersteund (er zijn plannen om synchrone toe te voegen).
Uitvoerprocessor
Soms is het nodig om externe consumenten op de hoogte te stellen van de komst van nieuwe data, hiervoor is er de rol Outputverwerker. Nadat de gegevens zijn opgeslagen, kunnen deze worden doorgegeven aan de overeenkomstige behandelaar (bijvoorbeeld om deze in de door de consument gewenste vorm te brengen) - en vervolgens worden doorgegeven aan de connector voor verzending. Ook hier wordt gebruik gemaakt van een reparatiewachtrij: als niemand het object heeft geaccepteerd, kan de beheerder het later opnieuw proberen.
scaling
De connector-, invoerprocessor- en uitvoerprocessorrollen zijn staatloos, waardoor we het systeem horizontaal kunnen schalen door eenvoudigweg nieuwe applicatie-instanties toe te voegen waarbij het gewenste roltype is ingeschakeld. Opslag wordt gebruikt voor horizontaal schalen tot het organiseren van een cluster met behulp van virtuele buckets. Na het toevoegen van een nieuwe server worden een aantal buckets van de oude servers op de achtergrond naar de nieuwe server verplaatst; dit gebeurt transparant voor gebruikers en heeft geen invloed op de werking van het hele systeem.
Gegevenseigenschappen
Objecten kunnen erg groot zijn en andere objecten bevatten. We zorgen voor atomiciteit bij het toevoegen en bijwerken van gegevens door een object met alle afhankelijkheden in één virtuele bucket op te slaan. Dit voorkomt dat het object wordt “verspreid” over meerdere fysieke servers.
Versiebeheer wordt ondersteund: elke update van een object creëert een nieuwe versie, en we kunnen altijd een momentopname nemen en zien hoe de wereld er toen uitzag. Voor gegevens die geen lange geschiedenis nodig hebben, kunnen we het aantal versies beperken of zelfs slechts één versie opslaan (de nieuwste versie). Dat wil zeggen dat we het versiebeheer voor een bepaald type feitelijk uitschakelen. Je kunt de historie ook beperken op tijd: verwijder bijvoorbeeld alle objecten van een bepaald type ouder dan 1 jaar. Ook archivering wordt ondersteund: we kunnen objecten die ouder zijn dan de opgegeven tijd ontladen, waardoor er ruimte vrijkomt in het cluster.
taken
Onder de interessante functies is het vermeldenswaard de mogelijkheid om taken volgens een schema, op verzoek van de gebruiker of programmatisch vanuit de sandbox te starten:
Hier zien we een andere rol: hardloper. Deze rol is staatloos en er kunnen indien nodig extra toepassingsinstanties met deze rol aan het cluster worden toegevoegd. De verantwoordelijkheid van de hardloper is het voltooien van taken. Zoals gezegd is het mogelijk om nieuwe taken vanuit de sandbox te genereren; ze worden opgeslagen in een wachtrij bij opslag en vervolgens uitgevoerd op de runner. Dit type taak wordt Job genoemd. We hebben ook een taaktype genaamd Taak - dit zijn door de gebruiker gedefinieerde taken die volgens een schema (met behulp van de cron-syntaxis) of op aanvraag worden uitgevoerd. Om dergelijke taken te starten en bij te houden, hebben we een handige taakbeheerder. Om deze functionaliteit beschikbaar te maken, moet u de plannerrol inschakelen; deze rol heeft een status en is dus niet schaalbaar, wat echter niet vereist is; Tegelijkertijd kan het, net als alle andere rollen, een replica hebben die begint te werken als de meester plotseling weigert.
Houthakker
Een andere rol wordt logger genoemd. Het verzamelt logbestanden van alle leden van het cluster en biedt een interface voor het uploaden en bekijken ervan via de webinterface.
Services
Het is vermeldenswaard dat het systeem het eenvoudig maakt om services te creëren. In het configuratiebestand kunt u opgeven welke verzoeken worden verzonden naar een door de gebruiker geschreven handler die in de sandbox draait. In deze handler kunt u bijvoorbeeld een soort analytische query uitvoeren en het resultaat retourneren.
De service wordt beschreven in het configuratiebestand:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
De GraphQL API wordt automatisch gegenereerd en de service wordt beschikbaar voor oproepen:
query {
sum(x: 1, y: 2)
}
Deze zal de handler bellen sumwat het resultaat zal opleveren:
3
Queryprofilering en statistieken
Om de werking van het systeem en profileringsverzoeken te begrijpen, hebben we ondersteuning voor het OpenTracing-protocol geïmplementeerd. Het systeem kan op verzoek informatie sturen naar tools die dit protocol ondersteunen, zoals Zipkin, waardoor u kunt begrijpen hoe het verzoek is uitgevoerd:
Uiteraard biedt het systeem interne statistieken die kunnen worden verzameld met Prometheus en gevisualiseerd met Grafana.
Aanwenden
Tarantool Data Grid kan worden ingezet vanuit RPM-pakketten of een archief, met behulp van een hulpprogramma uit de distributie of Ansible, er is ook ondersteuning voor Kubernetes ().
De applicatie die de bedrijfslogica implementeert (configuratie, handlers) wordt in het geïmplementeerde Tarantool Data Grid-cluster geladen in de vorm van een archief via de gebruikersinterface of met behulp van een script via de door ons geleverde API.
Inleidingen van de filosofie
Welke applicaties kunnen worden gemaakt met Tarantool Data Grid? In feite zijn de meeste zakelijke taken op de een of andere manier gerelateerd aan het verwerken, opslaan en openen van gegevensstromen. Als u dus grote gegevensstromen heeft die veilig moeten worden opgeslagen en toegankelijk, kan ons product u veel ontwikkelingstijd besparen en u concentreren op uw bedrijfslogica.
Zo willen wij informatie verzamelen over de vastgoedmarkt, zodat wij bijvoorbeeld in de toekomst informatie hebben over de beste aanbiedingen. In dit geval zullen we de volgende taken benadrukken:
- Robots die informatie verzamelen uit open bronnen zullen onze databronnen zijn. U kunt dit probleem oplossen met kant-en-klare oplossingen of door code in elke taal te schrijven.
- Vervolgens accepteert Tarantool Data Grid de gegevens en slaat deze op. Als het gegevensformaat uit verschillende bronnen verschillend is, kunt u in Lua code schrijven die de conversie naar één enkel formaat uitvoert. In de voorverwerkingsfase kunt u bijvoorbeeld ook dubbele aanbiedingen filteren of bovendien informatie over agenten die op de markt actief zijn in de database bijwerken.
- Nu heb je al een schaalbare oplossing in een cluster die gevuld kan worden met data en dataselecties kan maken. Vervolgens kunt u nieuwe functionaliteit implementeren, bijvoorbeeld een service schrijven die gegevens opvraagt en de meest voordelige aanbieding per dag doet - hiervoor zijn een paar regels in het configuratiebestand en een beetje Lua-code nodig.
Wat is het volgende?
Onze prioriteit is het verbeteren van het ontwikkelingsgemak met behulp van . Dit is bijvoorbeeld een IDE met ondersteuning voor het profileren en debuggen van handlers die in een sandbox draaien.
Ook besteden wij veel aandacht aan veiligheidsaspecten. Op dit moment ondergaan we certificering door FSTEC uit Rusland om het hoge beveiligingsniveau te bevestigen en te voldoen aan de vereisten voor certificering van softwareproducten die worden gebruikt in persoonlijke gegevensinformatiesystemen en overheidsinformatiesystemen.
Bron: www.habr.com