Enn úr myndinni „Our Secret Universe: The Hidden Life of the Cell“

Fjárfestingarviðskiptin eru eitt flóknasta svið bankaheimsins því þar eru ekki bara útlán, lántökur og innlán heldur líka verðbréf, gjaldmiðlar, hrávörur, afleiður og alls kyns margbreytileiki í formi skipulagðra vara.

Undanfarið höfum við séð aukið fjármálalæsi almennings. Sífellt fleiri taka þátt í viðskiptum á verðbréfamörkuðum. Einstakir fjárfestingarreikningar birtust fyrir ekki svo löngu síðan. Þeir gera þér kleift að eiga viðskipti á verðbréfamörkuðum og annað hvort fá skattafslátt eða forðast að borga skatta. Og allir viðskiptavinir sem koma til okkar vilja stjórna eignasafni sínu og sjá skýrslur í rauntíma. Þar að auki, oftast er þetta eignasafn fjölvöru, það er að segja að fólk er viðskiptavinir í ýmsum viðskiptagreinum.

Auk þess fara þarfir eftirlitsaðila, bæði rússneskra og erlendra, vaxandi.

Til að mæta núverandi þörfum og leggja grunn að framtíðaruppfærslum höfum við þróað fjárfestingarviðskiptakjarna sem byggir á Tarantool.

Einhver tölfræði. Fjárfestingarstarfsemi Alfa-banka veitir miðlunarþjónustu fyrir einstaklinga og lögaðila til að veita tækifæri til viðskipta á hinum ýmsu verðbréfamörkuðum, innlánsþjónustu vegna vörslu verðbréfa, fjárvörsluþjónustu fyrir einstaklinga með einka- og stórfé, þjónustu við útgáfu verðbréfa fyrir önnur fyrirtæki. . Fjárfestingarviðskipti Alfa-banka innihalda meira en 3 þúsund verðtilboð á sekúndu, sem er hlaðið niður af ýmsum viðskiptakerfum. Á virkum degi fara yfir 300 þúsund viðskipti á mörkuðum fyrir hönd bankans eða viðskiptavina hans. Allt að 5 þúsund pöntunarframkvæmdir á sekúndu eiga sér stað á ytri og innri kerfum. Á sama tíma vilja allir viðskiptavinir, bæði innri og ytri, sjá stöðu sína í rauntíma.

Forsaga

Einhvers staðar frá upphafi 2000 þróaðist svið fjárfestingarviðskipta okkar sjálfstætt: gjaldeyrisviðskipti, miðlunarþjónusta, gjaldeyrisviðskipti, viðskipti með verðbréf án endurgjalds og ýmsar afleiður. Fyrir vikið höfum við fallið í gildru virkra brunna. Hvað það er? Hver viðskiptagrein hefur sín kerfi sem afrita aðgerðir hvers annars. Hvert kerfi hefur sitt eigið gagnalíkan, þó að þau starfi með sömu hugtökum: færslur, gerningar, mótaðilar, tilvitnanir og svo framvegis. Og þegar hvert kerfi þróaðist sjálfstætt, kom fram fjölbreyttur dýragarður af tækni.

Þar að auki er kóðagrunnur kerfanna nú þegar nokkuð úreltur, því sumar vörur eru upprunnar um miðjan tíunda áratuginn. Og á sumum sviðum hægði þetta á þróunarferlinu og það voru frammistöðuvandamál.

Kröfur um nýja lausn

Fyrirtæki hafa áttað sig á því að tæknileg umbreyting er mikilvæg fyrir frekari þróun. Við fengum verkefni:

1. Safnaðu öllum viðskiptagögnum í einni, hraðvirkri geymslu og í einu gagnalíkani.
2. Við megum ekki týna eða breyta þessum upplýsingum.
3. Nauðsynlegt er að útgáfa gögnin, því hvenær sem er getur eftirlitsaðilinn beðið um tölfræði fyrir fyrri ár.
4. Við megum ekki bara koma með nýja, smart DBMS, heldur skapa vettvang til að leysa viðskiptavandamál.

Að auki setja arkitektar okkar eigin skilyrði:

1. Nýja lausnin verður að vera í fyrirtækjaflokki, það er að segja að hún verður þegar að vera prófuð í sumum stórum fyrirtækjum.
2. Vinnuhamur lausnarinnar ætti að vera mikilvægur fyrir verkefnið. Þetta þýðir að við verðum að vera til staðar í nokkrum gagnaverum samtímis og lifa rólega af þegar eitt gagnaver er rofið.
3. Kerfið verður að vera lárétt skalanlegt. Staðreyndin er sú að öll núverandi kerfi okkar eru aðeins lóðrétt skalanleg og við erum nú þegar að ná hámarkinu vegna lítillar vaxtar vélbúnaðarafls. Þess vegna er sú stund runnin upp þegar við þurfum að hafa lárétt skalanlegt kerfi til að lifa af.
4. Okkur var meðal annars sagt að lausnin yrði að vera ódýr.

Við fórum stöðluðu leiðina: við mótuðum kröfurnar og höfðum samband við innkaupadeildina. Þaðan fengum við lista yfir fyrirtæki sem almennt eru tilbúin að gera þetta fyrir okkur. Við sögðum öllum frá vandamálinu og fengum úttekt á lausnum frá sex þeirra.

Í bankanum tökum við ekki orð neins fyrir það, okkur finnst gaman að prófa allt sjálf. Þess vegna var skylduskilyrði í útboðssamkeppni okkar að standast álagspróf. Við mótuðum álagsprófunarverkefni og þrjú af hverjum sex fyrirtækjum hafa þegar samþykkt að innleiða frumgerð lausn sem byggir á minnistækni á eigin kostnað til að prófa hana.

Ég mun ekki segja þér hvernig við prófuðum allt og hversu langan tíma það tók, ég ætla bara að draga saman: besti árangur í álagsprófum var sýndur með frumgerð lausn byggða á Tarantool frá Mail.ru Group þróunarteymi. Við skrifuðum undir samning og hófum þróun. Það voru fjórir menn frá Mail.ru Group og frá Alfa-Bank voru þrír þróunaraðilar, þrír kerfissérfræðingar, lausnaarkitekt, vörueigandi og Scrum meistari.

Næst mun ég segja þér frá því hvernig kerfið okkar óx, hvernig það þróaðist, hvað við gerðum og hvers vegna nákvæmlega þetta.

Þróun

Fyrsta spurningin sem við spurðum okkur var hvernig við fáum gögn úr núverandi kerfum okkar. Við ákváðum að HTTP hentaði okkur vel, því öll núverandi kerfi hafa samskipti sín á milli með því að senda XML eða JSON yfir HTTP.

Við notum HTTP netþjóninn sem er innbyggður í Tarantool vegna þess að við þurfum ekki að slíta SSL lotum og árangur hans er nóg fyrir okkur.

Eins og ég sagði þegar, búa öll kerfi okkar í mismunandi gagnalíkönum og við inntakið þurfum við að koma hlutnum að líkaninu sem við lýsum sjálf. Það þurfti tungumál sem gerði kleift að umbreyta gögnum. Við völdum nauðsynlega Lua. Við keyrum allan gagnaumreikningskóða í sandkassa - þetta er öruggur staður sem keyrandi kóðinn fer ekki út fyrir. Til að gera þetta hleðum við einfaldlega nauðsynlegum kóða, búum til umhverfi með aðgerðum sem geta ekki lokað eða sleppt neinu.

Eftir umbreytingu verður að athuga hvort gögnin séu í samræmi við líkanið sem við erum að búa til. Við ræddum lengi hvert líkanið ætti að vera og hvaða tungumál ætti að nota til að lýsa því. Við völdum Apache Avro vegna þess að tungumálið er einfalt og það hefur stuðning frá Tarantool. Hægt er að taka nýjar útgáfur af líkaninu og sérsniðnum kóða í notkun nokkrum sinnum á dag, jafnvel undir álagi eða án, hvenær sem er sólarhringsins og laga sig mjög fljótt að breytingum.

Eftir staðfestingu verður að vista gögnin. Við gerum þetta með því að nota vshard (við erum með geo-dreifðar eftirmyndir af shards).

Þar að auki er sérstaðan slík að flestum kerfum sem senda okkur gögn er sama hvort við höfum fengið þau eða ekki. Þess vegna innleiddum við viðgerðarröð frá upphafi. Hvað það er? Ef hlutur af einhverjum ástæðum gengur ekki undir gagnaumbreytingu eða sannprófun, staðfestum við samt móttöku, en vistum hlutinn um leið í viðgerðarröðinni. Það er samkvæmt og staðsett í aðal vöruhúsi fyrirtækjagagna. Við skrifuðum strax stjórnandaviðmót fyrir það, ýmsar mælingar og viðvaranir. Fyrir vikið týnum við ekki gögnum. Jafnvel þótt eitthvað hafi breyst í upprunanum, ef gagnalíkanið hefur breyst, munum við strax uppgötva það og getum aðlagað okkur.

Nú þarftu að læra hvernig á að sækja vistuð gögn. Við greindum kerfin okkar vandlega og sáum að klassíski stafla Java og Oracle inniheldur endilega einhvers konar ORM sem breytir gögnum úr vensla í hlut. Svo hvers vegna ekki að gefa hluti strax í kerfi í formi línurits? Þannig að við samþykktum GraphQL með ánægju, sem uppfyllti allar þarfir okkar. Það gerir þér kleift að taka á móti gögnum í formi línurita og draga aðeins út það sem þú þarft núna. Þú getur jafnvel útgáfa API með töluverðum sveigjanleika.

Næstum strax komumst við að því að gögnin sem við vorum að draga dugðu ekki. Við bjuggum til aðgerðir sem hægt er að tengja við hluti í líkaninu - í rauninni reiknuð reiti. Það er að segja að við festum ákveðna aðgerð við reitinn, sem til dæmis reiknar út meðaltal tilboðsverðs. Og ytri neytandinn sem óskar eftir gögnunum veit ekki einu sinni að þetta er útreiknað svið.

Innleitt auðkenningarkerfi.

Þá tókum við eftir því að nokkur hlutverk kristallast í ákvörðun okkar. Hlutverk er eins konar samansafn aðgerða. Venjulega hafa hlutverk mismunandi notkunarsnið búnaðar:

• T-Connect: sér um komandi tengingar, CPU takmarkaður, lítil minnisnotkun, ríkisfangslaus.
• IB-Core: umbreytir gögnunum sem það fær í gegnum Tarantool samskiptareglur, það er, það starfar með töflum. Það geymir heldur ekki ástand og er skalanlegt.
• Geymsla: geymir aðeins gögn, notar enga rökfræði. Þetta hlutverk útfærir einföldustu viðmótin. Stærðanleg þökk sé vshard.

Það er, með því að nota hlutverk, aftengdum við mismunandi hluta klasans frá hvor öðrum, sem hægt er að skala óháð hver öðrum.

Þannig að við höfum búið til ósamstillta gagnaflæðisupptöku og viðgerðarröð með stjórnendaviðmóti. Upptakan er ósamstillt frá viðskiptalegu sjónarmiði: ef við erum tryggð að skrifa gögn til okkar, sama hvar, þá munum við staðfesta það. Ef það er ekki staðfest þá fór eitthvað úrskeiðis og þarf að senda gögnin. Þetta er ósamstillta upptakan.

Prófun

Strax í upphafi verkefnisins ákváðum við að reyna að innleiða reynsludrifna þróun. Við skrifum einingapróf í Lua með því að nota tarantool/tappa ramma og samþættingarpróf í Python með því að nota pytest ramma. Á sama tíma tökum við bæði þróunaraðila og greinendur með í að skrifa samþættingarpróf.

Hvernig notum við reynsludrifna þróun?

Ef við viljum nýjan eiginleika reynum við að skrifa próf fyrir hann fyrst. Þegar við uppgötvum villu, pössum við upp á að skrifa próf fyrst og laga það fyrst. Í fyrstu er erfitt að vinna svona, það er misskilningur hjá starfsmönnum, jafnvel skemmdarverk: „Við skulum laga það fljótt núna, gera eitthvað nýtt og hylja það síðan með prófunum.“ Aðeins þetta „síðar“ kemur nánast aldrei.

Þess vegna þarftu að þvinga þig til að skrifa próf fyrst og biðja aðra um að gera það. Trúðu mér, reynsludrifin þróun hefur ávinning í för með sér, jafnvel til skamms tíma. Þú munt finna að líf þitt hefur orðið auðveldara. Okkur finnst að 99% af kóðanum sé nú þakið prófum. Þetta virðist vera mikið, en við eigum ekki í neinum vandræðum: próf keyra á hverri skuldbindingu.

Hins vegar, það sem við elskum mest er álagspróf; við teljum það mikilvægast og framkvæmum það reglulega.

Ég skal segja þér smá sögu um hvernig við framkvæmdum fyrsta stig álagsprófunar á einni af fyrstu útgáfunum. Við settum kerfið upp á fartölvu þróunaraðilans, kveiktum á hleðslunni og fengum 4 þúsund færslur á sekúndu. Góður árangur fyrir fartölvu. Við settum það upp á sýndarhleðslubekk með fjórum netþjónum, veikari en í framleiðslu. Dreift í lágmarki. Við keyrum það, og við fáum verri niðurstöðu en á fartölvu í einum þræði. Áfallaefni.

Við vorum mjög sorgmædd. Við skoðum hleðslu netþjónsins en það kemur í ljós að þeir eru aðgerðalausir.

Við hringjum í hönnuðina og þeir útskýra fyrir okkur, fólki sem kemur úr heimi Java, að Tarantool sé einþráður. Það er aðeins hægt að nota það í raun af einum örgjörvakjarna undir álagi. Síðan settum við upp hámarks mögulega fjölda Tarantool tilvika á hverjum netþjóni, kveiktum á álaginu og fengum þegar 14,5 þúsund færslur á sekúndu.

Leyfðu mér að útskýra aftur. Vegna skiptingar í hlutverk sem nota auðlindir á annan hátt, hlaða hlutverk okkar sem bera ábyrgð á vinnslu tenginga og gagnaumbreytingu aðeins örgjörvanum og í nákvæmlega hlutfalli við álagið.

Í þessu tilviki var minni aðeins notað til að vinna úr komandi tengingum og tímabundnum hlutum.

Þvert á móti, á geymsluþjónum jókst álag á örgjörva, en mun hægar en á netþjónum sem vinna úr tengingum.

Og minnisnotkun jókst í réttu hlutfalli við magn gagna sem hlaðið var inn.

Þjónusta

Til að þróa nýju vöruna okkar sérstaklega sem umsóknarvettvang, bjuggum við til íhlut til að dreifa þjónustu og bókasöfnum á hana.

Þjónusta er ekki bara lítill kóða sem starfar á sumum sviðum. Þau geta verið nokkuð stór og flókin mannvirki sem eru hluti af klasa, athuga viðmiðunargögn, keyra viðskiptarökfræði og skila svörum. Við flytjum líka út þjónustuskema til GraphQL og neytandinn fær alhliða aðgangsstað að gögnunum, með sjálfskoðun yfir allt líkanið. Það er mjög þægilegt.

Þar sem þjónustur innihalda miklu fleiri aðgerðir ákváðum við að það ættu að vera bókasöfn þar sem við munum flytja oft notaðan kóða. Við bættum þeim við öruggt umhverfi, eftir að hafa áður athugað að það brýtur ekki neitt fyrir okkur. Og nú getum við úthlutað viðbótarumhverfi til aðgerða í formi bókasöfna.

Við vildum hafa vettvang ekki aðeins fyrir geymslu heldur einnig fyrir tölvur. Og þar sem við áttum nú þegar fullt af eftirlíkingum og brotum, innleiddum við eins konar dreifða tölvuvinnslu og kölluðum það kortaminnkun, vegna þess að það reyndist svipað og upprunalega kortafækkunin.

Gömul kerfi

Ekki geta öll eldri kerfin okkar hringt í okkur í gegnum HTTP og notað GraphQL, þó þau styðji samskiptaregluna. Þess vegna bjuggum við til kerfi sem gerir kleift að afrita gögn inn í þessi kerfi.

Ef eitthvað breytist hjá okkur þá koma einstakir kveikjar af stað í Geymsluhlutverkinu og skilaboðin með breytingunum endar í vinnsluröðinni. Það er sent til ytra kerfis með því að nota sérstakt afritunarhlutverk. Þetta hlutverk geymir ekki ástand.

Nýjar endurbætur

Eins og þú manst, frá viðskiptalegu sjónarmiði, gerðum við ósamstillta upptöku. En þá áttuðu þeir sig á því að það væri ekki nóg, því það er kerfaflokkur sem þarf strax að fá svar um stöðu starfseminnar. Svo við útvíkkuðum GraphQL okkar og bættum við stökkbreytingum. Þeir passa lífrænt inn í núverandi hugmyndafræði að vinna með gögn. Fyrir okkur er þetta einn punktur bæði í lestri og ritun fyrir annan flokk kerfa.

Við áttum okkur líka á því að þjónusta ein og sér myndi ekki duga okkur, því það eru ansi þungar skýrslur sem þarf að byggja einu sinni á dag, viku, í mánuði. Þetta getur tekið langan tíma og skýrslur geta jafnvel lokað viðburðarlykkju Tarantool. Þess vegna bjuggum við til aðskilin hlutverk: tímaáætlun og hlaupari. Hlauparar geyma ekki ástand. Þeir vinna þung verkefni sem við getum ekki reiknað út á flugu. Og tímaáætlunarhlutverkið fylgist með ræsingaráætlun þessara verkefna, sem lýst er í uppsetningunni. Verkefnin sjálf eru geymd á sama stað og viðskiptagögn. Þegar rétti tíminn kemur tekur tímaáætlunarmaðurinn verkefnið, gefur einhverjum hlaupara, sem telur það og vistar niðurstöðuna.

Ekki þarf að keyra öll verkefni samkvæmt áætlun. Sumar skýrslur þarf að lesa á eftirspurn. Um leið og þessi krafa kemur er verkefni búið til í sandkassanum og sent til hlaupara til framkvæmdar. Eftir nokkurn tíma fær notandinn ósamstillt svar um að allt hafi verið reiknað út og skýrslan sé tilbúin.

Upphaflega héldum við okkur við hugmyndafræðina um að geyma öll gögn, útgáfu þeirra en ekki eyða þeim. En í lífinu þarftu samt af og til að eyða einhverju, aðallega einhverjum hráum eða miðlungsupplýsingum. Byggt á útrunnið, bjuggum við til kerfi til að hreinsa geymsluna úr úreltum gögnum.

Við skiljum líka að fyrr eða síðar kemur upp sú staða að ekki verður nóg pláss til að geyma gögn í minni, en engu að síður verður að geyma gögnin. Í þessum tilgangi munum við fljótlega búa til diskageymslu.

Ályktun

Við byrjuðum á því að hlaða gögnum inn í eitt líkan og eyddum þremur mánuðum í að þróa þau. Við vorum með sex gagnaveitukerfi. Allur umbreytingarkóðinn í eitt líkan er um 30 þúsund línur í Lua. Og mest af verkinu er enn framundan. Stundum skortir hvatningu frá nágrannaliðum og það eru margar aðstæður sem flækja starfið. Ef þú stendur frammi fyrir svipuðu verkefni, margfaldaðu þá tímann sem þér finnst eðlilegur fyrir framkvæmd þess með þremur, eða jafnvel fjórum.

Mundu líka að núverandi vandamál í viðskiptaferlum er ekki hægt að leysa með því að nota nýtt DBMS, jafnvel mjög afkastamikið. Hvað ég meina? Í upphafi verkefnis okkar sköpuðum við þá tilfinningu meðal viðskiptavina að nú munum við koma með nýjan hraðvirkan gagnagrunn og við munum lifa! Ferlarnir munu ganga hraðar, allt verður í lagi. Í raun leysir tæknin ekki vandamálin sem viðskiptaferlar hafa, því viðskiptaferlar eru fólk. Og þú þarft að vinna með fólki, ekki tækni.

Prófdrifin þróun getur verið sársaukafull og tímafrekt á fyrstu stigum. En jákvæð áhrif þess verða áberandi jafnvel til skamms tíma, þegar þú þarft ekki að gera neitt til að framkvæma aðhvarfspróf.

Það er afar mikilvægt að framkvæma álagspróf á öllum stigum þróunar. Því fyrr sem þú tekur eftir einhverjum galla í arkitektúrnum, því auðveldara verður að laga það, sem mun spara þér mikinn tíma í framtíðinni.

Það er ekkert að Lua. Hver sem er getur lært að skrifa í það: Java verktaki, JavaScript verktaki, Python verktaki, framhlið eða bakendi. Jafnvel sérfræðingar okkar skrifa um það.

Þegar við tölum um þá staðreynd að við höfum ekki SQL, þá hræðir það fólk. „Hvernig færðu gögn án SQL? Er það mögulegt? Svo sannarlega. Í OLTP bekkjakerfi er SQL ekki þörf. Það er valkostur í formi einhvers konar tungumáls sem skilar þér strax aftur í skjalamiðaða sýn. Til dæmis, GraphQL. Og það er valkostur í formi dreifðrar tölvunar.

Ef þú skilur að þú þarft að skala, hannaðu þá lausnina þína á Tarantool á þann hátt að hún geti keyrt samhliða á tugum Tarantool tilvika. Ef þú gerir þetta ekki verður það erfitt og sársaukafullt seinna, þar sem Tarantool getur aðeins notað einn örgjörvakjarna í raun.

Heimild: www.habr.com