Steeds uit die film "Our Secret Universe: The Hidden Life of the Cell"

Die beleggingsbesigheid is een van die mees komplekse gebiede in die bankwêreld, want daar is nie net lenings, lenings en deposito's nie, maar ook sekuriteite, geldeenhede, kommoditeite, afgeleide instrumente en allerhande kompleksiteite in die vorm van gestruktureerde produkte.

Onlangs het ons 'n toename in die finansiële geletterdheid van die bevolking gesien. Al hoe meer mense raak betrokke by handel in die effektemarkte. Individuele beleggingsrekeninge het nie so lank gelede verskyn nie. Hulle laat jou toe om die effektemarkte te verhandel en óf belastingaftrekkings te ontvang óf om belasting te vermy. En alle kliënte wat na ons toe kom, wil hul portefeulje bestuur en verslaggewing intyds sien. Boonop is hierdie portefeulje meestal multi-produk, dit wil sê, mense is kliënte van verskillende sakelyne.

Daarbenewens groei die behoeftes van reguleerders, beide Russies en buitelandse,.

Om aan huidige behoeftes te voldoen en die grondslag te lê vir toekomstige opgraderings, het ons 'n beleggingsbesigheidskern ontwikkel wat op Tarantool gebaseer is.

Sommige statistieke. Alfa-Bank se beleggingsbesigheid verskaf makelaarsdienste vir individue en regsentiteite om die geleentheid te bied om op verskeie sekuriteitemarkte handel te dryf, depositodienste vir die berging van sekuriteite, trustbestuursdienste vir individue met private en groot kapitaal, dienste vir die uitreiking van sekuriteite vir ander maatskappye . Alfa-Bank se beleggingsbesigheid sluit meer as 3 duisend kwotasies per sekonde in, wat van verskeie handelsplatforms afgelaai word. Gedurende die werksdag word meer as 300 duisend transaksies op die markte namens die bank of sy kliënte beklink. Tot 5 duisend bestellingsuitvoerings per sekonde vind plaas op eksterne en interne platforms. Terselfdertyd wil alle kliënte, beide intern en ekstern, hul posisies intyds sien.

voorgeskiedenis

Iewers vanaf die begin van die 2000's het ons areas van beleggingsbesigheid onafhanklik ontwikkel: valutahandel, makelaarsdienste, valutahandel, oor-die-toonbank-handel in sekuriteite en verskeie afgeleide instrumente. As gevolg hiervan het ons in die strik van funksionele putte getrap. Wat dit is? Elke bedryfslyn het sy eie stelsels wat mekaar se funksies dupliseer. Elke stelsel het sy eie datamodel, alhoewel hulle met dieselfde konsepte werk: transaksies, instrumente, teenpartye, kwotasies, ensovoorts. En soos elke stelsel onafhanklik ontwikkel het, het 'n diverse dieretuin van tegnologie na vore gekom.

Boonop is die kodebasis van die stelsels reeds redelik verouderd, omdat sommige produkte in die middel-1990's ontstaan ​​het. En in sommige gebiede het dit die ontwikkelingsproses vertraag, en daar was prestasieprobleme.

Vereistes vir 'n nuwe oplossing

Besighede het besef dat tegnologiese transformasie noodsaaklik is vir verdere ontwikkeling. Ons het take gekry:

1. Versamel alle besigheidsdata in 'n enkele, vinnige berging en in 'n enkele datamodel.
2. Ons mag nie hierdie inligting verloor of verander nie.
3. Dit is nodig om die data weer te gee, want die reguleerder kan op enige oomblik vir statistieke vir vorige jare vra.
4. Ons moet nie net 'n nuwe, modieuse DBBS bring nie, maar 'n platform skep om besigheidsprobleme op te los.

Daarbenewens stel ons argitekte hul eie voorwaardes:

1. Die nuwe oplossing moet ondernemingsklas wees, dit wil sê, dit moet reeds in sommige groot maatskappye getoets word.
2. Die oplossing se bedryfsmodus moet missiekritiek wees. Dit beteken dat ons gelyktydig in verskeie datasentrums teenwoordig moet wees en die onderbreking van een datasentrum rustig moet oorleef.
3. Die stelsel moet horisontaal skaalbaar wees. Die feit is dat al ons huidige stelsels slegs vertikaal skaalbaar is, en ons is reeds besig om die plafon te slaan weens die lae groei van hardeware krag. Daarom het die oomblik aangebreek wanneer ons 'n horisontaal skaalbare stelsel moet hê om te oorleef.
4. Ons is onder meer meegedeel dat die oplossing goedkoop moet wees.

Ons het die standaardroete gevolg: ons het die vereistes geformuleer en die aankoopafdeling gekontak. Van daar af het ons 'n lys van maatskappye ontvang wat oor die algemeen gereed is om dit vir ons te doen. Ons het almal van die probleem vertel en 'n beoordeling van die oplossings van ses van hulle ontvang.

By die bank vat ons niemand se woord daarvoor nie; ons hou daarvan om alles self te toets. Daarom was 'n verpligte voorwaarde van ons tenderkompetisie om lastoetse te slaag. Ons het vragtoetstake geformuleer, en drie uit ses maatskappye het reeds ingestem om 'n prototipe-oplossing gebaseer op in-geheue-tegnologie op hul eie koste te implementeer om dit te toets.

Ek sal jou nie vertel hoe ons alles getoets het en hoe lank dit geneem het nie, ek sal net opsom: die beste prestasie in lastoetse is getoon deur 'n prototipe-oplossing gebaseer op Tarantool van die Mail.ru Group-ontwikkelingspan. Ons het 'n ooreenkoms onderteken en met ontwikkeling begin. Daar was vier mense van Mail.ru Group, en van Alfa-Bank was daar drie ontwikkelaars, drie stelselontleders, 'n oplossingsargitek, 'n produkeienaar en 'n Scrum-meester.

Volgende sal ek jou vertel van hoe ons stelsel gegroei het, hoe dit ontwikkel het, wat ons gedoen het en hoekom presies dit.

ontwerp

Die eerste vraag wat ons onsself gevra het, was hoe om data uit ons huidige stelsels te kry. Ons het besluit dat HTTP baie geskik is vir ons, want alle huidige stelsels kommunikeer met mekaar deur XML of JSON oor HTTP te stuur.

Ons gebruik die HTTP-bediener wat in Tarantool ingebou is omdat ons nie SSL-sessies hoef te beëindig nie, en die werkverrigting daarvan is genoeg vir ons.

Soos ek reeds gesê het, leef al ons stelsels in verskillende datamodelle, en by die insette moet ons die voorwerp na die model bring wat ons self beskryf. 'n Taal was nodig wat toelaat dat data getransformeer word. Ons het die noodsaaklike Lua gekies. Ons voer alle data-omskakelingskode in 'n sandbox uit - dit is 'n veilige plek waarby die lopende kode nie gaan nie. Om dit te doen, laai ons eenvoudig die vereiste kode en skep 'n omgewing met funksies wat niks kan blokkeer of laat val nie.

Na omskakeling moet die data nagegaan word vir voldoening aan die model wat ons skep. Ons het lank bespreek wat die model moet wees en watter taal om te gebruik om dit te beskryf. Ons het Apache Avro gekies omdat die taal eenvoudig is en dit het ondersteuning van Tarantool. Nuwe weergawes van die model en pasgemaakte kode kan verskeie kere per dag in werking gestel word, selfs onder vrag of sonder, enige tyd van die dag, en baie vinnig by veranderinge aanpas.

Na verifikasie moet die data gestoor word. Ons doen dit met behulp van vshard (ons het geo-verspreide replikas van skerwe).

Boonop is die spesifisiteit sodanig dat die meeste stelsels wat vir ons data stuur nie omgee of ons dit ontvang het of nie. Daarom het ons van die begin af 'n hersteltou geïmplementeer. Wat dit is? As 'n voorwerp om een ​​of ander rede nie datatransformasie of verifikasie ondergaan nie, bevestig ons steeds ontvangs, maar stoor terselfdertyd die voorwerp in die herstelwaglys. Dit is konsekwent en geleë in die hoof besigheidsdatapakhuis. Ons het dadelik 'n administrateur-koppelvlak daarvoor geskryf, verskeie maatstawwe en waarskuwings. As gevolg hiervan verloor ons nie data nie. Selfs al het iets in die bron verander, as die datamodel verander het, sal ons dit dadelik opspoor en kan aanpas.

Nou moet jy leer hoe om gestoorde data te herwin. Ons het ons stelsels noukeurig ontleed en gesien dat die klassieke stapel Java en Oracle noodwendig 'n soort ORM bevat wat data van relasioneel na objek omskakel. So hoekom gee jy nie onmiddellik voorwerpe aan stelsels in die vorm van 'n grafiek nie? Daarom het ons GraphQL met graagte aangeneem, wat aan al ons behoeftes voldoen het. Dit laat jou toe om data in die vorm van grafieke te ontvang en net uit te trek wat jy nou nodig het. U kan selfs die API met nogal baie buigsaamheid weergawe.

Byna onmiddellik het ons besef dat die data wat ons onttrek nie genoeg was nie. Ons het funksies geskep wat aan voorwerpe in die model gekoppel kan word - in wese berekende velde. Dit wil sê, ons heg 'n sekere funksie aan die veld, wat byvoorbeeld die gemiddelde kwotasieprys bereken. En die eksterne verbruiker wat die data aanvra, weet nie eens dat dit 'n berekende veld is nie.

Het 'n verifikasiestelsel geïmplementeer.

Toe het ons opgemerk dat verskeie rolle in ons besluit uitgekristalliseer het. 'n Rol is 'n soort samevoeging van funksies. Tipies het rolle verskillende toerustinggebruikprofiele:

• T-Connect: hanteer inkomende verbindings, SVE beperk, lae geheueverbruik, staatloos.
• IB-Core: transformeer die data wat dit via die Tarantool-protokol ontvang, dit wil sê dit werk met tabelle. Dit stoor ook nie toestand nie en is skaalbaar.
• Berging: stoor slegs data, gebruik geen logika nie. Hierdie rol implementeer die eenvoudigste koppelvlakke. Skaalbaar danksy vshard.

Dit wil sê, met behulp van rolle het ons verskillende dele van die groepering van mekaar ontkoppel, wat onafhanklik van mekaar geskaal kan word.

Dus, ons het 'n asynchrone transaksionele datavloei-opname en 'n herstelwaglys met 'n administrasie-koppelvlak geskep. Die opname is asynchronies vanuit 'n besigheidsoogpunt: as ons gewaarborg is om data aan onsself te skryf, maak nie saak waar nie, dan sal ons dit bevestig. As dit nie bevestig word nie, het iets verkeerd geloop en die data moet gestuur word. Dit is die asynchrone opname.

toets

Van die begin van die projek af het ons besluit dat ons sal probeer om toetsgedrewe ontwikkeling te implementeer. Ons skryf eenheidstoetse in Lua deur die tarantool/tap-raamwerk te gebruik, en integrasietoetse in Python deur die pytest-raamwerk te gebruik. Terselfdertyd betrek ons ​​beide ontwikkelaars en ontleders by die skryf van integrasietoetse.

Hoe gebruik ons ​​toetsgedrewe ontwikkeling?

As ons 'n nuwe kenmerk wil hê, probeer ons eers 'n toets daarvoor skryf. Wanneer ons 'n fout ontdek, maak ons ​​seker dat ons eers 'n toets skryf, en dit dan eers regmaak. Aanvanklik is dit moeilik om so te werk, daar is misverstande by werknemers, selfs sabotasie: "Kom ons maak dit gou reg, doen iets nuuts en bedek dit dan met toetse." Net hierdie “later” kom amper nooit nie.

Daarom moet jy jouself dwing om eers toetse te skryf en ander vra om dit te doen. Glo my, toetsgedrewe ontwikkeling bring selfs op kort termyn voordele. Jy sal voel dat jou lewe makliker geword het. Ons voel dat 99% van die kode nou deur toetse gedek word. Dit lyk na baie, maar ons het geen probleme nie: toetse loop op elke commit.

Waarvan ons egter die meeste hou, is vragtoetsing; ons beskou dit as die belangrikste en voer dit gereeld uit.

Ek sal jou 'n klein storie vertel oor hoe ons die eerste fase van lastoetsing van een van die eerste weergawes uitgevoer het. Ons het die stelsel op die ontwikkelaar se skootrekenaar geïnstalleer, die las aangeskakel en 4 duisend transaksies per sekonde ontvang. Goeie resultaat vir 'n skootrekenaar. Ons het dit op 'n virtuele laaibank van vier bedieners geïnstalleer, swakker as in produksie. Ontplooi tot 'n minimum. Ons begin dit, en ons kry 'n erger resultaat as op 'n skootrekenaar in een draad. Skok inhoud.

Ons was baie hartseer. Ons kyk na die bedienerlading, maar dit blyk dat hulle ledig is.

Ons bel die ontwikkelaars, en hulle verduidelik vir ons, mense wat uit die wêreld van Java kom, dat Tarantool enkeldraad is. Dit kan slegs effektief gebruik word deur een verwerkerkern onder las. Toe het ons die maksimum moontlike aantal Tarantool-gevalle op elke bediener ontplooi, die las aangeskakel en reeds 14,5 duisend transaksies per sekonde ontvang.

Kom ek verduidelik weer. As gevolg van die verdeling in rolle wat hulpbronne verskillend gebruik, het ons rolle verantwoordelik vir die verwerking van verbindings en datatransformasie slegs die verwerker gelaai, en streng eweredig aan die las.

In hierdie geval is geheue slegs gebruik vir die verwerking van inkomende verbindings en tydelike voorwerpe.

Inteendeel, op stoorbedieners het die verwerkerlading toegeneem, maar baie stadiger as op bedieners wat verbindings verwerk.

En geheueverbruik het gegroei in direkte verhouding tot die hoeveelheid data wat gelaai is.

Dienste

Om ons nuwe produk spesifiek as 'n toepassingsplatform te ontwikkel, het ons 'n komponent geskep om dienste en biblioteke daarop te ontplooi.

Dienste is nie net klein stukkies kode wat op sommige velde werk nie. Dit kan redelik groot en komplekse strukture wees wat deel is van 'n groepering, verwysingsdata nagaan, besigheidslogika bestuur en antwoorde gee. Ons voer ook die diensskema na GraphQL uit, en die verbruiker ontvang 'n universele toegangspunt tot die data, met introspeksie oor die hele model. Dit is baie gemaklik.

Aangesien dienste baie meer funksies bevat, het ons besluit dat daar biblioteke moet wees waarin ons gereeld gebruikte kode sal skuif. Ons het hulle by die veilige omgewing gevoeg, nadat ons voorheen gekontroleer het dat dit niks vir ons breek nie. En nou kan ons addisionele omgewings toewys aan funksies in die vorm van biblioteke.

Ons wou 'n platform hê, nie net vir berging nie, maar ook vir rekenaars. En aangesien ons reeds 'n klomp replikas en skerwe gehad het, het ons 'n soort verspreide rekenaar geïmplementeer en dit kaartvermindering genoem, omdat dit soortgelyk aan die oorspronklike kaartvermindering geblyk het.

Ou stelsels

Nie al ons nalatenskapstelsels kan ons oor HTTP bel en GraphQL gebruik nie, hoewel hulle die protokol ondersteun. Daarom het ons 'n meganisme geskep wat dit moontlik maak om data in hierdie stelsels te repliseer.

As iets vir ons verander, word unieke snellers in die Berging-rol geaktiveer en die boodskap met die veranderinge beland in die verwerkingstou. Dit word na 'n eksterne stelsel gestuur deur 'n aparte replikatorrol te gebruik. Hierdie rol stoor nie staat nie.

Nuwe verbeterings

Soos u onthou, het ons uit 'n besigheidsoogpunt asinchroniese opname gedoen. Maar toe besef hulle dat dit nie genoeg sal wees nie, want daar is 'n klas stelsels wat onmiddellik 'n reaksie oor die status van die operasie moet ontvang. Ons het dus ons GraphQL uitgebrei en mutasies bygevoeg. Hulle pas organies in by die bestaande paradigma van werk met data. Vir ons is dit 'n enkele punt van beide lees en skryf vir 'n ander klas stelsels.

Ons het ook besef dat dienste alleen nie vir ons genoeg sal wees nie, want daar is nogal swaar verslae wat een keer per dag, 'n week, 'n maand gebou moet word. Dit kan lank neem, en verslae kan selfs Tarantool se gebeurtenislus blokkeer. Daarom het ons aparte rolle geskep: skeduleerder en hardloper. Hardlopers stoor nie toestand nie. Hulle voer swaar take uit wat ons nie dadelik kan bereken nie. En die skeduleerderrol monitor die bekendstellingskedule van hierdie take, wat in die konfigurasie beskryf word. Die take self word op dieselfde plek as besigheidsdata gestoor. Wanneer die regte tyd aanbreek, neem die skeduleerder die taak, gee dit aan een of ander hardloper, wat dit tel en die resultaat stoor.

Nie alle take hoef volgens 'n skedule uitgevoer te word nie. Sommige verslae moet op aanvraag gelees word. Sodra hierdie vereiste aanbreek, word 'n taak in die sandbox geskep en na die hardloper gestuur vir uitvoering. Na 'n rukkie ontvang die gebruiker 'n asynchrone reaksie dat alles bereken is en die verslag gereed is.

Aanvanklik het ons by die paradigma gehou om alle data te stoor, dit te weergawe en nie uit te vee nie. Maar in die lewe moet jy van tyd tot tyd nog iets uitvee, meestal 'n paar rou of intermediêre inligting. Gebaseer op vervaldatum, het ons 'n meganisme geskep om die berging van verouderde data skoon te maak.

Ons verstaan ​​ook dat daar vroeër of later 'n situasie sal ontstaan ​​wanneer daar nie genoeg spasie sal wees om data in die geheue te stoor nie, maar die data moet tog gestoor word. Vir hierdie doeleindes sal ons binnekort skyfberging maak.

Gevolgtrekking

Ons het begin met die taak om data in 'n enkele model te laai en het drie maande daaraan bestee om dit te ontwikkel. Ons het ses dataverskaffingstelsels gehad. Die hele transformasiekode in 'n enkele model is ongeveer 30 duisend reëls in Lua. En die meeste van die werk lê nog voor. Soms is daar 'n gebrek aan motivering van naburige spanne, en daar is baie omstandighede wat die werk bemoeilik. As jy ooit voor 'n soortgelyke taak te staan ​​kom, vermenigvuldig dan die tyd wat vir jou normaal lyk vir die implementering daarvan met drie, of selfs vier.

Onthou ook dat bestaande probleme in besigheidsprosesse nie met 'n nuwe DBBS opgelos kan word nie, selfs 'n baie produktiewe een. Wat ek bedoel? Aan die begin van ons projek het ons die indruk onder kliënte geskep dat ons nou 'n nuwe vinnige databasis sal bring, en ons sal lewe! Die prosesse sal vinniger verloop, alles sal reg wees. Trouens, tegnologie los nie die probleme op wat besigheidsprosesse het nie, want besigheidsprosesse is mense. En jy moet met mense werk, nie tegnologie nie.

Toetsgedrewe ontwikkeling kan in die vroeë stadiums pynlik en tydrowend wees. Maar die positiewe effek daarvan sal selfs op kort termyn merkbaar wees, wanneer jy niks hoef te doen om regressietoetsing uit te voer nie.

Dit is uiters belangrik om lastoetsing in alle stadiums van ontwikkeling uit te voer. Hoe gouer jy 'n fout in die argitektuur opmerk, hoe makliker sal dit wees om dit reg te stel, wat jou in die toekoms baie tyd sal bespaar.

Daar is niks fout met Lua nie. Enigeen kan leer om daarin te skryf: Java-ontwikkelaar, JavaScript-ontwikkelaar, Python-ontwikkelaar, front-end of back-end. Selfs ons ontleders skryf daaroor.

As ons praat oor die feit dat ons nie SQL het nie, maak dit mense bang. “Hoe kry jy data sonder SQL? Is dit moontlik? Sekerlik. In 'n OLTP-klasstelsel is SQL nie nodig nie. Daar is 'n alternatief in die vorm van 'n soort taal wat jou dadelik terugbring na 'n dokument-georiënteerde siening. Byvoorbeeld, GraphQL. En daar is 'n alternatief in die vorm van verspreide rekenaars.

As jy verstaan ​​dat jy sal moet skaal, ontwerp dan jou oplossing op Tarantool op so 'n manier dat dit parallel kan loop op dosyne Tarantool-gevalle. As jy dit nie doen nie, sal dit later moeilik en pynlik wees, aangesien Tarantool slegs een verwerkerkern effektief kan gebruik.

Bron: will.com