Bado kutoka kwa filamu "Ulimwengu wetu wa Siri: Maisha Siri ya Kiini"

Biashara ya uwekezaji ni mojawapo ya maeneo magumu zaidi katika ulimwengu wa benki, kwa sababu hakuna tu mikopo, mikopo na amana, lakini pia dhamana, sarafu, bidhaa, derivatives na kila aina ya magumu kwa namna ya bidhaa zilizopangwa.

Hivi majuzi, tumeona ongezeko la ujuzi wa kifedha wa idadi ya watu. Watu zaidi na zaidi wanajihusisha na biashara katika masoko ya dhamana. Akaunti za uwekezaji za kibinafsi zilionekana si muda mrefu uliopita. Wanakuruhusu kufanya biashara ya masoko ya dhamana na kupokea makato ya kodi au kuepuka kulipa kodi. Na wateja wote wanaokuja kwetu wanataka kudhibiti kwingineko yao na kuona kuripoti kwa wakati halisi. Zaidi ya hayo, mara nyingi kwingineko hii ni bidhaa nyingi, yaani, watu ni wateja wa mistari mbalimbali ya biashara.

Kwa kuongeza, mahitaji ya wasimamizi, wote wa Kirusi na wa kigeni, yanaongezeka.

Ili kukidhi mahitaji ya sasa na kuweka msingi wa uboreshaji wa siku zijazo, tumeunda msingi wa biashara ya uwekezaji kulingana na Tarantool.

Baadhi ya takwimu. Biashara ya uwekezaji ya Alfa-Bank inatoa huduma za udalali kwa watu binafsi na vyombo vya kisheria ili kutoa fursa ya kufanya biashara kwenye masoko ya dhamana mbalimbali, huduma za kuweka amana kwa ajili ya uhifadhi wa dhamana, huduma za usimamizi wa uaminifu kwa watu wenye mitaji binafsi na kubwa, huduma za kutoa dhamana kwa makampuni mengine. . Biashara ya uwekezaji ya Alfa-Bank inajumuisha zaidi ya nukuu elfu 3 kwa sekunde, ambazo hupakuliwa kutoka kwa mifumo mbalimbali ya biashara. Wakati wa siku ya kazi, zaidi ya miamala elfu 300 huhitimishwa kwenye soko kwa niaba ya benki au wateja wake. Utekelezaji wa hadi elfu 5 kwa sekunde hufanyika kwenye majukwaa ya nje na ya ndani. Wakati huo huo, wateja wote, ndani na nje, wanataka kuona nafasi zao kwa wakati halisi.

kabla ya historia

Mahali fulani tangu mwanzo wa miaka ya 2000, maeneo yetu ya biashara ya uwekezaji yalitengenezwa kwa kujitegemea: biashara ya kubadilishana, huduma za udalali, biashara ya sarafu, biashara ya juu ya dhamana na derivatives mbalimbali. Matokeo yake, tumeingia kwenye mtego wa visima vya kazi. Ni nini? Kila mstari wa biashara una mifumo yake ambayo inarudia kazi za kila mmoja. Kila mfumo una modeli yake ya data, ingawa wanafanya kazi na dhana sawa: shughuli, vyombo, wenzao, nukuu, na kadhalika. Na kadri kila mfumo ulivyobadilika kivyake, mbuga ya wanyama mbalimbali za teknolojia ziliibuka.

Kwa kuongeza, msingi wa kanuni wa mifumo tayari umepitwa na wakati, kwa sababu baadhi ya bidhaa zilianza katikati ya miaka ya 1990. Na katika baadhi ya maeneo hii ilipunguza kasi ya mchakato wa maendeleo, na kulikuwa na matatizo ya utendaji.

Mahitaji ya suluhisho mpya

Biashara zimegundua kuwa mabadiliko ya kiteknolojia ni muhimu kwa maendeleo zaidi. Tulipewa majukumu:

1. Kusanya data yote ya biashara katika hifadhi moja, ya haraka na katika muundo mmoja wa data.
2. Hatupaswi kupoteza au kubadilisha habari hii.
3. Inahitajika kutoa toleo la data, kwa sababu wakati wowote mdhibiti anaweza kuuliza takwimu za miaka iliyopita.
4. Ni lazima si tu kuleta DBMS mpya, ya mtindo, lakini kuunda jukwaa la kutatua matatizo ya biashara.

Kwa kuongeza, wasanifu wetu huweka hali zao wenyewe:

1. Suluhisho jipya lazima liwe darasa la biashara, yaani, lazima lijaribiwe katika baadhi ya makampuni makubwa.
2. Njia ya uendeshaji ya suluhisho inapaswa kuwa muhimu sana. Hii ina maana kwamba ni lazima tuwepo katika vituo kadhaa vya data kwa wakati mmoja na kunusurika kwa utulivu kukatika kwa kituo kimoja cha data.
3. Mfumo lazima uongezeke kwa usawa. Ukweli ni kwamba mifumo yetu yote ya sasa inaweza kuongezeka tu kwa wima, na tayari tunapiga dari kutokana na ukuaji mdogo wa nguvu za vifaa. Kwa hivyo, wakati umefika ambapo tunahitaji kuwa na mfumo wa usawa ili kuishi.
4. Miongoni mwa mambo mengine, tuliambiwa kwamba ufumbuzi unapaswa kuwa nafuu.

Tulifuata njia ya kawaida: tulitengeneza mahitaji na tukawasiliana na idara ya ununuzi. Kutoka hapo tulipokea orodha ya makampuni ambayo, kwa ujumla, ni tayari kufanya hili kwa ajili yetu. Tuliambia kila mtu kuhusu tatizo hilo, na tukapokea tathmini ya masuluhisho kutoka kwa sita kati yao.

Katika benki, hatuchukui neno la mtu yeyote kwa hilo; tunapenda kujaribu kila kitu sisi wenyewe. Kwa hivyo, sharti la lazima la shindano letu la zabuni lilikuwa kupitisha majaribio ya mzigo. Tuliandaa kazi za majaribio ya upakiaji, na kampuni tatu kati ya sita tayari zimekubali kutekeleza suluhisho la mfano kulingana na teknolojia ya kumbukumbu kwa gharama zao wenyewe ili kulifanya majaribio.

Sitakuambia jinsi tulivyojaribu kila kitu na ilichukua muda gani, nitafupisha tu: utendaji bora katika vipimo vya mzigo ulionyeshwa na suluhisho la mfano kulingana na Tarantool kutoka kwa timu ya maendeleo ya Mail.ru Group. Tulisaini makubaliano na kuanza maendeleo. Kulikuwa na watu wanne kutoka Mail.ru Group, na kutoka Alfa-Bank kulikuwa na watengenezaji watatu, wachambuzi watatu wa mfumo, mbunifu wa suluhisho, mmiliki wa bidhaa na bwana wa Scrum.

Ifuatayo nitakuambia juu ya jinsi mfumo wetu ulivyokua, jinsi ulivyobadilika, tulifanya nini na kwa nini hasa hii.

Maendeleo

Swali la kwanza tulilojiuliza ni jinsi ya kupata data kutoka kwa mifumo yetu ya sasa. Tuliamua kuwa HTTP ilitufaa kabisa, kwa sababu mifumo yote ya sasa inawasiliana kwa kutuma XML au JSON kupitia HTTP.

Tunatumia seva ya HTTP iliyojengwa ndani ya Tarantool kwa sababu hatuhitaji kusitisha vipindi vya SSL, na utendakazi wake unatutosha.

Kama nilivyosema tayari, mifumo yetu yote inaishi katika mifano tofauti ya data, na kwa pembejeo tunahitaji kuleta kitu kwa mfano tunaojielezea wenyewe. Lugha ilihitajika ambayo iliruhusu data kubadilishwa. Tulichagua Lua ya lazima. Tunaendesha msimbo wote wa ubadilishaji wa data kwenye kisanduku cha mchanga - hapa ni mahali salama ambapo msimbo unaoendesha hauendi. Ili kufanya hivyo, tunapakia tu msimbo unaohitajika, na kuunda mazingira na vitendaji ambavyo haviwezi kuzuia au kuacha chochote.

Baada ya kugeuza, data lazima iangaliwe kwa kufuata muundo tunaounda. Tulijadili kwa muda mrefu mfano unapaswa kuwa nini na lugha gani ya kutumia kuuelezea. Tulichagua Apache Avro kwa sababu lugha ni rahisi na ina usaidizi kutoka kwa Tarantool. Matoleo mapya ya mtindo na msimbo maalum yanaweza kuwekwa mara kadhaa kwa siku, hata chini ya mzigo au bila, wakati wowote wa siku, na kukabiliana na mabadiliko haraka sana.

Baada ya uthibitishaji, data lazima ihifadhiwe. Tunafanya hivyo kwa kutumia vshard (tuna nakala zilizotawanywa za geo za shards).

Zaidi ya hayo, umaalum ni kwamba mifumo mingi inayotutumia data haijali ikiwa tumeipokea au la. Ndiyo sababu tulitekeleza foleni ya ukarabati tangu mwanzo. Ni nini? Ikiwa kwa sababu fulani kitu haifanyi mabadiliko au uthibitishaji wa data, bado tunathibitisha kupokea, lakini wakati huo huo uhifadhi kitu kwenye foleni ya ukarabati. Ni thabiti na iko katika ghala kuu la data ya biashara. Mara moja tuliandika kiolesura cha msimamizi kwa ajili yake, vipimo na arifa mbalimbali. Matokeo yake, hatupotezi data. Hata ikiwa kitu kimebadilika katika chanzo, ikiwa muundo wa data umebadilika, tutaigundua mara moja na tunaweza kuzoea.

Sasa unahitaji kujifunza jinsi ya kurejesha data iliyohifadhiwa. Tulichanganua mifumo yetu kwa uangalifu na kuona kwamba mkusanyiko wa kawaida wa Java na Oracle lazima uwe na aina fulani ya ORM ambayo hubadilisha data kutoka kwa uhusiano hadi kipingamizi. Kwa hivyo kwa nini usipe mara moja vitu kwa mifumo katika mfumo wa grafu? Kwa hivyo tulikubali GraphQL kwa furaha, ambayo ilikidhi mahitaji yetu yote. Inakuruhusu kupokea data katika mfumo wa grafu na kuvuta tu kile unachohitaji hivi sasa. Unaweza hata toleo la API na kubadilika sana.

Karibu mara moja tuligundua kuwa data tuliyokuwa tukitoa haitoshi. Tumeunda kazi ambazo zinaweza kuunganishwa na vitu katika mfano - kimsingi, mashamba yaliyohesabiwa. Hiyo ni, tunaunganisha kazi fulani kwenye shamba, ambayo, kwa mfano, huhesabu bei ya wastani ya quote. Na mtumiaji wa nje ambaye anaomba data hajui hata kwamba hii ni uwanja uliohesabiwa.

Imetekelezwa mfumo wa uthibitishaji.

Kisha tuliona kwamba majukumu kadhaa yalijitokeza katika uamuzi wetu. Jukumu ni aina ya kiunganishi cha vitendaji. Kawaida, majukumu yana wasifu tofauti wa utumiaji wa vifaa:

• T-Connect: Hushughulikia miunganisho inayoingia, CPU ndogo, matumizi ya kumbukumbu ya chini, isiyo na uraia.
• IB-Core: inabadilisha data inayopokea kupitia itifaki ya Tarantool, yaani, inafanya kazi na meza. Pia haina kuhifadhi hali na ni scalable.
• Uhifadhi: huhifadhi data pekee, haitumii mantiki yoyote. Jukumu hili linatekeleza miingiliano rahisi zaidi. Shukrani kubwa kwa vshard.

Hiyo ni, kwa kutumia majukumu, tulitenganisha sehemu tofauti za nguzo kutoka kwa kila mmoja, ambazo zinaweza kupunguzwa kwa kujitegemea.

Kwa hivyo, tumeunda rekodi ya mtiririko wa data ya muamala isiyolingana na foleni ya ukarabati iliyo na kiolesura cha msimamizi. Kurekodi ni asynchronous kutoka kwa mtazamo wa biashara: ikiwa tumehakikishiwa kujiandikia data, bila kujali wapi, basi tutaithibitisha. Ikiwa haijathibitishwa, basi hitilafu imetokea na data inahitaji kutumwa. Hii ni rekodi ya asynchronous.

Upimaji

Tangu mwanzo wa mradi, tuliamua kwamba tutajaribu kutekeleza maendeleo yanayotokana na mtihani. Tunaandika majaribio ya kitengo katika Lua kwa kutumia mfumo wa tarantool/bomba, na majaribio ya ujumuishaji katika Python kwa kutumia mfumo wa pytest. Wakati huo huo, tunahusisha watengenezaji na wachambuzi katika uandishi wa majaribio ya ujumuishaji.

Je, tunatumiaje maendeleo yanayoendeshwa na mtihani?

Ikiwa tunataka kipengele kipya, tunajaribu kukiandikia jaribio kwanza. Tunapogundua hitilafu, tunahakikisha kuwa tunaandika jaribio kwanza, na kisha tu kulirekebisha. Mwanzoni ni ngumu kufanya kazi kama hii, kuna kutokuelewana kwa wafanyikazi, hata hujuma: "Wacha tuirekebishe haraka, fanya kitu kipya, kisha tuifunika kwa vipimo." Hii tu "baadaye" karibu haiji kamwe.

Kwa hiyo, unahitaji kujilazimisha kuandika vipimo kwanza na kuuliza wengine kufanya hivyo. Niamini, maendeleo yanayoendeshwa na mtihani huleta manufaa hata kwa muda mfupi. Utahisi kuwa maisha yako yamekuwa rahisi. Tunahisi kuwa 99% ya msimbo sasa inashughulikiwa na majaribio. Hii inaonekana kama nyingi, lakini hatuna shida yoyote: majaribio huendeshwa kwa kila ahadi.

Walakini, kile tunachopenda zaidi ni upimaji wa mzigo; tunachukulia kuwa muhimu zaidi na tunautekeleza mara kwa mara.

Nitakuambia hadithi kidogo kuhusu jinsi tulivyofanya hatua ya kwanza ya kupima mzigo wa mojawapo ya matoleo ya kwanza. Tuliweka mfumo kwenye kompyuta ndogo ya msanidi programu, tukawasha mzigo na kupokea shughuli elfu 4 kwa sekunde. Matokeo mazuri kwa laptop. Tuliisakinisha kwenye benchi ya upakiaji pepe ya seva nne, dhaifu kuliko katika toleo la umma. Imetumwa kwa kiwango cha chini. Tunaendesha, na tunapata matokeo mabaya zaidi kuliko kwenye kompyuta ya mkononi kwenye thread moja. Maudhui ya mshtuko.

Tulihuzunika sana. Tunaangalia mzigo wa seva, lakini zinageuka kuwa hawana kazi.

Tunawaita watengenezaji, na wanatuelezea, watu wanaokuja kutoka ulimwengu wa Java, kwamba Tarantool ina thread moja. Inaweza tu kutumika kwa ufanisi na msingi mmoja wa processor chini ya mzigo. Kisha tukapeleka idadi ya juu zaidi ya matukio ya Tarantool kwenye kila seva, tukawasha mzigo na tayari tumepokea miamala elfu 14,5 kwa sekunde.

Hebu nieleze tena. Kutokana na mgawanyiko katika majukumu yanayotumia rasilimali kwa njia tofauti, majukumu yetu yanayohusika na kuchakata miunganisho na kubadilisha data yalipakia kichakataji pekee, na sawia kabisa na mzigo.

Katika kesi hii, kumbukumbu ilitumiwa tu kwa usindikaji miunganisho inayoingia na vitu vya muda.

Kinyume chake, kwenye seva za uhifadhi, mzigo wa processor uliongezeka, lakini polepole zaidi kuliko kwenye seva zinazosindika miunganisho.

Na matumizi ya kumbukumbu yalikua kwa uwiano wa moja kwa moja na kiasi cha data iliyopakiwa.

Huduma

Ili kutengeneza bidhaa zetu mpya hasa kama jukwaa la programu, tulitengeneza kipengele cha kupeleka huduma na maktaba juu yake.

Huduma sio tu vipande vidogo vya msimbo vinavyofanya kazi kwenye sehemu fulani. Inaweza kuwa miundo mikubwa na changamano ambayo ni sehemu ya kundi, angalia data ya marejeleo, endesha mantiki ya biashara na urejeshe majibu. Pia tunahamisha taratibu za huduma kwa GraphQL, na mtumiaji hupokea sehemu ya kufikia data kwa wote, kwa ukaguzi wa ndani katika muundo mzima. Ni vizuri sana.

Kwa kuwa huduma zina utendakazi nyingi zaidi, tuliamua kuwa kuwe na maktaba ambamo tutahamisha msimbo unaotumiwa mara kwa mara. Tuliwaongeza kwenye mazingira salama, tukiwa tumeangalia hapo awali kuwa haituvunji chochote. Na sasa tunaweza kugawa mazingira ya ziada kwa kazi katika mfumo wa maktaba.

Tulitaka kuwa na jukwaa sio tu la kuhifadhi, bali pia la kompyuta. Na kwa kuwa tayari tulikuwa na rundo la replicas na shards, tulitekeleza aina ya kompyuta iliyosambazwa na kuiita kupunguza ramani, kwa sababu iligeuka sawa na kupunguza ramani ya awali.

Mifumo ya zamani

Si mifumo yetu yote ya urithi inayoweza kutupigia simu kupitia HTTP na kutumia GraphQL, ingawa inaauni itifaki. Kwa hivyo, tumeunda utaratibu unaoruhusu data kuigwa katika mifumo hii.

Ikiwa kitu kitabadilika kwa ajili yetu, vichochezi vya kipekee huanzishwa katika jukumu la Hifadhi na ujumbe ulio na mabadiliko huishia kwenye foleni ya kuchakata. Inatumwa kwa mfumo wa nje kwa kutumia jukumu tofauti la kuiga. Jukumu hili halihifadhi hali.

Maboresho mapya

Kama unavyokumbuka, kwa mtazamo wa biashara, tulirekodi bila usawa. Lakini basi waligundua kuwa haitoshi, kwa sababu kuna darasa la mifumo ambayo inahitaji kupokea majibu mara moja kuhusu hali ya operesheni. Kwa hivyo tulipanua GraphQL yetu na kuongeza mabadiliko. Wanalingana kikaboni katika dhana iliyopo ya kufanya kazi na data. Kwetu sisi, hii ni hatua moja ya kusoma na kuandika kwa darasa lingine la mifumo.

Pia tuligundua kuwa huduma pekee hazingetutosha, kwa sababu kuna ripoti nzito zinazohitaji kujengwa mara moja kwa siku, wiki, mwezi. Hii inaweza kuchukua muda mrefu, na ripoti zinaweza hata kuzuia kitanzi cha tukio la Tarantool. Kwa hivyo, tuliunda majukumu tofauti: mpangilio na mkimbiaji. Wakimbiaji hawahifadhi hali. Wanaendesha kazi nzito ambazo hatuwezi kuhesabu kwa kuruka. Na jukumu la mpangaji hufuatilia ratiba ya uzinduzi wa kazi hizi, ambayo imeelezewa katika usanidi. Majukumu yenyewe yanahifadhiwa katika sehemu sawa na data ya biashara. Wakati unaofaa unakuja, mpangaji anachukua kazi hiyo, anampa mkimbiaji fulani, ambaye huhesabu na kuokoa matokeo.

Sio kazi zote zinahitaji kuendeshwa kwa ratiba. Ripoti zingine zinahitaji kusomwa kwa mahitaji. Mara tu mahitaji haya yanapokuja, kazi inaundwa kwenye sanduku la mchanga na kutumwa kwa mkimbiaji kwa utekelezaji. Baada ya muda fulani, mtumiaji hupokea jibu la asynchronous kwamba kila kitu kimehesabiwa na ripoti iko tayari.

Hapo awali, tulizingatia dhana ya kuhifadhi data yote, kuibadilisha na sio kuifuta. Lakini katika maisha, mara kwa mara bado unapaswa kufuta kitu, hasa habari mbichi au ya kati. Kulingana na muda wake wa matumizi, tumeunda utaratibu wa kusafisha hifadhi kutoka kwa data iliyopitwa na wakati.

Pia tunaelewa kwamba mapema au baadaye hali itakuja wakati hakutakuwa na nafasi ya kutosha ya kuhifadhi data katika kumbukumbu, lakini hata hivyo data lazima ihifadhiwe. Kwa madhumuni haya, hivi karibuni tutafanya hifadhi ya disk.

Hitimisho

Tulianza na kazi ya kupakia data kwenye modeli moja na tukatumia miezi mitatu kuitengeneza. Tulikuwa na mifumo sita ya usambazaji wa data. Nambari nzima ya ubadilishaji kuwa modeli moja ni kama mistari elfu 30 katika Lua. Na kazi nyingi bado ziko mbele. Wakati mwingine kuna ukosefu wa motisha kutoka kwa timu za jirani, na kuna hali nyingi zinazofanya kazi kuwa ngumu. Ikiwa utawahi kukabiliana na kazi kama hiyo, basi zidisha wakati unaoonekana kuwa wa kawaida kwako kwa utekelezaji wake kwa tatu, au hata nne.

Pia kumbuka kuwa matatizo yaliyopo katika michakato ya biashara hayawezi kutatuliwa kwa kutumia DBMS mpya, hata yenye tija sana. Ninamaanisha nini? Mwanzoni mwa mradi wetu, tuliunda hisia kati ya wateja kwamba sasa tutaleta hifadhidata mpya ya haraka na tutaishi! Michakato itaenda kwa kasi, kila kitu kitakuwa sawa. Kwa kweli, teknolojia haina kutatua matatizo ambayo michakato ya biashara ina, kwa sababu michakato ya biashara ni watu. Na unahitaji kufanya kazi na watu, sio teknolojia.

Maendeleo yanayotokana na mtihani yanaweza kuwa chungu na ya muda mrefu katika hatua za mwanzo. Lakini athari nzuri yake itaonekana hata kwa muda mfupi, wakati hauitaji kufanya chochote kufanya upimaji wa rejista.

Ni muhimu sana kufanya upimaji wa mzigo katika hatua zote za maendeleo. Haraka unapoona kasoro fulani katika usanifu, itakuwa rahisi zaidi kurekebisha, ambayo itakuokoa muda mwingi katika siku zijazo.

Hakuna kitu kibaya na Lua. Mtu yeyote anaweza kujifunza kuandika ndani yake: Msanidi wa Java, msanidi wa JavaScript, msanidi wa Python, mwisho wa mbele au nyuma. Hata wachambuzi wetu wanaandika juu yake.

Tunapozungumza juu ya ukweli kwamba hatuna SQL, inatisha watu. Unapataje data bila SQL? Je, hilo linawezekana? Hakika. Katika mfumo wa darasa la OLTP, SQL haihitajiki. Kuna njia mbadala katika mfumo wa aina fulani ya lugha ambayo inakurudisha mara moja kwa mtazamo unaozingatia hati. Kwa mfano, GraphQL. Na kuna njia mbadala katika mfumo wa kompyuta iliyosambazwa.

Ikiwa unaelewa kuwa utahitaji kuongeza kiwango, basi tengeneza suluhisho lako kwenye Tarantool kwa njia ambayo inaweza kukimbia sambamba kwenye matukio kadhaa ya Tarantool. Ikiwa hutafanya hivyo, itakuwa vigumu na chungu baadaye, kwani Tarantool inaweza kutumia kwa ufanisi msingi mmoja wa processor.

Chanzo: mapenzi.com