Sempre da u filmu "U nostru universu secretu: a vita oculta di a cellula"
L'affari d'investimentu hè unu di i spazii più cumplessi in u mondu bancariu, perchè ùn sò micca solu prestiti, prestiti è dipositi, ma ancu securities, muniti, commodities, derivati è ogni tipu di cumplessità in forma di prudutti strutturati.
Ricertamenti, avemu vistu un aumentu di l'alfabetizazione finanziaria di a pupulazione. Sempre più persone sò implicati in u cummerciu in i mercati di securities. I cunti d'investimentu individuali apparsu micca tantu tempu fà. Permettenu di scambià i mercati di securities è o riceve deduzioni fiscali o evità di pagà i tassi. È tutti i clienti chì venenu à noi volenu gestisce a so cartera è vede i rapporti in tempu reale. Inoltre, a maiò parte di questa cartera hè multi-prodottu, vale à dì, e persone sò clienti di diverse linee di cummerciale.
Inoltre, i bisogni di i regulatori, russi è stranieri, crescenu.
Per risponde à i bisogni attuali è mette a basa per l'aghjurnamenti futuri, avemu sviluppatu un core cummerciale d'investimentu basatu in Tarantool.
Alcune statistiche. L'affari d'investimentu d'Alfa-Bank furnisce servizii di intermediazione per individui è persone giuridiche per furnisce l'uppurtunità di cummerciu in diversi mercati di valori mobiliari, servizii di depositu per u almacenamentu di titoli, servizii di gestione di fiducia per individui cù capitale privatu è grande, servizii per l'emissione di titoli per altre imprese. . L'affari d'investimentu di Alfa-Bank includenu più di 3 mila quote per seconda, chì sò scaricati da diverse piattaforme di cummerciale. Durante u ghjornu di travagliu, più di 300 mila transazzioni sò cunclusi nantu à i mercati in nome di u bancu o di i so clienti. Finu à 5 mila esecuzioni d'ordine per seconda si verificanu nantu à e plataforme esterne è interne. À u listessu tempu, tutti i clienti, sia interni sia esterni, volenu vede e so pusizioni in tempu reale.
Pristoria
Dapoi l'iniziu di l'anni 2000, i nostri spazii di l'affari d'investimentu si sò sviluppati indipindentamente: scambii di scambiu, servizii di brokerage, cummerciu di valute, cummercializazioni over-the-counter in securities è diversi derivati. In u risultatu, avemu cascatu in a trappula di pozzi funziunali. Chì ghjè ? Ogni linea di cummerciale hà i so propri sistemi chì duplicanu e funzioni di l'altri. Ogni sistema hà u so propiu mudellu di dati, ancu s'elli operanu cù i stessi cuncetti: transacciones, strumenti, contrapartiti, quotes, etc. È cum'è ogni sistema evoluzione indipindente, un zoo diversu di tecnulugia emerge.
Inoltre, a basa di codice di i sistemi hè digià abbastanza obsoleta, perchè certi prudutti sò urigginati in a mità di l'anni 1990. E in certi spazii, questu rallentò u prucessu di sviluppu, è ci sò stati prublemi di rendiment.
Requisiti per una nova suluzione
L'imprese anu capitu chì a trasformazione tecnologica hè vitale per u sviluppu ulteriore. On nous a donné des tâches :
- Raccoglie tutti i dati di l'affari in un almacenamentu unicu è veloce è in un mudellu di dati unicu.
- Ùn ci vole micca perde o cambià sta informazione.
- Hè necessariu di versione di e dati, perchè in ogni mumentu u regulatore pò dumandà statistiche per l'anni precedenti.
- Ùn ci vole micca solu purtà qualchi DBMS novu, di moda, ma creà una piattaforma per risolve i prublemi di cummerciale.
Inoltre, i nostri architetti stabiliscenu e so cundizioni:
- A nova suluzione deve esse di classe impresa, vale à dì, deve esse digià pruvata in certi grandi cumpagnie.
- U modu di funziunamentu di a suluzione deve esse missione critica. Questu significa chì duvemu esse prisente in parechji centri di dati simultaneamente è sopravvive cù calma à l'outage di un centru di dati.
- U sistema deve esse scalable horizontalmente. U fattu hè chì tutti i nostri sistemi attuali sò solu scalabili verticalmente, è avemu digià chjappà u tettu per via di a bassa crescita di u putere hardware. Dunque, u mumentu hè ghjuntu quandu avemu bisognu di avè un sistema scalable horizontale per sopravvive.
- Frà l'altri cose, ci anu dettu chì a suluzione duvia esse boni.
Avemu seguitu a strada standard: avemu formulatu i requisiti è cuntattate u dipartimentu di compra. Da quì avemu ricevutu una lista di cumpagnie chì, in generale, sò pronti per fà questu per noi. Avemu dettu à tutti nantu à u prublema, è ricevutu una valutazione di e suluzioni da sei di elli.
À u bancu, ùn pigliamu micca a parolla di nimu; ci piace à pruvà tuttu. Dunque, una cundizione obbligatoria di a nostra cuncurrenza di offerta era di passà e teste di carica. Avemu formulatu compiti di prova di carica, è trè da sei cumpagnie anu digià accunsentutu à implementà una soluzione prototipu basata in tecnulugia in memoria à i so spesi per pruvà.
Ùn vi dicu micca cumu avemu pruvatu tuttu è quantu tempu hà pigliatu, solu riassumeraghju: u megliu rendimentu in i testi di carica hè statu dimustratu da una suluzione prototipu basatu in Tarantool da u gruppu di sviluppu di Mail.ru Group. Avemu firmatu un accordu è cuminciamu u sviluppu. Ci era quattru persone da Mail.ru Group, è da Alfa-Bank ci eranu trè sviluppatori, trè analisti di sistema, un architettu di suluzione, un pruprietariu di produttu è un maestru Scrum.
In seguitu vi dicu cumu u nostru sistema hà crisciutu, cumu hà evolutu, ciò chì avemu fattu è perchè esattamente questu.
Sviluppu
A prima quistione chì avemu dumandatu era cumu uttene dati da i nostri sistemi attuali. Avemu decisu chì HTTP era abbastanza adattatu per noi, perchè tutti i sistemi attuali cumunicanu cù l'altri mandendu XML o JSON per HTTP.
Utilizemu u servitore HTTP integratu in Tarantool perchè ùn avemu micca bisognu di finisce e sessioni SSL, è u so rendiment hè abbastanza per noi.
Comu aghju digià dettu, tutti i nostri sistemi campanu in mudelli di dati diffirenti, è à l'input avemu bisognu di purtà l'ughjettu à u mudellu chì avemu discrittu. Era necessariu una lingua chì permette di trasfurmà e dati. Avemu sceltu imperativu Lua. Eseguimu tuttu u codice di cunversione di dati in un sandbox - questu hè un locu sicuru oltre chì u codice in esecuzione ùn va micca. Per fà questu, carichemu solu u codice necessariu, creendu un ambiente cù funzioni chì ùn ponu micca bluccà o abbandunà nunda.
Dopu à a cunversione, i dati deve esse verificatu per u rispettu di u mudellu chì avemu criatu. Avemu discututu per un bellu pezzu ciò chì u mudellu duveria esse è chì lingua aduprà per discriverà. Avemu sceltu Apache Avro perchè a lingua hè simplice è hà supportu da Tarantool. Novi versioni di u mudellu è u codice persunalizatu ponu esse messu in opera parechje volte à ghjornu, ancu sottu carica o senza, in ogni mumentu di u ghjornu, è adattanu à i cambiamenti assai rapidamente.
Dopu a verificazione, i dati deve esse salvatu. Facemu questu utilizendu vshard (avemu repliche geo-disperse di shards).
Inoltre, a specificità hè tale chì a maiò parte di i sistemi chì ci mandanu dati ùn importa micca se l'avemu ricevutu o micca. Hè per quessa chì avemu implementatu una fila di riparazione da u principiu. Chì ghjè ? Se per una certa ragione un ughjettu ùn hè micca sottumessu à a trasfurmazioni di dati o a verificazione, avemu sempre cunfirmà u ricivutu, ma à u stessu tempu salvà l'ughjettu in a fila di riparazione. Hè coherente è situatu in u magazzinu di dati di l'affari principali. Avemu scrittu immediatamente una interfaccia di amministratore per ellu, diverse metriche è alerti. In u risultatu, ùn perdemu micca dati. Ancu s'è qualcosa hà cambiatu in a fonte, se u mudellu di dati hà cambiatu, l'avemu immediatamente detectà è pudemu adattà.
Avà vi tocca à amparà à ritruvà dati salvatu. Avemu analizatu currettamente i nostri sistemi è hà vistu chì a pila classica di Java è Oracle cuntene necessariamente un tipu di ORM chì cunverte e dati da a relazione à l'ughjettu. Allora perchè micca immediatamente dà l'ogetti à i sistemi in forma di gràficu? Allora avemu aduttatu felice GraphQL, chì risponde à tutti i nostri bisogni. Permette di riceve dati in forma di grafici è tira fora solu ciò chì avete bisognu avà. Pudete ancu versione l'API cun assai flessibilità.
Quasi subitu avemu capitu chì i dati chì avemu estrattu ùn era micca abbastanza. Avemu creatu funzioni chì ponu esse ligati à l'uggetti in u mudellu - essenzialmente, campi calculati. Questu hè, aghjustemu una certa funzione à u campu, chì, per esempiu, calcula u prezzu mediu di quotazione. È u cunsumadore esternu chì dumanda a dati ùn sapi mancu chì questu hè un campu calculatu.
Implementatu un sistema di autentificazione.
Allora avemu nutatu chì parechji roli cristallizzati in a nostra decisione. Un rolu hè un tipu di aggregatore di funzioni. Di genere, i roli anu profili d'usu di l'equipaggiu diffirenti:
- T-Connect: gestisce e cunnessione in entrata, CPU limitata, cunsumu pocu di memoria, senza statu.
- IB-Core : trasforma i dati chì riceve via u protokollu Tarantool, vale à dì, opera cù tavule. Ùn guarda micca ancu u statu è hè scalabile.
- Almacenamiento: guarda solu dati, ùn usa micca logica. Stu rolu implementa l'interfaccia più simplice. Scalabile grazie à vshard.
Vale à dì, usendu roli, avemu disaccoppiatu diverse parti di u cluster l'una di l'altru, chì ponu esse scalate indipindentamente l'una di l'altru.
Cusì, avemu creatu una registrazione di flussu di dati transazionale asincrona è una fila di riparazione cù una interfaccia di amministratore. L'arregistramentu hè asincronu da un puntu di vista di l'affari: s'ellu ci hè garantitu di scrive dati per noi stessi, ùn importa induve, allora cunfirmemu. S'ellu ùn hè micca cunfirmatu, allora qualcosa hè andatu male è e dati deve esse mandatu. Questa hè a registrazione asincrona.
Prucessioni
Da u principiu di u prugettu, avemu decisu chì avemu da pruvà à implementà u sviluppu guidatu da teste. Scrivemu teste di unità in Lua utilizendu u framework tarantool/tap, è testi di integrazione in Python utilizendu u framework pytest. À u listessu tempu, implicamu sia sviluppatori è analisti in testi di integrazione di scrittura.
Cumu usemu u sviluppu guidatu da teste?
Se vulemu una nova funzione, pruvemu di scrive una prova per prima. Quandu scopremu un bug, assicuratemu di scrive prima una prova, è solu dopu corregge. À u principiu, hè difficiule di travaglià cusì, ci hè un malintesi da parte di l'impiegati, ancu u sabotage: "Aghjustamu rapidamente, fate qualcosa di novu, è poi copre cù testi". Solu questu "dopu" ùn vene quasi mai.
Dunque, avete bisognu di furzà à scrive testi prima è dumandà à l'altri di fà. Believe me, u sviluppu guidatu da teste porta benefici ancu à cortu termini. Senterete chì a vostra vita hè diventata più faciule. Sentemu chì u 99% di u codice hè avà coperto da teste. Questu pare assai, ma ùn avemu micca prublemi: e teste currianu annantu à ogni cummit.
Tuttavia, ciò chì ci piace di più hè a prova di carica; u cunsideremu u più impurtante è a realizamu regularmente.
Vi cuntaraghju una piccula storia di cumu avemu realizatu a prima tappa di a prova di carica di una di e prime versioni. Avemu stallatu u sistema nantu à u laptop di u sviluppatore, hà attivatu a carica è hà ricevutu 4 mila transazzione per seconda. Bon risultatu per un laptop. L'avemu installatu nantu à un bancu di carica virtuale di quattru servitori, più debuli chì in a produzzione. Impulsatu à u minimu. U lanciamu, è avemu un risultatu peghju chè in un laptop in un filu. Contenutu di scossa.
Eramu assai tristi. Fighjemu a carica di u servitore, ma risulta chì sò inattivi.
Chjamemu i sviluppatori, è ci spieganu, persone chì venenu da u mondu di Java, chì Tarantool hè unicu filatu. Pò esse usatu in modu efficace solu da un core di processore sottu carica. Dopu avemu implementatu u massimu numeru pussibule di istanzi di Tarantool in ogni servitore, accendemu a carica è hà digià ricevutu 14,5 mila transazzioni per seconda.
Lasciami spiegà di novu. A causa di a divisione in roli chì utilizanu risorse in modu diversu, i nostri roli rispunsevuli di trasfurmazioni di cunnessione è trasfurmazioni di dati caricate solu u processatore, è strettamente proporzionali à a carica.
In questu casu, a memoria hè stata aduprata solu per processà e cunnessione entrate è l'uggetti tempuranee.
À u cuntrariu, nantu à i servitori di almacenamento, a carica di u processatore aumentava, ma assai più lenta chè in i servitori chì processanu e cunnessione.
È u cunsumu di memoria hè cresciutu in proporzione diretta à a quantità di dati caricati.
Servizi
Per sviluppà u nostru novu pruduttu specificamente cum'è una piattaforma di applicazione, avemu creatu un cumpunente per implementà servizii è biblioteche nantu à questu.
I servizii ùn sò micca solu picculi pezzi di codice chì operanu in certi campi. Puderanu esse strutturi abbastanza grandi è cumplessi chì facenu parte di un cluster, verificate e dati di riferimentu, eseguite a logica di l'affari è rinvià e risposte. Avemu ancu esportatu u schema di serviziu à GraphQL, è u cunsumadore riceve un puntu d'accessu universale à e dati, cù introspezione in tuttu u mudellu. Hè assai còmode.
Siccomu i servizii cuntenenu assai più funzioni, avemu decisu chì ci deve esse biblioteche in quale moveremu u codice spessu usatu. L'avemu aghjuntu à l'ambiente sicuru, avendu verificatu prima chì ùn rompe nunda per noi. È avà pudemu assignà ambienti supplementari à e funzioni in forma di biblioteche.
Vulemu avè una piattaforma micca solu per u almacenamentu, ma ancu per l'informatica. E postu chì avemu digià avutu una mansa di rèpliche è shards, avemu implementatu un tipu di computing distribuitu è l'hà chjamatu map reduce, perchè resultò simile à a mappa originale reduce.
Vechi sistemi
Micca tutti i nostri sistemi legati ponu chjamà per HTTP è aduprà GraphQL, ancu s'ellu sustene u protocolu. Per quessa, avemu criatu un miccanisimu chì permette a dati per esse replicate in questi sistemi.
Se qualcosa cambia per noi, i triggers unichi sò attivati in u rolu di Storage è u messagiu cù i cambiamenti finisci in a fila di trasfurmazioni. Hè mandatu à un sistema esternu cù un rolu di replicatore separatu. Stu rolu ùn guarda micca u statu.
Migliure novi
Comu vi ricordate, da un puntu di vista cummerciale, avemu fattu a registrazione asincrona. Ma tandu si capì chì ùn saria micca abbastanza, perchè ci hè una classa di sistemi chì deve riceve immediatamente una risposta nantu à u statutu di l'operazione. Allora avemu allargatu u nostru GraphQL è aghjustatu mutazioni. Si adattanu organicamente à u paradigma esistenti di travaglià cù dati. Per noi, questu hè un puntu unicu di lettura è scrittura per una altra classa di sistemi.
Avemu capitu ancu chì i servizii solu ùn sarianu micca abbastanza per noi, perchè ci sò rapporti abbastanza pesanti chì deve esse custruitu una volta à ghjornu, una settimana, un mese. Questu pò piglià assai tempu, è i rapporti ponu ancu bluccà u ciclu di l'avvenimenti di Tarantool. Per quessa, avemu creatu roli separati: scheduler è runner. I corridori ùn guardanu micca u statu. Eseguinu travaglii pisanti chì ùn pudemu micca calculà à a mosca. È u rolu di pianificatore monitoreghja u calendariu di lanciamentu di sti travaglii, chì hè descrittu in a cunfigurazione. I travaglii stessi sò almacenati in u stessu locu cum'è e dati di l'affari. Quandu vene u tempu ghjusta, u pianificatore piglia u compitu, dà à qualchì corridore, chì cunta è salva u risultatu.
Ùn sò micca tutti i travaglii deve esse eseguiti in un calendariu. Certi rapporti anu da esse leghje nantu à dumanda. Appena stu requisitu ghjunghje, un compitu hè creatu in u sandbox è mandatu à u corridore per l'esekzione. Dopu qualchì tempu, l'utilizatore riceve una risposta asincrona chì tuttu hè statu calculatu è u rapportu hè prestu.
Inizialmente, avemu aderitu à u paradigma di almacenà tutte e dati, versionendu è micca sguassate. Ma in a vita, da u tempu à u tempu avete sempre à sguassà qualcosa, soprattuttu qualchì infurmazione prima o intermediata. Basatu nantu à a scadenza, avemu creatu un mecanismu per pulizziari l'almacenamiento da dati obsoleti.
Avemu ancu capitu chì prima o dopu una situazione vene quandu ùn ci sarà abbastanza spaziu per almacenà e dati in memoria, ma quantunque i dati devenu esse guardati. Per questi scopi, faremu prestu u almacenamiento di discu.
cunchiusioni
Avemu principiatu cù u compitu di carica di dati in un unicu mudellu è hà passatu trè mesi à sviluppà. Avemu avutu sei sistemi di furnimentu di dati. Tuttu u codice di trasfurmazioni in un mudellu unicu hè di circa 30 mila linee in Lua. È a maiò parte di u travagliu hè sempre avanti. Calchì volta ci hè una mancanza di motivazione da i squadre vicini, è ci sò parechje circustanze chì complicanu u travagliu. Sè mai affruntà un compitu simili, tandu multiplicà u tempu chì vi pare normale per a so implementazione da trè, o ancu quattru.
Ricurdate ancu chì i prublemi esistenti in i prucessi di cummerciale ùn ponu esse risolti cù un novu DBMS, ancu assai pruduttivu. Chì vogliu dì ? À l'iniziu di u nostru prughjettu, avemu creatu l'impressione trà i clienti chì avà purteremu una nova basa di dati veloce è vivemu! I prucessi andaranu più veloce, tuttu sarà bè. In fatti, a tecnulugia ùn risolve micca i prublemi chì i prucessi di cummerciale anu, perchè i prucessi di cummerciale sò persone. È avete bisognu di travaglià cù e persone, micca a tecnulugia.
U sviluppu di test-driven pò esse dulurosu è di tempu in i primi stadi. Ma l'effettu pusitivu di questu serà notevuli ancu in u cortu termini, quandu ùn avete micca bisognu di fà nunda per fà una prova di regressione.
Hè estremamente impurtante di fà una prova di carica in tutte e tappe di sviluppu. Quantu prima avete nutatu qualchì difettu in l'architettura, più faciule serà riparatu, chì vi risparmià assai tempu in u futuru.
Ùn ci hè nunda di male cù Lua. Qualchese pò amparà à scrive in questu: sviluppatore Java, sviluppatore JavaScript, sviluppatore Python, front-end o back-end. Ancu i nostri analisti scrivenu nantu à questu.
Quandu parlemu di u fattu chì ùn avemu micca SQL, a ghjente spaventa. "Cumu uttene dati senza SQL? Hè pussibule? Di sicuru. In un sistema di classi OLTP, SQL ùn hè micca necessariu. Ci hè una alternativa in a forma di qualchì tipu di lingua chì vi torna immediatamente à una vista orientata à documentu. Per esempiu, GraphQL. È ci hè una alternativa in a forma di l'informatica distribuita.
Se capite chì avete bisognu di scala, allora cuncepisce a vostra suluzione nantu à Tarantool in tale manera chì si pò eseguisce in parallelu nantu à decine di casi Tarantool. Se ùn fate micca questu, serà difficiule è dulurosu dopu, postu chì Tarantool pò aduprà solu un core di processore.
Source: www.habr.com