Kadras iš filmo „Mūsų slaptoji visata: paslėptas ląstelės gyvenimas“

Investicijų verslas yra viena sudėtingiausių sričių bankų pasaulyje, nes čia yra ne tik paskolos, skolinimai ir indėliai, bet ir vertybiniai popieriai, valiutos, prekės, išvestinės finansinės priemonės ir visokie sudėtingi struktūriniai produktai.

Pastaruoju metu pastebime, kad išaugo gyventojų finansinis raštingumas. Vis daugiau žmonių įsitraukia į prekybą vertybinių popierių rinkose. Individualios investicinės sąskaitos atsirado ne taip seniai. Jie leidžia prekiauti vertybinių popierių rinkose ir gauti mokesčių atskaitymus arba vengti mokėti mokesčius. O visi pas mus besikreipiantys klientai nori valdyti savo portfelį ir matyti ataskaitas realiu laiku. Be to, dažniausiai šis portfelis yra kelių produktų, tai yra, žmonės yra įvairių verslo linijų klientai.

Be to, auga ir Rusijos, ir užsienio reguliuotojų poreikiai.

Siekdami patenkinti dabartinius poreikius ir padėti pamatus būsimiems atnaujinimams, sukūrėme investicinio verslo branduolį, pagrįstą Tarantool.

Šiek tiek statistikos. Alfa-Bank investicinis verslas teikia tarpininkavimo paslaugas fiziniams ir juridiniams asmenims, suteikiančias galimybę prekiauti įvairiose vertybinių popierių rinkose, depozitoriumo paslaugas vertybinių popierių saugojimui, patikos valdymo paslaugas privataus ir didelio kapitalo asmenims, vertybinių popierių išleidimo paslaugas kitoms įmonėms. . „Alfa-Bank“ investicinis verslas apima daugiau nei 3 tūkstančius kotiruočių per sekundę, kurios atsisiunčiamos iš įvairių prekybos platformų. Per darbo dieną rinkose banko ar jo klientų vardu sudaroma daugiau nei 300 tūkst. Per sekundę išorinėse ir vidinėse platformose įvykdoma iki 5 tūkst. Tuo pačiu metu visi klientai, tiek vidiniai, tiek išoriniai, nori matyti savo pozicijas realiu laiku.

priešistorė

Kažkur nuo 2000-ųjų pradžios mūsų investicinio verslo sritys vystėsi savarankiškai: prekyba biržoje, tarpininkavimo paslaugos, prekyba valiutomis, prekyba vertybiniais popieriais ir įvairiomis išvestinėmis priemonėmis. Dėl to patekome į funkcinių šulinių spąstus. Kas tai yra? Kiekviena verslo sritis turi savo sistemas, kurios dubliuoja viena kitos funkcijas. Kiekviena sistema turi savo duomenų modelį, nors veikia su tomis pačiomis sąvokomis: sandoriai, priemonės, sandorio šalys, kotiruotės ir pan. Kiekvienai sistemai vystantis atskirai, atsirado įvairių technologijų zoologijos sodas.

Be to, sistemų kodų bazė jau gana pasenusi, nes kai kurie produktai atsirado 1990-ųjų viduryje. Kai kuriose srityse tai sulėtino kūrimo procesą ir kilo našumo problemų.

Reikalavimai naujam sprendimui

Įmonės suprato, kad technologinė transformacija yra gyvybiškai svarbi tolesnei plėtrai. Gavome užduotis:

1. Surinkite visus verslo duomenis vienoje greitoje saugykloje ir viename duomenų modelyje.
2. Neturime prarasti ar keisti šios informacijos.
3. Būtina versijuoti duomenis, nes bet kuriuo metu reguliuotojas gali paprašyti ankstesnių metų statistikos.
4. Turime ne tik sukurti naujas, madingas DBVS, bet ir sukurti platformą verslo problemoms spręsti.

Be to, mūsų architektai nustato savo sąlygas:

1. Naujasis sprendimas turi būti verslo klasės, tai yra jau turi būti išbandytas kai kuriose didelėse įmonėse.
2. Sprendimo veikimo režimas turi būti labai svarbus. Tai reiškia, kad turime vienu metu būti keliuose duomenų centruose ir ramiai išgyventi vieno duomenų centro gedimus.
3. Sistema turi būti reguliuojama horizontaliai. Faktas yra tas, kad visos mūsų dabartinės sistemos yra keičiamos tik vertikaliai, o dėl mažo aparatinės įrangos galios augimo jau pasiekėme lubas. Todėl atėjo momentas, kai mums reikia turėti horizontaliai keičiamą sistemą, kad išgyventume.
4. Be kita ko, mums buvo pasakyta, kad sprendimas turi būti pigus.

Ėjome standartiniu maršrutu: suformulavome reikalavimus ir susisiekėme su pirkimo skyriumi. Iš ten gavome sąrašą įmonių, kurios apskritai yra pasirengusios tai padaryti už mus. Visiems papasakojome apie problemą, o iš šešių gavome sprendimų įvertinimą.

Banke mes niekam tikę, mėgstame viską išbandyti patys. Todėl privaloma mūsų konkurso sąlyga buvo išlaikyti apkrovos testus. Suformulavome apkrovos testavimo užduotis, o trys iš šešių įmonių jau sutiko savo lėšomis įdiegti prototipinį sprendimą, pagrįstą atminties technologijomis, kad galėtų jį išbandyti.

Nepasakosiu, kaip viską išbandėme ir kiek laiko tai užtruko, tik apibendrinsiu: geriausius apkrovos testų rezultatus parodė Mail.ru grupės kūrimo komandos Tarantool pagrindu sukurtas prototipas. Pasirašėme sutartį ir pradėjome plėtrą. Iš Mail.ru grupės dirbo keturi žmonės, o iš Alfa-Bank – trys kūrėjai, trys sistemų analitikai, sprendimų architektas, produkto savininkas ir Scrum meistras.

Toliau papasakosiu apie tai, kaip mūsų sistema augo, kaip ji vystėsi, ką mes padarėme ir kodėl būtent taip.

Vystymasis

Pirmas klausimas, kurį uždavėme sau, buvo kaip gauti duomenis iš dabartinių sistemų. Nusprendėme, kad HTTP mums visai tinka, nes visos dabartinės sistemos tarpusavyje bendrauja siųsdamos XML arba JSON per HTTP.

Mes naudojame HTTP serverį, įmontuotą Tarantool, nes mums nereikia nutraukti SSL seansų, o jo našumo mums pakanka.

Kaip jau sakiau, visos mūsų sistemos veikia skirtinguose duomenų modeliuose, o įvesties metu turime perkelti objektą į modelį, kurį apibūdiname patys. Reikėjo kalbos, kuri leistų transformuoti duomenis. Mes pasirinkome imperatyvų Lua. Visus duomenų konvertavimo kodus paleidžiame smėlio dėžėje – tai saugi vieta, už kurios veikiantis kodas neperžengia. Norėdami tai padaryti, mes tiesiog įkeliame reikiamą kodą, sukurdami aplinką su funkcijomis, kurios negali nieko užblokuoti ar išmesti.

Po konvertavimo reikia patikrinti, ar duomenys atitinka mūsų kuriamą modelį. Ilgai diskutavome, koks turėtų būti modelis ir kokia kalba jį apibūdinti. Pasirinkome „Apache Avro“, nes kalba yra paprasta ir palaiko „Tarantool“. Naujos modelio ir individualaus kodo versijos gali būti pradėtos eksploatuoti kelis kartus per dieną, net esant apkrovai ar be jos, bet kuriuo paros metu ir labai greitai prisitaikyti prie pokyčių.

Po patikrinimo duomenys turi būti išsaugoti. Tai darome naudodami vshard (turime geografiškai išsklaidytas skeveldrų kopijas).

Be to, specifika tokia, kad daugumai mums duomenis siunčiančių sistemų nesvarbu, ar mes juos gavome, ar ne. Todėl nuo pat pradžių įdiegėme remonto eilę. Kas tai yra? Jei dėl kokių nors priežasčių objekto duomenys nekeičiami ar nepatikrinami, mes vis tiek patvirtiname gavimą, bet tuo pačiu išsaugome objektą remonto eilėje. Jis yra nuoseklus ir yra pagrindinėje verslo duomenų saugykloje. Iš karto parašėme jam administratoriaus sąsają, įvairias metrikas ir įspėjimus. Dėl to mes neprarandame duomenų. Net jei kas nors pasikeitė šaltinyje, jei pasikeitė duomenų modelis, mes iš karto tai aptiksime ir galėsime prisitaikyti.

Dabar jūs turite išmokti atkurti išsaugotus duomenis. Atidžiai išanalizavome savo sistemas ir pamatėme, kad klasikiniame „Java“ ir „Oracle“ pakete būtinai yra tam tikras ORM, kuris konvertuoja duomenis iš reliacinio į objektą. Taigi kodėl gi iš karto nepateikus objektų sistemoms grafiko pavidalu? Taigi mes laimingai priėmėme GraphQL, kuris atitiko visus mūsų poreikius. Tai leidžia jums gauti duomenis grafikų pavidalu ir ištraukti tik tai, ko jums reikia šiuo metu. Jūs netgi galite kurti API versiją gana lanksčiai.

Beveik iš karto supratome, kad mūsų išgaunamų duomenų nepakanka. Sukūrėme funkcijas, kurias galima susieti su modelio objektais – iš esmės skaičiuojamuosius laukus. Tai yra, prie lauko pridedame tam tikrą funkciją, kuri, pavyzdžiui, apskaičiuoja vidutinę pasiūlymo kainą. O išorinis vartotojas, kuris prašo duomenų, net nežino, kad tai skaičiuojamas laukas.

Įdiegta autentifikavimo sistema.

Tada pastebėjome, kad mūsų sprendime išsikristalizavo keli vaidmenys. Vaidmuo yra savotiškas funkcijų agregatorius. Paprastai vaidmenys turi skirtingus įrangos naudojimo profilius:

• T-Connect: tvarko gaunamus ryšius, CPU ribotas, mažas atminties suvartojimas, be būsenos.
• IB-Core: transformuoja duomenis, kuriuos gauna per Tarantool protokolą, tai yra, veikia su lentelėmis. Jis taip pat nesaugo būsenos ir yra keičiamas.
• Saugykla: saugo tik duomenis, nenaudoja jokios logikos. Šis vaidmuo įgyvendina paprasčiausias sąsajas. Keičiamas dėl vshard.

Tai yra, naudodamiesi vaidmenimis, mes atsiejome skirtingas klasterio dalis viena nuo kitos, kurios gali būti keičiamos nepriklausomai viena nuo kitos.

Taigi, sukūrėme asinchroninį operacijų duomenų srauto įrašymą ir taisymo eilę su administratoriaus sąsaja. Verslo požiūriu įrašymas yra asinchroninis: jei garantuotai įrašysime duomenis sau, nesvarbu kur, tada tai patvirtinsime. Jei tai nepatvirtina, vadinasi, kažkas nutiko ir duomenis reikia siųsti. Tai asinchroninis įrašymas.

Bandymai

Nuo pat projekto pradžios nusprendėme, kad bandysime įgyvendinti bandomąją plėtrą. Mes rašome vienetų testus Lua naudodami tarantool/tap sistemą, o integracijos testus Python programoje, naudodami pytest sistemą. Tuo pačiu į integracijos testų rašymą įtraukiame ir kūrėjus, ir analitikus.

Kaip mes naudojame bandomąjį vystymą?

Jei norime kokios nors naujos funkcijos, pirmiausia bandome parašyti jos testą. Kai aptinkame klaidą, pirmiausia parašome testą, o tik tada ištaisome. Iš pradžių taip dirbti sunku, kyla darbuotojų nesusipratimas, net sabotažas: „Dabar greitai sutvarkykim, padarykime ką nors naujo, o paskui uždenkime testais“. Tik šis „vėliau“ beveik niekada neateina.

Todėl pirmiausia reikia prisiversti rašyti testus ir paprašyti tai padaryti kitų. Patikėkite manimi, bandymais pagrįsta plėtra duoda naudos net ir trumpuoju laikotarpiu. Pajusite, kad jūsų gyvenimas tapo lengvesnis. Manome, kad 99% kodo dabar yra išbandyti. Tai atrodo daug, bet mes neturime jokių problemų: bandymai vykdomi kiekvieną kartą.

Tačiau labiausiai mėgstame apkrovos testavimą, kurį laikome svarbiausiu ir atliekame reguliariai.

Papasakosiu jums nedidelę istoriją apie tai, kaip atlikome pirmąjį vienos iš pirmųjų versijų apkrovos testavimo etapą. Įdiegėme sistemą į kūrėjo nešiojamąjį kompiuterį, įjungėme apkrovą ir gavome 4 tūkstančius operacijų per sekundę. Puikus rezultatas nešiojamam kompiuteriui. Įdiegėme jį ant virtualaus keturių serverių apkrovos stendo, silpnesnio nei gamybinėje. Išskleista iki minimumo. Paleidžiame jį ir gauname blogesnį rezultatą nei nešiojamajame kompiuteryje vienoje gijoje. Šoko turinys.

Mums buvo labai liūdna. Mes žiūrime į serverio apkrovą, bet pasirodo, kad jie neveikia.

Mes skambiname kūrėjams, ir jie mums, žmonėms, atvykusiems iš Java pasaulio, paaiškina, kad Tarantool yra vienos gijos. Jį efektyviai gali naudoti tik vienas procesoriaus branduolys esant apkrovai. Tada kiekviename serveryje įdiegėme maksimalų įmanomą Tarantool egzempliorių skaičių, įjungėme apkrovą ir jau gavome 14,5 tūkst. operacijų per sekundę.

Leisk man dar kartą paaiškinti. Dėl skirstymo į vaidmenis, kurie skirtingai naudoja išteklius, mūsų vaidmenys, atsakingi už ryšių apdorojimą ir duomenų transformavimą, apkrauna tik procesorių ir griežtai proporcingai apkrovai.

Šiuo atveju atmintis buvo naudojama tik gaunamiems ryšiams ir laikiniems objektams apdoroti.

Priešingai, saugojimo serveriuose procesoriaus apkrova padidėjo, bet daug lėčiau nei serveriuose, kurie apdoroja ryšius.

O atminties suvartojimas augo tiesiogiai proporcingai įkeltų duomenų kiekiui.

Paslaugos

Norėdami sukurti savo naują produktą kaip programų platformą, sukūrėme komponentą, skirtą paslaugoms ir bibliotekoms diegti.

Paslaugos nėra tik mažos kodo dalys, veikiančios kai kuriose srityse. Tai gali būti gana didelės ir sudėtingos struktūros, kurios yra klasterio dalis, tikrina atskaitos duomenis, vykdo verslo logiką ir pateikia atsakymus. Mes taip pat eksportuojame paslaugų schemą į „GraphQL“, o vartotojas gauna universalų prieigos tašką prie duomenų ir viso modelio apžiūrą. Tai labai patogu.

Kadangi paslaugose yra daug daugiau funkcijų, nusprendėme, kad turėtų būti bibliotekos, į kurias perkelsime dažnai naudojamą kodą. Juos įtraukėme į saugią aplinką, prieš tai patikrinę, ar tai mums nieko nelaužo. O dabar funkcijoms galime priskirti papildomas aplinkas bibliotekų pavidalu.

Norėjome turėti platformą ne tik saugojimui, bet ir skaičiavimui. O kadangi jau turėjome krūvą kopijų ir skeveldrų, tai įdiegėme savotišką paskirstytą skaičiavimą ir pavadinome jį map reduktoriumi, nes jis pasirodė panašus į originalų map redukavimą.

Senos sistemos

Ne visos mūsų senos sistemos gali mums paskambinti per HTTP ir naudoti GraphQL, nors jos palaiko protokolą. Todėl sukūrėme mechanizmą, kuris leidžia duomenis replikuoti į šias sistemas.

Jei kas nors pasikeičia, saugyklos vaidmenyje suaktyvinami unikalūs aktyvikliai, o pranešimas su pakeitimais patenka į apdorojimo eilę. Jis siunčiamas į išorinę sistemą naudojant atskirą replikatoriaus vaidmenį. Šis vaidmuo neišsaugo būsenos.

Nauji patobulinimai

Kaip prisimenate, verslo požiūriu įrašėme asinchroniškai. Bet tada jie suprato, kad to neužteks, nes yra tam tikra sistemų klasė, kuri turi iš karto gauti atsakymą apie operacijos būseną. Taigi mes išplėtėme savo GraphQL ir pridėjome mutacijų. Jie organiškai įsilieja į esamą darbo su duomenimis paradigmą. Mums tai yra vienas skaitymo ir rašymo taškas kitai sistemų klasei.

Taip pat supratome, kad vien paslaugų mums neužteks, nes yra gana sunkių ataskaitų, kurias reikia statyti kartą per dieną, per savaitę, per mėnesį. Tai gali užtrukti ilgai, o ataskaitos gali net blokuoti Tarantool įvykių kilpą. Todėl sukūrėme atskirus vaidmenis: planuotoją ir bėgiką. Bėgikai nesaugo būsenos. Jie atlieka sunkias užduotis, kurių mes negalime apskaičiuoti. Planuotojo vaidmuo stebi šių užduočių paleidimo grafiką, kuris aprašytas konfigūracijoje. Pačios užduotys saugomos toje pačioje vietoje kaip ir verslo duomenys. Kai ateina tinkamas laikas, planuotojas paima užduotį, duoda kokiam nors bėgikui, kuris suskaičiuoja ir išsaugo rezultatą.

Ne visos užduotys turi būti vykdomos pagal tvarkaraštį. Kai kurias ataskaitas reikia perskaityti pareikalavus. Kai tik atsiranda šis reikalavimas, smėlio dėžėje sukuriama užduotis ir siunčiama bėgikui vykdyti. Po kurio laiko vartotojas gauna asinchroninį atsakymą, kad viskas suskaičiuota ir ataskaita paruošta.

Iš pradžių laikėmės visų duomenų saugojimo, versijų versijų ir neištrinimo paradigmos. Tačiau gyvenime karts nuo karto vis tiek tenka ką nors ištrinti, dažniausiai kokią neapdorotą ar tarpinę informaciją. Remdamiesi pasibaigusiu galiojimo laiku, sukūrėme saugyklos valymo nuo pasenusių duomenų mechanizmą.

Taip pat suprantame, kad anksčiau ar vėliau ateis situacija, kai neužteks vietos duomenims saugoti atmintyje, tačiau vis dėlto duomenys turi būti saugomi. Šiems tikslams netrukus sukursime disko saugyklą.

išvada

Pradėjome nuo užduoties įkelti duomenis į vieną modelį ir praleidome tris mėnesius jį kurdami. Turėjome šešias duomenų tiekimo sistemas. Visas transformacijos kodas į vieną modelį yra apie 30 tūkstančių Lua eilučių. O didžioji dalis darbų dar laukia. Kartais pritrūksta motyvacijos iš kaimyninių komandų, atsiranda daug aplinkybių, kurios apsunkina darbą. Jei kada nors susidursite su panašia užduotimi, padauginkite laiką, kuris jums atrodo normalus jos įgyvendinimui, iš trijų ar net keturių.

Taip pat atminkite, kad esamos verslo procesų problemos negali būti išspręstos naudojant naują DBVS, net ir labai produktyvią. Ką turiu omenyje? Projekto pradžioje klientams sukūrėme įspūdį, kad dabar atsinešime naują greitą duomenų bazę ir gyvensime! Procesai vyks greičiau, viskas bus gerai. Tiesą sakant, technologijos neišsprendžia verslo procesų problemų, nes verslo procesai yra žmonės. Ir reikia dirbti su žmonėmis, o ne su technologijomis.

Bandymu pagrįstas kūrimas ankstyvosiose stadijose gali būti skausmingas ir atimantis daug laiko. Tačiau teigiamas jo poveikis bus pastebimas net per trumpą laiką, kai jums nereikės nieko daryti norint atlikti regresijos testą.

Labai svarbu atlikti apkrovos testavimą visuose kūrimo etapuose. Kuo anksčiau pastebėsite kokį nors architektūros trūkumą, tuo lengviau jį ištaisysite, o tai sutaupys daug laiko ateityje.

Su Lua nėra nieko blogo. Jame rašyti gali išmokti bet kas: „Java“ kūrėjas, „JavaScript“ kūrėjas, „Python“ kūrėjas, „front-end“ arba „back-end“. Net mūsų analitikai apie tai rašo.

Kai kalbame apie tai, kad neturime SQL, tai kelia siaubą žmonėms. „Kaip gauti duomenis be SQL? Ar tai įmanoma? Žinoma. OLTP klasės sistemoje SQL nereikia. Yra alternatyva tam tikros kalbos forma, kuri iš karto grąžina į dokumentą orientuotą vaizdą. Pavyzdžiui, GraphQL. Ir yra alternatyva paskirstytojo skaičiavimo forma.

Jei suprantate, kad reikės keisti mastelį, suprojektuokite savo sprendimą Tarantool taip, kad jis galėtų veikti lygiagrečiai dešimtyse Tarantool egzempliorių. Jei to nepadarysite, vėliau bus sunku ir skausminga, nes Tarantool gali efektyviai naudoti tik vieną procesoriaus branduolį.

Šaltinis: www.habr.com