In 2017 het ons 'n kompetisie gewen om die transaksionele kern van Alfa-Bank se beleggingsbesigheid te ontwikkel en begin werk (by HighLoad++ 2018 met 'n verslag oor die kern van die beleggingsbesigheid Vladimir Drynkin, hoof van die transaksionele kern van die beleggingsbesigheid van Alfa Bank). Hierdie stelsel was veronderstel om transaksiedata van verskillende bronne in verskeie formate saam te voeg, die data in 'n verenigde vorm te bring, dit te stoor en toegang daartoe te verskaf.
Tydens die ontwikkelingsproses het die stelsel ontwikkel en funksionaliteit verkry, en op 'n stadium het ons besef dat ons besig was om iets veel meer te kristalliseer as net toepassingsagteware wat geskep is om 'n streng gedefinieerde reeks take op te los: ons het daarin geslaag stelsel vir die bou van verspreide toepassings met aanhoudende berging. Die ervaring wat ons opgedoen het, het die basis gevorm van 'n nuwe produk - (TDG).
Ek wil praat oor die TDG-argitektuur en die oplossings waartoe ons tydens die ontwikkelingsproses gekom het, jou bekendstel aan die hooffunksionaliteit en wys hoe ons produk die basis kan word vir die bou van volledige oplossings.
Argitektonies het ons die stelsel in aparte verdeel rol, wat elkeen verantwoordelik is vir die oplossing van 'n sekere reeks probleme. 'n Enkellopende toepassingsinstansie implementeer een of meer roltipes. Daar kan verskeie rolle van dieselfde tipe in 'n groep wees:
connector
Connector is verantwoordelik vir kommunikasie met die buitewêreld; sy taak is om die versoek te aanvaar, dit te ontleed, en indien dit slaag, stuur dan die data vir verwerking na die invoerverwerker. Ons ondersteun HTTP, SOAP, Kafka, FIX formate. Die argitektuur laat jou toe om eenvoudig ondersteuning vir nuwe formate by te voeg, met ondersteuning vir IBM MQ wat binnekort kom. As die ontleding van die versoek misluk het, sal die koppelaar 'n fout terugstuur; anders sal dit reageer dat die versoek suksesvol verwerk is, selfs al het 'n fout tydens die verdere verwerking daarvan voorgekom. Dit is spesifiek gedoen om met stelsels te werk wat nie weet hoe om versoeke te herhaal nie – of, inteendeel, dit te aanhoudend doen. Om nie data te verloor nie, word 'n herstelwaglys gebruik: die voorwerp kom eers daarin en word eers na suksesvolle verwerking daarvan verwyder. Die administrateur kan waarskuwings ontvang oor voorwerpe wat in die herstelwaglys oorbly, en nadat 'n sagtewarefout of hardewarefout uitgeskakel is, probeer weer.
Invoer verwerker
Die invoerverwerker klassifiseer die ontvangde data volgens kenmerkende kenmerke en roep toepaslike verwerkers. Hanteerders is Lua-kode wat in 'n sandbox loop, dus kan hulle nie die werking van die stelsel beïnvloed nie. Op hierdie stadium kan die data tot die verlangde vorm gereduseer word, en, indien nodig, kan 'n arbitrêre aantal take geloods word wat die nodige logika kan implementeer. Byvoorbeeld, in die MDM (Master Data Management) produk gebou op Tarantool Data Grid, wanneer 'n nuwe gebruiker bygevoeg word, om nie die verwerking van die versoek te vertraag nie, begin ons die skepping van 'n goue rekord as 'n aparte taak. Die sandbox ondersteun versoeke vir die lees, verandering en byvoeging van data, laat jou toe om een of ander funksie op alle rolle van die bergingstipe en samevoeging van die resultaat uit te voer (kaart/verminder).
Hanteerders kan beskryf word in lêers:
sum.lua
local x, y = unpack(...)
return x + yEn dan, verklaar in die konfigurasie:
functions:
sum: { __file: sum.lua }
Hoekom Lua? Lua is 'n baie eenvoudige taal. Op grond van ons ervaring begin mense 'n paar uur nadat hulle dit leer ken het, kode skryf wat hul probleem oplos. En dit is nie net professionele ontwikkelaars nie, maar, byvoorbeeld, ontleders. Boonop, danksy die jit-samesteller, loop Lua baie vinnig.
stoor
Berging stoor volgehoue data. Voordat dit gestoor word, word data teen die dataskema bekragtig. Om die stroombaan te beskryf gebruik ons 'n uitgebreide formaat . 'N 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 grond van hierdie beskrywing word DDL (Data Definition Language) outomaties gegenereer vir die Tarantula DBMS en skema vir toegang tot data.
Asinchroniese data-replikasie word ondersteun (daar is planne om sinchrone een by te voeg).
Uitset verwerker
Soms is dit nodig om eksterne verbruikers in kennis te stel van die aankoms van nuwe data; vir hierdie doel is daar die Uitsetverwerker-rol. Nadat die data gestoor is, kan dit na die ooreenstemmende hanteerder oorgedra word (byvoorbeeld om dit na die vorm te bring wat deur die verbruiker vereis word) - en dan na die koppelaar oorgedra word vir versending. 'n Herstelry word ook hier gebruik: as niemand die voorwerp aanvaar het nie, kan die administrateur later weer probeer.
Skaal
Die koppelaar-, invoerverwerker- en uitsetverwerkerrolle is staatloos, wat ons in staat stel om die stelsel horisontaal te skaal deur eenvoudig nuwe toepassinggevalle by te voeg met die gewenste roltipe geaktiveer. Berging word gebruik vir horisontale skaal om 'n groepering met behulp van virtuele emmers te organiseer. Nadat 'n nuwe bediener bygevoeg is, word sommige van die emmers van die ou bedieners na die nuwe bediener in die agtergrond geskuif; dit gebeur deursigtig vir gebruikers en beïnvloed nie die werking van die hele stelsel nie.
Data Eienskappe
Voorwerpe kan baie groot wees en ander voorwerpe bevat. Ons verseker atomiteit van die byvoeging en opdatering van data deur 'n voorwerp met alle afhanklikhede in een virtuele emmer te stoor. Dit verhoed dat die voorwerp oor verskeie fisiese bedieners "verspreid" word.
Weergawe word ondersteun: elke opdatering van 'n voorwerp skep 'n nuwe weergawe, en ons kan altyd 'n tydstuk neem en sien hoe die wêreld toe gelyk het. Vir data wat nie 'n lang geskiedenis nodig het nie, kan ons die aantal weergawes beperk of selfs net een stoor - die nuutste een - dit wil sê, in wese weergawe deaktiveer vir 'n sekere tipe. Jy kan ook die geskiedenis volgens tyd beperk: vee byvoorbeeld alle voorwerpe van 'n sekere tipe ouer as 1 jaar uit. Argiefering word ook ondersteun: ons kan voorwerpe ouer as die gespesifiseerde tyd aflaai, wat spasie in die groep vrymaak.
take
Onder die interessante kenmerke is dit die moeite werd om te let op die vermoë om take op 'n skedule te begin, op die gebruiker se versoek, of programmaties vanaf die sandbox:
Hier sien ons nog 'n rol - hardloper. Hierdie rol is staatloos, en bykomende toepassinggevalle met hierdie rol kan soos nodig by die groep gevoeg word. Die hardloper se verantwoordelikheid is om take te voltooi. Soos genoem, is dit moontlik om nuwe take uit die sandbox te genereer; hulle word in 'n tou op stoor gestoor en dan op die hardloper uitgevoer. Hierdie tipe taak word Job genoem. Ons het ook 'n taaktipe genaamd Taak - dit is gebruikergedefinieerde take wat volgens 'n skedule (met behulp van cron-sintaksis) of op aanvraag loop. Om sulke take te begin en op te spoor, het ons 'n gerieflike taakbestuurder. Om hierdie funksionaliteit beskikbaar te maak, moet jy die skeduleerderrol aktiveer; hierdie rol het 'n toestand, so dit skaal nie, wat egter nie vereis word nie; terselfdertyd, soos alle ander rolle, kan dit 'n replika hê wat begin werk as die meester skielik weier.
logger
Nog 'n rol word logger genoem. Dit versamel logs van alle lede van die groepering en bied 'n koppelvlak om dit op te laai en deur die webkoppelvlak te bekyk.
Dienste
Dit is die moeite werd om te noem dat die stelsel dit maklik maak om dienste te skep. In die konfigurasielêer kan jy spesifiseer watter versoeke na 'n gebruikergeskrewe hanteerder gestuur word wat in die sandbox loop. In hierdie hanteerder kan jy byvoorbeeld 'n soort analitiese navraag uitvoer en die resultaat terugstuur.
Die diens word beskryf in die konfigurasielêer:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
Die GraphQL API word outomaties gegenereer en die diens word beskikbaar om te bel:
query {
sum(x: 1, y: 2)
}
Dit sal die hanteerder roep sumwat die resultaat sal gee:
3
Navrae profilering en statistieke
Om die werking van die stelsel en profielversoeke te verstaan, het ons ondersteuning vir die OpenTracing-protokol geïmplementeer. Die stelsel kan inligting op aanvraag stuur na gereedskap wat hierdie protokol ondersteun, soos Zipkin, wat jou sal toelaat om te verstaan hoe die versoek uitgevoer is:
Natuurlik verskaf die stelsel interne maatstawwe wat met behulp van Prometheus ingesamel en met Grafana gevisualiseer kan word.
Ontplooi
Tarantool Data Grid kan ontplooi word vanaf RPM-pakkette of 'n argief, met behulp van 'n nut van die verspreiding of Ansible, daar is ook ondersteuning vir Kubernetes ().
Die toepassing wat die besigheidslogika (konfigurasie, hanteerders) implementeer, word in die ontplooide Tarantool Data Grid-groepering gelaai in die vorm van 'n argief deur die UI of met behulp van 'n skrif deur die API wat deur ons verskaf word.
Beginsels van filosofie
Watter toepassings kan met Tarantool Data Grid geskep word? Trouens, die meeste saketake hou op een of ander manier verband met die verwerking, berging en toegang tot datavloei. As jy dus groot strome data het wat veilig gestoor en toegang verkry moet word, dan kan ons produk jou baie ontwikkelingstyd bespaar en op jou besigheidslogika fokus.
Ons wil byvoorbeeld inligting oor die eiendomsmark insamel, sodat ons in die toekoms byvoorbeeld inligting oor die beste aanbiedinge sal hê. In hierdie geval sal ons die volgende take uitlig:
- Robotte wat inligting van oop bronne insamel, sal ons databronne wees. Jy kan hierdie probleem oplos deur klaargemaakte oplossings te gebruik of kode in enige taal te skryf.
- Vervolgens sal Tarantool Data Grid die data aanvaar en stoor. As die dataformaat van verskillende bronne anders is, kan u kode in Lua skryf wat die omskakeling na 'n enkele formaat sal uitvoer. In die voorverwerkingstadium sal jy ook byvoorbeeld duplikaataanbiedinge kan filtreer of addisioneel inligting oor agente wat in die mark werk in die databasis kan bywerk.
- Nou het jy reeds 'n skaalbare oplossing in 'n groepering wat met data gevul kan word en datakeuses kan maak. Dan kan jy nuwe funksionaliteit implementeer, byvoorbeeld 'n diens skryf wat 'n versoek vir data sal maak en die mees voordelige aanbod per dag sal gee - dit sal 'n paar reëls in die konfigurasielêer en 'n bietjie Lua-kode vereis.
Wat is volgende?
Ons prioriteit is om die gemak van ontwikkeling te verbeter . Byvoorbeeld, dit is 'n IDE met ondersteuning vir profilering en ontfouting van hanteerders wat in 'n sandbox loop.
Ons gee ook baie aandag aan veiligheidskwessies. Op die oomblik ondergaan ons sertifisering deur FSTEC van Rusland om die hoë vlak van sekuriteit te bevestig en te voldoen aan die vereistes vir sertifisering van sagtewareprodukte wat in persoonlike data-inligtingstelsels en regeringsinligtingstelsels gebruik word.
Bron: will.com