Mula pa rin sa pelikulang "Our Secret Universe: The Hidden Life of the Cell"

Ang negosyo sa pamumuhunan ay isa sa mga pinaka-kumplikadong lugar sa mundo ng pagbabangko, dahil mayroong hindi lamang mga pautang, paghiram at deposito, kundi pati na rin ang mga securities, pera, mga kalakal, derivatives at lahat ng uri ng mga kumplikado sa anyo ng mga nakabalangkas na produkto.

Kamakailan, nakita natin ang pagtaas ng financial literacy ng populasyon. Parami nang parami ang mga taong nakikibahagi sa pangangalakal sa mga pamilihan ng seguridad. Ang mga indibidwal na account sa pamumuhunan ay lumitaw hindi pa katagal. Pinapayagan ka nilang i-trade ang mga securities market at makatanggap ng mga bawas sa buwis o maiwasan ang pagbabayad ng mga buwis. At lahat ng kliyente na pumupunta sa amin ay gustong pamahalaan ang kanilang portfolio at makita ang pag-uulat sa real time. Bukod dito, kadalasan ang portfolio na ito ay maraming produkto, iyon ay, ang mga tao ay mga kliyente ng iba't ibang linya ng negosyo.

Bilang karagdagan, ang mga pangangailangan ng mga regulator, parehong Ruso at dayuhan, ay lumalaki.

Upang matugunan ang mga kasalukuyang pangangailangan at mailagay ang pundasyon para sa mga pag-upgrade sa hinaharap, bumuo kami ng isang pangunahing negosyo sa pamumuhunan batay sa Tarantool.

Ilang istatistika. Ang negosyo ng pamumuhunan ng Alfa-Bank ay nagbibigay ng mga serbisyo ng brokerage para sa mga indibidwal at legal na entity upang magbigay ng pagkakataon na makipagkalakalan sa iba't ibang mga merkado ng seguridad, mga serbisyo sa deposito para sa pag-iimbak ng mga seguridad, mga serbisyo sa pamamahala ng tiwala para sa mga indibidwal na may pribado at malaking kapital, mga serbisyo para sa pag-isyu ng mga seguridad para sa ibang mga kumpanya . Kasama sa negosyo ng pamumuhunan ng Alfa-Bank ang higit sa 3 libong quote bawat segundo, na dina-download mula sa iba't ibang platform ng kalakalan. Sa araw ng trabaho, higit sa 300 libong mga transaksyon ang natapos sa mga merkado sa ngalan ng bangko o ng mga kliyente nito. Hanggang sa 5 libong mga pagpapatupad ng order bawat segundo ay nangyayari sa panlabas at panloob na mga platform. Kasabay nito, ang lahat ng mga kliyente, parehong panloob at panlabas, ay gustong makita ang kanilang mga posisyon sa real time.

prehistory

Sa isang lugar mula sa simula ng 2000s, ang aming mga lugar ng negosyo sa pamumuhunan ay binuo nang nakapag-iisa: exchange trading, brokerage services, currency trading, over-the-counter trading sa mga securities at iba't ibang derivatives. Bilang resulta, nahulog tayo sa bitag ng mga functional well. Ano ito? Ang bawat linya ng negosyo ay may sariling mga sistema na duplicate ang mga function ng bawat isa. Ang bawat system ay may sariling modelo ng data, bagama't gumagana ang mga ito na may parehong mga konsepto: mga transaksyon, instrumento, katapat, quote, at iba pa. At habang nag-iisa ang pag-unlad ng bawat sistema, lumitaw ang magkakaibang zoo ng mga teknolohiya.

Bilang karagdagan, ang code base ng mga system ay medyo luma na, dahil ang ilang mga produkto ay nagmula noong kalagitnaan ng 1990s. At sa ilang mga lugar, pinabagal nito ang proseso ng pag-unlad, at may mga problema sa pagganap.

Mga kinakailangan para sa isang bagong solusyon

Napagtanto ng mga negosyo na ang teknolohikal na pagbabago ay mahalaga para sa karagdagang pag-unlad. Binigyan kami ng mga gawain:

1. Kolektahin ang lahat ng data ng negosyo sa isang solong, mabilis na storage at sa isang modelo ng data.
2. Hindi natin dapat mawala o baguhin ang impormasyong ito.
3. Kinakailangang i-version ang data, dahil sa anumang sandali ang regulator ay maaaring humingi ng mga istatistika para sa mga nakaraang taon.
4. Hindi lamang tayo dapat magdala ng ilang bago, sunod sa moda na DBMS, ngunit lumikha ng isang platform para sa paglutas ng mga problema sa negosyo.

Bilang karagdagan, ang aming mga arkitekto ay nagtatakda ng kanilang sariling mga kondisyon:

1. Ang bagong solusyon ay dapat na enterprise-class, iyon ay, dapat na nasubok na ito sa ilang malalaking kumpanya.
2. Ang operating mode ng solusyon ay dapat na kritikal sa misyon. Nangangahulugan ito na dapat tayong naroroon sa maraming data center nang sabay-sabay at mahinahong makaligtas sa pagkawala ng isang data center.
3. Ang system ay dapat na pahalang na nasusukat. Ang katotohanan ay ang lahat ng aming kasalukuyang mga sistema ay patayo lamang na nasusukat, at kami ay umaakyat na sa kisame dahil sa mababang paglaki ng lakas ng hardware. Samakatuwid, dumating ang sandali na kailangan nating magkaroon ng isang pahalang na nasusukat na sistema upang mabuhay.
4. Sa iba pang mga bagay, sinabi sa amin na ang solusyon ay kailangang mura.

Sinundan namin ang karaniwang ruta: bumalangkas kami ng mga kinakailangan at nakipag-ugnayan sa departamento ng pagbili. Mula doon nakatanggap kami ng listahan ng mga kumpanya na, sa pangkalahatan, ay handang gawin ito para sa amin. Sinabi namin sa lahat ang tungkol sa problema, at nakatanggap kami ng pagtatasa ng mga solusyon mula sa anim sa kanila.

Sa bangko, hindi namin kinukuha ang salita ng sinuman para dito; gusto naming subukan ang lahat ng aming sarili. Samakatuwid, ang isang ipinag-uutos na kondisyon ng aming malambot na kompetisyon ay ang pumasa sa mga pagsusulit sa pagkarga. Bumuo kami ng mga gawain sa pagsubok sa pag-load, at tatlo sa anim na kumpanya ang sumang-ayon na magpatupad ng isang prototype na solusyon batay sa mga in-memory na teknolohiya sa sarili nilang gastos upang masubukan ito.

Hindi ko sasabihin sa iyo kung paano namin sinubukan ang lahat at kung gaano ito katagal, ibubuod ko lang: ang pinakamahusay na pagganap sa mga pagsubok sa pag-load ay ipinakita ng isang prototype na solusyon batay sa Tarantool mula sa Mail.ru Group development team. Pumirma kami ng isang kasunduan at nagsimulang bumuo. Mayroong apat na tao mula sa Mail.ru Group, at mula sa Alfa-Bank mayroong tatlong developer, tatlong system analyst, isang solution architect, isang may-ari ng produkto at isang Scrum master.

Susunod, sasabihin ko sa iyo ang tungkol sa kung paano lumago ang aming system, kung paano ito umunlad, kung ano ang ginawa namin at kung bakit eksakto ito.

Development

Ang unang tanong namin sa aming sarili ay kung paano kumuha ng data mula sa aming mga kasalukuyang system. Napagpasyahan namin na ang HTTP ay angkop para sa amin, dahil lahat ng kasalukuyang system ay nakikipag-ugnayan sa isa't isa sa pamamagitan ng pagpapadala ng XML o JSON sa HTTP.

Ginagamit namin ang HTTP server na nakapaloob sa Tarantool dahil hindi namin kailangang wakasan ang mga sesyon ng SSL, at ang pagganap nito ay sapat na para sa amin.

Gaya ng nasabi ko na, lahat ng aming system ay nakatira sa iba't ibang modelo ng data, at sa input kailangan naming dalhin ang bagay sa modelong inilalarawan namin sa aming sarili. Kinailangan ang isang wika na nagpapahintulot sa data na mabago. Pinili namin ang imperative na Lua. Pinapatakbo namin ang lahat ng code ng conversion ng data sa isang sandbox - ito ay isang ligtas na lugar kung saan hindi napupunta ang tumatakbong code. Upang gawin ito, i-load lang namin ang kinakailangang code, na lumilikha ng isang kapaligiran na may mga function na hindi maaaring harangan o i-drop ang anumang bagay.

Pagkatapos ng conversion, dapat suriin ang data para sa pagsunod sa modelong ginagawa namin. Matagal naming tinalakay kung ano ang modelo at kung anong wika ang gagamitin para ilarawan ito. Pinili namin ang Apache Avro dahil simple ang wika at mayroon itong suporta mula sa Tarantool. Ang mga bagong bersyon ng modelo at custom na code ay maaaring gamitin nang maraming beses sa isang araw, kahit na sa ilalim ng pagkarga o wala, anumang oras ng araw, at umangkop sa mga pagbabago nang napakabilis.

Pagkatapos ng pag-verify, dapat na i-save ang data. Ginagawa namin ito gamit ang vshard (mayroon kaming geo-dispersed replicas ng shards).

Bukod dito, ang pagiging tiyak ay tulad na ang karamihan sa mga system na nagpapadala sa amin ng data ay walang pakialam kung natanggap namin ito o hindi. Kaya naman nagpatupad kami ng pila sa pagkukumpuni sa simula pa lang. Ano ito? Kung sa ilang kadahilanan ang isang bagay ay hindi sumasailalim sa pagbabagong-anyo o pagpapatunay ng data, kinukumpirma pa rin namin ang resibo, ngunit sa parehong oras ay i-save ang bagay sa pila ng pag-aayos. Ito ay pare-pareho at matatagpuan sa pangunahing bodega ng data ng negosyo. Agad kaming nagsulat ng interface ng administrator para dito, iba't ibang sukatan at alerto. Bilang resulta, hindi kami nawawalan ng data. Kahit na may nagbago sa pinagmulan, kung nagbago ang modelo ng data, agad naming matutukoy ito at makakaangkop.

Ngayon ay kailangan mong matutunan kung paano kunin ang naka-save na data. Maingat naming sinuri ang aming mga system at nakita namin na ang classic na stack ng Java at Oracle ay kinakailangang naglalaman ng ilang uri ng ORM na nagko-convert ng data mula sa relational patungo sa object. Kaya bakit hindi kaagad magbigay ng mga bagay sa mga system sa anyo ng isang graph? Kaya't masaya naming pinagtibay ang GraphQL, na nakakatugon sa lahat ng aming mga pangangailangan. Binibigyang-daan ka nitong makatanggap ng data sa anyo ng mga graph at bunutin lamang ang kailangan mo ngayon. Maaari mo ring i-version ang API na may lubos na kakayahang umangkop.

Halos kaagad naming napagtanto na ang data na aming kinukuha ay hindi sapat. Gumawa kami ng mga function na maaaring maiugnay sa mga bagay sa modelo - mahalagang mga kalkuladong field. Iyon ay, nag-attach kami ng isang tiyak na function sa field, na, halimbawa, kinakalkula ang average na presyo ng quote. At ang panlabas na mamimili na humihiling ng data ay hindi alam na ito ay isang kalkuladong field.

Nagpatupad ng sistema ng pagpapatunay.

Pagkatapos ay napansin namin na maraming mga tungkulin ang nag-kristal sa aming desisyon. Ang isang tungkulin ay isang uri ng aggregator ng mga function. Karaniwan, ang mga tungkulin ay may iba't ibang profile sa paggamit ng kagamitan:

• T-Connect: pinangangasiwaan ang mga papasok na koneksyon, limitado ang CPU, mababang memory consumption, stateless.
• IB-Core: binabago ang data na natatanggap nito sa pamamagitan ng Tarantool protocol, ibig sabihin, ito ay gumagana sa mga talahanayan. Hindi rin ito nag-iimbak ng estado at nasusukat.
• Imbakan: nag-iimbak lamang ng data, hindi gumagamit ng anumang lohika. Ang papel na ito ay nagpapatupad ng pinakasimpleng mga interface. Scalable salamat sa vshard.

Iyon ay, gamit ang mga tungkulin, na-decoupled namin ang iba't ibang bahagi ng cluster mula sa isa't isa, na maaaring i-scale nang nakapag-iisa sa bawat isa.

Kaya, gumawa kami ng asynchronous na pag-record ng daloy ng data ng transaksyon at isang pila sa pag-aayos na may interface ng admin. Ang pag-record ay asynchronous mula sa isang pananaw sa negosyo: kung kami ay garantisadong magsusulat ng data sa aming sarili, kahit saan, pagkatapos ay kukumpirmahin namin ito. Kung hindi ito nakumpirma, may nangyaring mali at kailangang ipadala ang data. Ito ang asynchronous na pag-record.

Pagsubok

Sa simula pa lang ng proyekto, nagpasya kaming susubukan naming ipatupad ang pag-unlad na hinimok ng pagsubok. Nagsusulat kami ng mga unit test sa Lua gamit ang tarantool/tap framework, at mga integration test sa Python gamit ang pytest framework. Kasabay nito, isinasangkot namin ang parehong mga developer at analyst sa pagsulat ng mga pagsubok sa pagsasama.

Paano namin ginagamit ang pag-unlad na hinimok ng pagsubok?

Kung gusto namin ng ilang bagong feature, susubukan muna naming magsulat ng pagsubok para dito. Kapag nakatuklas kami ng isang bug, tinitiyak naming magsulat muna kami ng isang pagsubok, at pagkatapos ay ayusin ito. Sa una ay mahirap magtrabaho ng ganito, may hindi pagkakaunawaan sa bahagi ng mga empleyado, kahit na sabotahe: "Mabilis nating ayusin ito ngayon, gumawa ng bago, at pagkatapos ay takpan ito ng mga pagsubok." Tanging ang "mamaya" na ito ay halos hindi na darating.

Samakatuwid, kailangan mong pilitin ang iyong sarili na magsulat muna ng mga pagsusulit at hilingin sa iba na gawin ito. Maniwala ka sa akin, ang pag-unlad na hinimok ng pagsubok ay nagdudulot ng mga benepisyo kahit na sa maikling panahon. Mararamdaman mo na naging mas madali ang iyong buhay. Nararamdaman namin na 99% ng code ay sakop na ngayon ng mga pagsubok. Mukhang marami ito, ngunit wala kaming anumang mga problema: tumatakbo ang mga pagsubok sa bawat commit.

Gayunpaman, ang pinakagusto namin ay ang load testing; itinuturing namin itong pinakamahalaga at regular naming isinasagawa.

Sasabihin ko sa iyo ang isang maliit na kuwento tungkol sa kung paano namin isinagawa ang unang yugto ng pagsubok sa pag-load ng isa sa mga unang bersyon. Na-install namin ang system sa laptop ng developer, binuksan ang pag-load at nakatanggap ng 4 na libong mga transaksyon bawat segundo. Magandang resulta para sa isang laptop. Na-install namin ito sa isang virtual load bench ng apat na server, mas mahina kaysa sa produksyon. Na-deploy sa pinakamababa. Pinapatakbo namin ito, at nakakakuha kami ng isang resulta na mas masahol pa kaysa sa isang laptop sa isang thread. Nakakagulat na nilalaman.

Sobrang nalungkot kami. Tinitingnan namin ang pag-load ng server, ngunit lumalabas na sila ay walang ginagawa.

Tinatawag namin ang mga developer, at ipinaliwanag nila sa amin, mga taong nagmula sa mundo ng Java, na ang Tarantool ay single-threaded. Maaari lamang itong epektibong magamit ng isang core ng processor sa ilalim ng pagkarga. Pagkatapos ay nag-deploy kami ng pinakamataas na posibleng bilang ng mga pagkakataon ng Tarantool sa bawat server, na-on ang pag-load at nakatanggap na ng 14,5 libong mga transaksyon bawat segundo.

Hayaan akong magpaliwanag muli. Dahil sa paghahati sa mga tungkulin na gumagamit ng mga mapagkukunan nang iba, ang aming mga tungkulin na responsable para sa pagproseso ng mga koneksyon at pagbabago ng data ay nag-load lamang sa processor, at mahigpit na proporsyonal sa pag-load.

Sa kasong ito, ang memorya ay ginamit lamang para sa pagproseso ng mga papasok na koneksyon at pansamantalang mga bagay.

Sa kabaligtaran, sa mga server ng imbakan, tumaas ang pag-load ng processor, ngunit mas mabagal kaysa sa mga server na nagpoproseso ng mga koneksyon.

At ang pagkonsumo ng memorya ay lumago sa direktang proporsyon sa dami ng data na na-load.

Mga Serbisyo

Upang bumuo ng aming bagong produkto partikular na bilang isang application platform, gumawa kami ng isang bahagi para sa pag-deploy ng mga serbisyo at library dito.

Ang mga serbisyo ay hindi lamang maliliit na piraso ng code na gumagana sa ilang field. Maaari silang maging malaki at kumplikadong mga istruktura na bahagi ng isang kumpol, suriin ang data ng sanggunian, patakbuhin ang lohika ng negosyo at ibalik ang mga tugon. Ini-export din namin ang schema ng serbisyo sa GraphQL, at ang consumer ay tumatanggap ng isang unibersal na access point sa data, na may pagsisiyasat sa buong modelo. Ito ay napaka komportable.

Dahil ang mga serbisyo ay naglalaman ng maraming higit pang mga function, napagpasyahan namin na dapat mayroong mga aklatan kung saan ililipat namin ang madalas na ginagamit na code. Idinagdag namin ang mga ito sa ligtas na kapaligiran, na dati nang nasuri na wala itong masira para sa amin. At ngayon ay maaari na tayong magtalaga ng mga karagdagang kapaligiran sa mga function sa anyo ng mga aklatan.

Nais naming magkaroon ng isang platform hindi lamang para sa imbakan, kundi pati na rin para sa pag-compute. At dahil mayroon na kaming grupo ng mga replicas at shards, nagpatupad kami ng isang uri ng distributed computing at tinawag itong map reduce, dahil ito ay naging katulad ng orihinal na map reduce.

Mga lumang sistema

Hindi lahat ng aming legacy system ay maaaring tumawag sa amin sa HTTP at gumamit ng GraphQL, bagama't sinusuportahan ng mga ito ang protocol. Samakatuwid, gumawa kami ng mekanismo na nagpapahintulot sa data na makopya sa mga system na ito.

Kung may magbabago para sa amin, nati-trigger ang mga natatanging trigger sa tungkulin ng Storage at mapupunta ang mensaheng may mga pagbabago sa queue sa pagproseso. Ito ay ipinadala sa isang panlabas na sistema gamit ang isang hiwalay na replicator role. Ang tungkuling ito ay hindi nag-iimbak ng estado.

Mga bagong pagpapabuti

Tulad ng naaalala mo, mula sa isang pananaw sa negosyo, gumawa kami ng asynchronous na pag-record. Ngunit pagkatapos ay napagtanto nila na hindi ito magiging sapat, dahil mayroong isang klase ng mga sistema na kailangang agad na makatanggap ng tugon tungkol sa katayuan ng operasyon. Kaya pinalawig namin ang aming GraphQL at nagdagdag ng mga mutasyon. Organikong umaangkop ang mga ito sa umiiral na paradigm ng pagtatrabaho sa data. Para sa amin, ito ay isang punto ng parehong pagbabasa at pagsusulat para sa isa pang klase ng mga sistema.

Napagtanto din namin na ang mga serbisyo lamang ay hindi magiging sapat para sa amin, dahil may mga medyo mabibigat na ulat na kailangang gawin isang beses sa isang araw, isang linggo, isang buwan. Maaaring tumagal ito ng mahabang panahon, at maaari pang i-block ng mga ulat ang loop ng kaganapan ng Tarantool. Samakatuwid, gumawa kami ng magkakahiwalay na tungkulin: scheduler at runner. Ang mga runner ay hindi nag-iimbak ng estado. Nagpapatakbo sila ng mabibigat na gawain na hindi natin makalkula sa mabilisang paraan. At sinusubaybayan ng tungkulin ng scheduler ang iskedyul ng paglulunsad ng mga gawaing ito, na inilarawan sa pagsasaayos. Ang mga gawain mismo ay nakaimbak sa parehong lugar bilang data ng negosyo. Kapag dumating ang tamang oras, gagawin ng scheduler ang gawain, ibibigay ito sa ilang runner, na nagbibilang nito at nagse-save ng resulta.

Hindi lahat ng gawain ay kailangang isagawa ayon sa iskedyul. Ang ilang mga ulat ay kailangang basahin kapag hinihiling. Sa sandaling dumating ang kinakailangan na ito, ang isang gawain ay nilikha sa sandbox at ipinadala sa runner para sa pagpapatupad. Pagkaraan ng ilang oras, ang user ay makakatanggap ng isang asynchronous na tugon na ang lahat ay nakalkula at ang ulat ay handa na.

Sa una, sumunod kami sa paradigm ng pag-iimbak ng lahat ng data, pag-bersyon nito at hindi pagtanggal nito. Ngunit sa buhay, paminsan-minsan kailangan mo pa ring tanggalin ang isang bagay, karamihan ay ilang hilaw o intermediate na impormasyon. Batay sa expired, gumawa kami ng mekanismo para sa paglilinis ng storage mula sa lumang data.

Naiintindihan din namin na maaga o huli ay darating ang isang sitwasyon kung kailan walang sapat na espasyo upang mag-imbak ng data sa memorya, ngunit gayunpaman ang data ay dapat na naka-imbak. Para sa mga layuning ito, malapit na kaming gumawa ng disk storage.

Konklusyon

Nagsimula kami sa gawain ng pag-load ng data sa isang modelo at gumugol ng tatlong buwan sa pagbuo nito. Mayroon kaming anim na data supply system. Ang buong transformation code sa isang solong modelo ay humigit-kumulang 30 libong linya sa Lua. At karamihan sa trabaho ay nasa unahan pa. Minsan may kakulangan ng motibasyon mula sa mga kalapit na koponan, at maraming mga pangyayari na nagpapalubha sa trabaho. Kung sakaling nahaharap ka sa isang katulad na gawain, pagkatapos ay i-multiply ang oras na tila normal sa iyo para sa pagpapatupad nito sa tatlo, o kahit apat.

Tandaan din na ang mga kasalukuyang problema sa mga proseso ng negosyo ay hindi malulutas gamit ang isang bagong DBMS, kahit isang napaka-produktibo. Ang ibig kong sabihin? Sa simula ng aming proyekto, lumikha kami ng impresyon sa mga customer na ngayon ay magdadala kami ng bagong mabilis na database at mabubuhay kami! Ang mga proseso ay magiging mas mabilis, ang lahat ay magiging maayos. Sa katunayan, hindi nilulutas ng teknolohiya ang mga problema na mayroon ang mga proseso ng negosyo, dahil ang mga proseso ng negosyo ay mga tao. At kailangan mong makipagtulungan sa mga tao, hindi sa teknolohiya.

Ang pag-unlad na hinimok ng pagsubok ay maaaring maging masakit at matagal sa mga unang yugto. Ngunit ang positibong epekto nito ay magiging kapansin-pansin kahit sa maikling panahon, kapag hindi mo kailangang gumawa ng anumang bagay upang magsagawa ng pagsusuri sa regression.

Napakahalaga na magsagawa ng pagsubok sa pagkarga sa lahat ng mga yugto ng pag-unlad. Kung mas maaga kang mapansin ang ilang depekto sa arkitektura, mas madali itong ayusin, na makakatipid sa iyo ng maraming oras sa hinaharap.

Walang masama kay Lua. Kahit sino ay maaaring matutong magsulat dito: Java developer, JavaScript developer, Python developer, front-end o back-end. Maging ang aming mga analyst ay nagsusulat dito.

Kapag pinag-uusapan natin ang katotohanang wala tayong SQL, nakakatakot ang mga tao. "Paano ka makakakuha ng data nang walang SQL? Posible ba iyon? tiyak. Sa isang OLTP class system, hindi kailangan ang SQL. Mayroong isang alternatibo sa anyo ng ilang uri ng wika na agad na nagbabalik sa iyo sa isang view na nakatuon sa dokumento. Halimbawa, ang GraphQL. At mayroong isang alternatibo sa anyo ng distributed computing.

Kung naiintindihan mo na kakailanganin mong sukatin, pagkatapos ay idisenyo ang iyong solusyon sa Tarantool sa paraang maaari itong tumakbo nang magkatulad sa dose-dosenang mga pagkakataon ng Tarantool. Kung hindi mo ito gagawin, ito ay magiging mahirap at masakit sa ibang pagkakataon, dahil ang Tarantool ay maaari lamang epektibong gumamit ng isang core ng processor.

Pinagmulan: www.habr.com