Akoma nga filmi "Universi ynë sekret: Jeta e fshehur e qelizës"

Biznesi i investimeve është një nga fushat më komplekse në botën bankare, sepse nuk ka vetëm kredi, hua dhe depozita, por edhe letra me vlerë, monedha, mallra, derivate dhe lloj-lloj kompleksiteti në formën e produkteve të strukturuara.

Kohët e fundit, ne kemi parë një rritje të edukimit financiar të popullsisë. Gjithnjë e më shumë njerëz po përfshihen në tregtimin në tregjet e letrave me vlerë. Llogaritë e investimeve individuale u shfaqën jo shumë kohë më parë. Ato ju lejojnë të tregtoni tregjet e letrave me vlerë dhe ose të merrni zbritje tatimore ose të shmangni pagimin e taksave. Dhe të gjithë klientët që vijnë tek ne dëshirojnë të menaxhojnë portofolin e tyre dhe të shohin raportimin në kohë reale. Për më tepër, më shpesh ky portofol është me shumë produkte, domethënë njerëzit janë klientë të linjave të ndryshme të biznesit.

Për më tepër, nevojat e rregullatorëve, si rusë ashtu edhe të huaj, po rriten.

Për të përmbushur nevojat aktuale dhe për të hedhur themelet për përmirësimet e ardhshme, ne kemi zhvilluar një bazë biznesi investimi bazuar në Tarantool.

Disa statistika. Biznesi i investimeve të Alfa-Bank ofron shërbime brokerimi për persona fizikë dhe juridikë për të ofruar mundësinë e tregtimit në tregje të ndryshme letrash me vlerë, shërbime depozitimi për ruajtjen e letrave me vlerë, shërbime të menaxhimit të besimit për individë me kapital privat dhe të madh, shërbime për emetimin e letrave me vlerë për kompani të tjera. . Biznesi i investimeve të Alfa-Bank përfshin më shumë se 3 mijë kuota në sekondë, të cilat shkarkohen nga platforma të ndryshme tregtare. Gjatë ditës së punës, në treg janë kryer mbi 300 mijë transaksione për llogari të bankës apo klientëve të saj. Deri në 5 mijë ekzekutime në sekondë ndodhin në platformat e jashtme dhe të brendshme. Në të njëjtën kohë, të gjithë klientët, të brendshëm dhe të jashtëm, duan të shohin pozicionet e tyre në kohë reale.

parahistorinë

Diku nga fillimi i viteve 2000, fushat tona të biznesit të investimeve u zhvilluan në mënyrë të pavarur: tregtimi i këmbimit, shërbimet e brokerimit, tregtia e monedhave, tregtia jashtë bursës së letrave me vlerë dhe derivateve të ndryshme. Si pasojë kemi rënë në grackën e puseve funksionale. Cfare eshte? Çdo linjë biznesi ka sistemet e veta që kopjojnë funksionet e njëri-tjetrit. Secili sistem ka modelin e tij të të dhënave, megjithëse ato funksionojnë me të njëjtat koncepte: transaksione, instrumente, palë, kuota, etj. Dhe ndërsa secili sistem evoluoi në mënyrë të pavarur, u shfaq një kopsht zoologjik i larmishëm teknologjish.

Për më tepër, baza e kodit të sistemeve është tashmë mjaft e vjetëruar, sepse disa produkte kanë origjinën në mesin e viteve 1990. Dhe në disa zona kjo ngadalësoi procesin e zhvillimit dhe pati probleme të performancës.

Kërkesat për një zgjidhje të re

Bizneset e kanë kuptuar se transformimi teknologjik është jetik për zhvillimin e mëtejshëm. Na u dhanë detyra:

1. Mblidhni të gjitha të dhënat e biznesit në një ruajtje të vetme, të shpejtë dhe në një model të vetëm të dhënash.
2. Ne nuk duhet të humbasim ose ndryshojmë këtë informacion.
3. Është e nevojshme të modifikohen të dhënat, sepse në çdo moment rregullatori mund të kërkojë statistika për vitet e mëparshme.
4. Ne nuk duhet vetëm të sjellim disa DBMS të reja, në modë, por të krijojmë një platformë për zgjidhjen e problemeve të biznesit.

Për më tepër, arkitektët tanë vendosin kushtet e tyre:

1. Zgjidhja e re duhet të jetë e klasit të ndërmarrjes, domethënë tashmë duhet të testohet në disa kompani të mëdha.
2. Mënyra e funksionimit të zgjidhjes duhet të jetë misioni kritik. Kjo do të thotë që ne duhet të jemi të pranishëm në disa qendra të dhënash njëkohësisht dhe të mbijetojmë me qetësi ndërprerjen e një qendre të dhënash.
3. Sistemi duhet të jetë i shkallëzuar horizontalisht. Fakti është se të gjitha sistemet tona aktuale janë të shkallëzueshme vetëm vertikalisht, dhe ne tashmë jemi duke goditur tavanin për shkak të rritjes së ulët të fuqisë harduerike. Prandaj, ka ardhur momenti kur duhet të kemi një sistem horizontalisht të shkallëzuar për të mbijetuar.
4. Ndër të tjera na thanë se zgjidhja duhej të ishte e lirë.

Ne ndoqëm rrugën standarde: formuluam kërkesat dhe kontaktuam departamentin e blerjeve. Nga atje kemi marrë një listë të kompanive që, në përgjithësi, janë të gatshme ta bëjnë këtë për ne. Ne i treguam të gjithëve për problemin dhe morëm një vlerësim të zgjidhjeve nga gjashtë prej tyre.

Në bankë, ne nuk e pranojmë fjalën e askujt; na pëlqen të testojmë gjithçka vetë. Prandaj, një kusht i detyrueshëm i konkursit tonë të tenderit ishte kalimi i testeve të ngarkesës. Ne formuluam detyrat e testimit të ngarkesës dhe tre nga gjashtë kompani tashmë kanë rënë dakord të zbatojnë një zgjidhje prototip të bazuar në teknologjitë në memorie me shpenzimet e tyre për ta testuar atë.

Nuk do t'ju tregoj se si testuam gjithçka dhe sa kohë u desh, thjesht do të përmbledh: performanca më e mirë në testet e ngarkesës u tregua nga një zgjidhje prototip bazuar në Tarantool nga ekipi i zhvillimit të Mail.ru Group. Ne nënshkruam një marrëveshje dhe filluam zhvillimin. Kishte katër persona nga Mail.ru Group, dhe nga Alfa-Bank kishte tre zhvillues, tre analistë të sistemit, një arkitekt zgjidhjesh, një pronar produkti dhe një master Scrum.

Më pas do t'ju tregoj se si u rrit sistemi ynë, si evoluoi, çfarë bëmë dhe pse pikërisht kjo.

Разработка

Pyetja e parë që i bëmë vetes ishte se si të merrnim të dhëna nga sistemet tona aktuale. Ne vendosëm që HTTP ishte mjaft i përshtatshëm për ne, sepse të gjitha sistemet aktuale komunikojnë me njëri-tjetrin duke dërguar XML ose JSON mbi HTTP.

Ne përdorim serverin HTTP të integruar në Tarantool sepse nuk kemi nevojë të ndërpresim seancat SSL dhe performanca e tij na mjafton.

Siç thashë tashmë, të gjitha sistemet tona jetojnë në modele të ndryshme të dhënash, dhe në hyrje ne duhet ta sjellim objektin në modelin që përshkruajmë veten. Duhej një gjuhë që lejonte të dhënat të transformoheshin. Ne zgjodhëm imperativin Lua. Ne ekzekutojmë të gjithë kodin e konvertimit të të dhënave në një sandbox - ky është një vend i sigurt përtej të cilit kodi i ekzekutimit nuk shkon. Për ta bërë këtë, ne thjesht ngarkojmë kodin e kërkuar, duke krijuar një mjedis me funksione që nuk mund të bllokojnë ose lëshojnë asgjë.

Pas konvertimit, të dhënat duhet të kontrollohen për përputhshmëri me modelin që po krijojmë. Ne diskutuam për një kohë të gjatë se cili duhet të jetë modeli dhe çfarë gjuhe të përdorim për ta përshkruar atë. Ne zgjodhëm Apache Avro sepse gjuha është e thjeshtë dhe ka mbështetje nga Tarantool. Versionet e reja të modelit dhe kodit personal mund të vihen në funksion disa herë në ditë, edhe nën ngarkesë ose pa, në çdo kohë të ditës, dhe përshtaten shumë shpejt me ndryshimet.

Pas verifikimit, të dhënat duhet të ruhen. Ne e bëjmë këtë duke përdorur vshard (kemi kopje gjeo-shpërndara të copëzave).

Për më tepër, specifika është e tillë që shumica e sistemeve që na dërgojnë të dhëna nuk u intereson nëse i kemi marrë apo jo. Kjo është arsyeja pse ne kemi zbatuar një radhë riparimi që në fillim. Cfare eshte? Nëse për ndonjë arsye një objekt nuk i nënshtrohet transformimit ose verifikimit të të dhënave, ne përsëri konfirmojmë marrjen, por në të njëjtën kohë e ruajmë objektin në radhën e riparimit. Është konsistente dhe ndodhet në depon kryesore të të dhënave të biznesit. Ne shkruam menjëherë një ndërfaqe administratori për të, metrika të ndryshme dhe alarme. Si rezultat, ne nuk humbasim të dhëna. Edhe nëse diçka ka ndryshuar në burim, nëse modeli i të dhënave ka ndryshuar, ne do ta zbulojmë menjëherë dhe mund të përshtatemi.

Tani ju duhet të mësoni se si të rikuperoni të dhënat e ruajtura. Ne analizuam me kujdes sistemet tona dhe pamë se grupi klasik i Java dhe Oracle përmban domosdoshmërisht një lloj ORM që konverton të dhënat nga relacionale në objekt. Pra, pse të mos u jepni menjëherë objekte sistemeve në formën e një grafiku? Pra, ne miratuam me kënaqësi GraphQL, i cili plotësoi të gjitha nevojat tona. Kjo ju lejon të merrni të dhëna në formën e grafikëve dhe të nxirrni vetëm atë që ju nevojitet tani. Ju madje mund të versiononi API-në me mjaft fleksibilitet.

Pothuajse menjëherë kuptuam se të dhënat që po nxirrnim nuk ishin të mjaftueshme. Ne krijuam funksione që mund të lidhen me objektet në model - në thelb, fusha të llogaritura. Kjo do të thotë, ne bashkojmë një funksion të caktuar në fushë, e cila, për shembull, llogarit çmimin mesatar të kuotës. Dhe konsumatori i jashtëm që kërkon të dhënat nuk e di as që kjo është një fushë e llogaritur.

Zbatoi një sistem vërtetimi.

Më pas vumë re se në vendimin tonë u kristalizuan disa role. Një rol është një lloj grumbulluesi i funksioneve. Në mënyrë tipike, rolet kanë profile të ndryshme të përdorimit të pajisjeve:

• T-Connect: trajton lidhjet hyrëse, CPU i kufizuar, konsum i ulët memorie, pa shtetësi.
• IB-Core: transformon të dhënat që merr nëpërmjet protokollit Tarantool, pra funksionon me tabela. Ai gjithashtu nuk ruan gjendjen dhe është i shkallëzuar.
• Ruajtja: ruan vetëm të dhëna, nuk përdor asnjë logjikë. Ky rol zbaton ndërfaqet më të thjeshta. I shkallëzuar falë vshard.

Kjo do të thotë, duke përdorur role, ne shkëputëm pjesë të ndryshme të grupit nga njëra-tjetra, të cilat mund të shkallëzohen në mënyrë të pavarur nga njëra-tjetra.

Pra, ne kemi krijuar një regjistrim asinkron të rrjedhës së të dhënave transaksionale dhe një radhë riparimi me një ndërfaqe administratori. Regjistrimi është asinkron nga pikëpamja e biznesit: nëse jemi të garantuar t'i shkruajmë të dhënat vetes, pavarësisht se ku, atëherë do ta konfirmojmë. Nëse nuk konfirmohet, atëherë diçka shkoi keq dhe të dhënat duhet të dërgohen. Ky është regjistrimi asinkron.

Testimi

Që në fillim të projektit, ne vendosëm që do të përpiqeshim të zbatonim zhvillimin e drejtuar nga testi. Ne shkruajmë teste njësi në Lua duke përdorur kornizën tarantool/tap dhe testet e integrimit në Python duke përdorur kornizën pytest. Në të njëjtën kohë, ne përfshijmë si zhvilluesit ashtu edhe analistët në shkrimin e testeve të integrimit.

Si e përdorim zhvillimin e drejtuar nga testi?

Nëse duam ndonjë veçori të re, ne fillimisht përpiqemi të shkruajmë një test për të. Kur zbulojmë një gabim, ne sigurohemi që fillimisht të shkruajmë një test dhe vetëm më pas ta rregullojmë atë. Në fillim është e vështirë të punosh kështu, ka keqkuptim nga ana e punonjësve, madje edhe sabotim: "Ta rregullojmë shpejt tani, të bëjmë diçka të re dhe më pas ta mbulojmë me teste". Vetëm kjo "më vonë" pothuajse nuk vjen kurrë.

Prandaj, duhet ta detyroni veten të shkruani teste së pari dhe t'u kërkoni të tjerëve ta bëjnë atë. Më besoni, zhvillimi i drejtuar nga testi sjell përfitime edhe në afat të shkurtër. Do të ndjeni se jeta juaj është bërë më e lehtë. Ne mendojmë se 99% e kodit tani mbulohet nga testet. Kjo duket si shumë, por ne nuk kemi asnjë problem: testet kryhen në çdo kryerje.

Megjithatë, ajo që na pëlqen më shumë është testimi i ngarkesës; ne e konsiderojmë atë më të rëndësishmin dhe e kryejmë rregullisht.

Unë do t'ju tregoj një histori të vogël se si kemi kryer fazën e parë të testimit të ngarkesës së një prej versioneve të para. Ne instaluam sistemin në laptopin e zhvilluesit, ndezëm ngarkesën dhe morëm 4 mijë transaksione në sekondë. Rezultat i mirë për një laptop. Ne e instaluam atë në një bankë ngarkese virtuale prej katër serverësh, më të dobët se në prodhim. Vendosur në minimum. Ne e lëshojmë atë dhe marrim një rezultat më të keq sesa në një laptop në një fije. Përmbajtje shokuese.

Ishim shumë të trishtuar. Ne shikojmë ngarkesën e serverit, por rezulton se ata janë të papunë.

Ne thërrasim zhvilluesit dhe ata na shpjegojnë, njerëz që vijnë nga bota e Java-s, se Tarantool është me një fije të vetme. Mund të përdoret në mënyrë efektive vetëm nga një bërthamë procesori nën ngarkesë. Pastaj vendosëm numrin maksimal të mundshëm të rasteve të Tarantool në secilin server, aktivizuam ngarkesën dhe morëm tashmë 14,5 mijë transaksione në sekondë.

Më lejoni të shpjegoj përsëri. Për shkak të ndarjes në role që përdorin burimet në mënyra të ndryshme, rolet tona përgjegjëse për përpunimin e lidhjeve dhe transformimin e të dhënave ngarkonin vetëm procesorin, dhe rreptësisht në proporcion me ngarkesën.

Në këtë rast, memoria përdorej vetëm për përpunimin e lidhjeve hyrëse dhe objekteve të përkohshme.

Përkundrazi, në serverët e ruajtjes, ngarkesa e procesorit u rrit, por shumë më ngadalë sesa në serverët që përpunojnë lidhjet.

Dhe konsumi i kujtesës u rrit në përpjesëtim të drejtë me sasinë e të dhënave të ngarkuara.

Sherbime

Për të zhvilluar produktin tonë të ri në mënyrë specifike si një platformë aplikacioni, ne krijuam një komponent për vendosjen e shërbimeve dhe bibliotekave në të.

Shërbimet nuk janë vetëm pjesë të vogla kodi që funksionojnë në disa fusha. Ato mund të jenë struktura mjaft të mëdha dhe komplekse që janë pjesë e një grupi, kontrollojnë të dhënat e referencës, drejtojnë logjikën e biznesit dhe kthejnë përgjigjet. Ne gjithashtu e eksportojmë skemën e shërbimit në GraphQL dhe konsumatori merr një pikë aksesi universal në të dhëna, me introspeksion në të gjithë modelin. Është shumë komode.

Meqenëse shërbimet përmbajnë shumë më tepër funksione, ne vendosëm që duhet të ketë biblioteka në të cilat do të zhvendosim kodin e përdorur shpesh. I kemi shtuar në ambientin e sigurt, pasi kemi kontrolluar më parë që të mos na prishë asgjë. Dhe tani ne mund të caktojmë mjedise shtesë për funksionet në formën e bibliotekave.

Ne donim të kishim një platformë jo vetëm për ruajtje, por edhe për informatikë. Dhe meqenëse tashmë kishim një mori kopjesh dhe copëzash, ne zbatuam një lloj llogaritjeje të shpërndarë dhe e quajtëm reduktimin e hartës, sepse doli i ngjashëm me reduktimin origjinal të hartës.

Sistemet e vjetra

Jo të gjitha sistemet tona të vjetra mund të na telefonojnë përmes HTTP dhe të përdorin GraphQL, megjithëse ata mbështesin protokollin. Prandaj, ne krijuam një mekanizëm që lejon të dhënat të riprodhohen në këto sisteme.

Nëse diçka ndryshon për ne, aktivizuesit unik aktivizohen në rolin "Storage" dhe mesazhi me ndryshimet përfundon në radhën e përpunimit. Ai dërgohet në një sistem të jashtëm duke përdorur një rol të veçantë replikator. Ky rol nuk ruan gjendjen.

Përmirësime të reja

Siç e mbani mend, nga pikëpamja e biznesit, ne bëmë regjistrim asinkron. Por më pas e kuptuan se nuk do të mjaftonte, sepse ekziston një klasë sistemesh që duhet të marrin menjëherë një përgjigje për statusin e operacionit. Kështu ne zgjeruam GraphQL-në tonë dhe shtuam mutacione. Ato përshtaten organikisht në paradigmën ekzistuese të punës me të dhëna. Për ne, kjo është një pikë e vetme e leximit dhe e shkrimit për një klasë tjetër sistemesh.

E kuptuam gjithashtu se vetëm shërbimet nuk do të na mjaftonin, sepse ka raporte mjaft të rënda që duhet të ndërtohen një herë në ditë, në javë, në muaj. Kjo mund të zgjasë shumë dhe raportet madje mund të bllokojnë ciklin e ngjarjeve të Tarantool. Prandaj, ne krijuam role të veçanta: planifikues dhe vrapues. Vrapuesit nuk e ruajnë gjendjen. Ata kryejnë detyra të rënda që ne nuk mund t'i llogarisim në fluturim. Dhe roli i planifikuesit monitoron orarin e nisjes së këtyre detyrave, i cili përshkruhet në konfigurim. Vetë detyrat ruhen në të njëjtin vend me të dhënat e biznesit. Kur vjen koha e duhur, programuesi merr detyrën, ia jep një vrapuesi, i cili e numëron dhe ruan rezultatin.

Jo të gjitha detyrat duhet të kryhen sipas një orari. Disa raporte duhet të lexohen sipas kërkesës. Sapo të arrijë kjo kërkesë, krijohet një detyrë në sandbox dhe dërgohet te vrapuesi për ekzekutim. Pas ca kohësh, përdoruesi merr një përgjigje asinkrone se gjithçka është llogaritur dhe raporti është gati.

Fillimisht, ne iu përmbajtëm paradigmës së ruajtjes së të gjitha të dhënave, versionimit të tyre dhe jo fshirjes së tyre. Por në jetë, herë pas here duhet të fshish diçka, kryesisht disa informacione të papërpunuara ose të ndërmjetme. Në bazë të skadimit, ne krijuam një mekanizëm për pastrimin e ruajtjes nga të dhënat e vjetruara.

Ne gjithashtu kuptojmë se herët a vonë do të vijë një situatë kur nuk do të ketë hapësirë ​​të mjaftueshme për të ruajtur të dhënat në memorie, por megjithatë të dhënat duhet të ruhen. Për këto qëllime, së shpejti do të bëjmë ruajtjen e diskut.

Përfundim

Ne filluam me detyrën e ngarkimit të të dhënave në një model të vetëm dhe kaluam tre muaj duke e zhvilluar atë. Ne kishim gjashtë sisteme të furnizimit me të dhëna. I gjithë kodi i transformimit në një model të vetëm është rreth 30 mijë rreshta në Lua. Dhe pjesa më e madhe e punës është ende përpara. Ndonjëherë mungon motivimi nga ekipet fqinje dhe ka shumë rrethana që e vështirësojnë punën. Nëse ndonjëherë përballeni me një detyrë të ngjashme, atëherë shumëzoni kohën që ju duket normale për zbatimin e saj me tre, madje edhe katër.

Mos harroni gjithashtu se problemet ekzistuese në proceset e biznesit nuk mund të zgjidhen duke përdorur një DBMS të re, madje edhe shumë produktive. Çfarë dua të them? Në fillim të projektit tonë, krijuam përshtypjen tek klientët se tani do të sjellim një bazë të re të shpejtë të dhënash dhe do të jetojmë! Proceset do të ecin më shpejt, gjithçka do të jetë mirë. Në fakt teknologjia nuk i zgjidh problemet që kanë proceset e biznesit, sepse proceset e biznesit janë njerëz. Dhe ju duhet të punoni me njerëz, jo me teknologji.

Zhvillimi i drejtuar nga testet mund të jetë i dhimbshëm dhe kërkon shumë kohë në fazat e hershme. Por efekti pozitiv i tij do të jetë i dukshëm edhe në afat të shkurtër, kur nuk keni nevojë të bëni asgjë për të kryer testimin e regresionit.

Është jashtëzakonisht e rëndësishme të kryhet testimi i ngarkesës në të gjitha fazat e zhvillimit. Sa më shpejt të vini re ndonjë defekt në arkitekturë, aq më lehtë do të jetë ta rregulloni atë, gjë që do t'ju kursejë shumë kohë në të ardhmen.

Nuk ka asgjë të keqe me Lua. Çdokush mund të mësojë të shkruajë në të: zhvillues Java, zhvillues JavaScript, zhvillues Python, front-end ose back-end. Edhe analistët tanë shkruajnë mbi të.

Kur flasim për faktin se nuk kemi SQL, kjo i tmerron njerëzit. "Si merrni të dhëna pa SQL? A është e mundur kjo? Sigurisht. Në një sistem të klasës OLTP, SQL nuk nevojitet. Ekziston një alternativë në formën e një lloj gjuhe që ju kthen menjëherë në një pamje të orientuar nga dokumenti. Për shembull, GraphQL. Dhe ekziston një alternativë në formën e llogaritjes së shpërndarë.

Nëse e kuptoni se do t'ju duhet të shkallëzoni, atëherë dizajnoni zgjidhjen tuaj në Tarantool në mënyrë të tillë që të mund të funksionojë paralelisht në dhjetëra raste të Tarantool. Nëse nuk e bëni këtë, do të jetë e vështirë dhe e dhimbshme më vonë, pasi Tarantool mund të përdorë në mënyrë efektive vetëm një bërthamë procesori.

Burimi: www.habr.com