Imatge de la pel·lícula "Our Secret Universe: The Hidden Life of the Cell"

El negoci inversor és un dels àmbits més complexos del món bancari, perquè no només hi ha préstecs, préstecs i dipòsits, sinó també valors, divises, matèries primeres, derivats i tota mena de complexitats en forma de productes estructurats.

Recentment, hem vist un augment de l'alfabetització financera de la població. Cada cop hi ha més persones que s'impliquen en la negociació als mercats de valors. Els comptes d'inversió individuals van aparèixer no fa gaire. Us permeten operar als mercats de valors i rebre deduccions fiscals o evitar pagar impostos. I tots els clients que vénen a nosaltres volen gestionar la seva cartera i veure'n els informes en temps real. A més, la majoria de les vegades aquesta cartera és multiproducte, és a dir, les persones són clients de diverses línies de negoci.

A més, les necessitats dels reguladors, tant russos com estrangers, creixen.

Per satisfer les necessitats actuals i establir les bases per a futures actualitzacions, hem desenvolupat un nucli de negoci d'inversió basat en Tarantool.

Algunes estadístiques. El negoci d'inversió d'Alfa-Bank ofereix serveis d'intermediació per a persones físiques i jurídiques per oferir l'oportunitat de negociar en diversos mercats de valors, serveis de dipòsit per a l'emmagatzematge de valors, serveis de gestió de confiança per a persones físiques amb capital privat i gran, serveis d'emissió de valors per a altres empreses. . El negoci d'inversió d'Alfa-Bank inclou més de 3 cotitzacions per segon, que es descarreguen des de diverses plataformes comercials. Durant la jornada laboral, es conclouen més de 300 mil transaccions als mercats per compte del banc o dels seus clients. Es produeixen fins a 5 mil execucions d'ordres per segon a plataformes externes i internes. Al mateix temps, tots els clients, tant interns com externs, volen veure les seves posicions en temps real.

prehistòria

Des de principis de la dècada del 2000, les nostres àrees de negoci d'inversió es van desenvolupar de manera independent: negociació de divises, serveis de corretatge, negociació de divises, negociació de valors sense borsa i diversos derivats. Com a resultat, hem caigut en el parany dels pous funcionals. Què és això? Cada línia de negoci té els seus propis sistemes que dupliquen les funcions dels altres. Cada sistema té el seu propi model de dades, tot i que operen amb els mateixos conceptes: transaccions, instruments, contraparts, cotitzacions, etc. I a mesura que cada sistema va evolucionar de manera independent, va sorgir un zoològic divers de tecnologies.

A més, el codi base dels sistemes ja està força obsolet, perquè alguns productes es van originar a mitjans dels anys noranta. I en algunes àrees això va frenar el procés de desenvolupament i hi va haver problemes de rendiment.

Requisits per a una nova solució

Les empreses s'han adonat que la transformació tecnològica és vital per al desenvolupament posterior. Ens van donar tasques:

1. Recolliu totes les dades empresarials en un únic emmagatzematge ràpid i en un únic model de dades.
2. No hem de perdre ni canviar aquesta informació.
3. Cal versionar les dades, perquè en qualsevol moment el regulador pot demanar estadístiques d'anys anteriors.
4. No només hem de portar alguns SGBD nous i de moda, sinó crear una plataforma per resoldre problemes empresarials.

A més, els nostres arquitectes estableixen les seves pròpies condicions:

1. La nova solució ha de ser de classe empresarial, és a dir, ja s'ha de provar en algunes grans empreses.
2. El mode de funcionament de la solució hauria de ser fonamental. Això vol dir que hem d'estar presents en diversos centres de dades simultàniament i sobreviure amb calma a l'interrupció d'un centre de dades.
3. El sistema ha de ser escalable horitzontalment. El fet és que tots els nostres sistemes actuals només són escalables verticalment i ja estem arribant al sostre a causa del baix creixement de la potència del maquinari. Per tant, ha arribat el moment en què necessitem tenir un sistema escalable horitzontalment per sobreviure.
4. Entre altres coses, ens van dir que la solució havia de ser barata.

Vam seguir la ruta estàndard: vam formular els requisits i vam contactar amb el departament de compres. A partir d'aquí vam rebre una llista d'empreses que, en general, estan disposades a fer-ho per nosaltres. Vam explicar a tothom el problema i vam rebre una valoració de les solucions de sis d'ells.

Al banc, no creiem la paraula de ningú; ens agrada provar-ho tot nosaltres mateixos. Per tant, una condició obligatòria del nostre concurs era superar les proves de càrrega. Vam formular tasques de prova de càrrega, i tres de cada sis empreses ja han acceptat implementar una solució prototip basada en tecnologies en memòria pel seu compte per provar-la.

No us diré com ho vam provar tot i quant de temps va trigar, només resumiré: el millor rendiment a les proves de càrrega es va mostrar amb una solució prototip basada en Tarantool de l'equip de desenvolupament del Grup Mail.ru. Vam signar un acord i vam començar el desenvolupament. Hi havia quatre persones del grup Mail.ru i d'Alfa-Bank hi havia tres desenvolupadors, tres analistes de sistemes, un arquitecte de solucions, un propietari de producte i un mestre Scrum.

A continuació us explicaré com va créixer el nostre sistema, com va evolucionar, què vam fer i per què exactament això.

Desenvolupament

La primera pregunta que ens vam fer va ser com obtenir dades dels nostres sistemes actuals. Vam decidir que HTTP era molt adequat per a nosaltres, perquè tots els sistemes actuals es comuniquen entre ells enviant XML o JSON per HTTP.

Utilitzem el servidor HTTP integrat a Tarantool perquè no necessitem finalitzar les sessions SSL i el seu rendiment és suficient per a nosaltres.

Com ja he dit, tots els nostres sistemes viuen en diferents models de dades, i a l'entrada hem d'apropar l'objecte al model que nosaltres mateixos descrivim. Calia un llenguatge que permetés transformar les dades. Vam triar Lua imperatiu. Executem tot el codi de conversió de dades en una caixa de proves: aquest és un lloc segur més enllà del qual no passa el codi en execució. Per fer-ho, simplement carreguem el codi necessari, creant un entorn amb funcions que no poden bloquejar ni deixar anar res.

Després de la conversió, s'ha de comprovar que les dades compleixen amb el model que estem creant. Vam discutir durant molt de temps quin hauria de ser el model i quin llenguatge utilitzar per descriure-lo. Hem escollit Apache Avro perquè el llenguatge és senzill i té suport de Tarantool. Les noves versions del model i el codi personalitzat es poden posar en funcionament diverses vegades al dia, fins i tot amb càrrega o sense, a qualsevol hora del dia, i s'adapten als canvis molt ràpidament.

Després de la verificació, s'han de desar les dades. Ho fem amb vshard (tenim rèpliques de fragments geo-disperses).

A més, l'especificitat és tal que a la majoria dels sistemes que ens envien dades no els importa si les rebem o no. És per això que vam implementar una cua de reparació des del principi. Què és això? Si per algun motiu un objecte no se sotmet a transformació o verificació de dades, encara confirmem la recepció, però al mateix temps desem l'objecte a la cua de reparació. És coherent i es troba al magatzem de dades empresarial principal. Immediatament vam escriure una interfície d'administrador per a això, diverses mètriques i alertes. Com a resultat, no perdem dades. Encara que alguna cosa hagi canviat a la font, si el model de dades ha canviat, ho detectarem immediatament i ens podrem adaptar.

Ara heu d'aprendre a recuperar les dades desades. Hem analitzat acuradament els nostres sistemes i hem vist que la pila clàssica de Java i Oracle conté necessàriament algun tipus d'ORM que converteix les dades de relacionals a objecte. Llavors, per què no donar immediatament objectes als sistemes en forma de gràfic? Així doncs, vam adoptar GraphQL, que satisfà totes les nostres necessitats. Us permet rebre dades en forma de gràfics i treure només el que necessiteu ara mateix. Fins i tot podeu versionar l'API amb molta flexibilitat.

Gairebé immediatament ens vam adonar que les dades que estàvem extreint no eren suficients. Hem creat funcions que es poden enllaçar amb objectes del model, bàsicament, camps calculats. És a dir, adjuntem una funció determinada al camp, que, per exemple, calcula el preu mitjà de cotització. I el consumidor extern que demana les dades ni tan sols sap que es tracta d'un camp calculat.

Implementat un sistema d'autenticació.

Aleshores ens vam adonar que diversos papers van cristal·litzar en la nostra decisió. Un rol és una mena d'agregador de funcions. Normalment, els rols tenen diferents perfils d'ús d'equips:

• T-Connect: gestiona connexions entrants, CPU limitada, baix consum de memòria, sense estat.
• IB-Core: transforma les dades que rep mitjançant el protocol Tarantool, és a dir, opera amb taules. Tampoc emmagatzema estat i és escalable.
• Emmagatzematge: només emmagatzema dades, no utilitza cap lògica. Aquesta funció implementa les interfícies més senzilles. Escalable gràcies a vshard.

És a dir, utilitzant rols, vam desacoblar diferents parts del clúster entre si, que es poden escalar independentment les unes de les altres.

Per tant, hem creat un enregistrament asíncron de flux de dades transaccionals i una cua de reparació amb una interfície d'administració. L'enregistrament és asíncron des del punt de vista empresarial: si tenim la garantia d'escriure dades per a nosaltres mateixos, no importa on, aleshores ho confirmarem. Si no es confirma, hi ha hagut un error i les dades s'han d'enviar. Aquest és l'enregistrament asíncron.

Proves

Des del principi del projecte, vam decidir que intentaríem implementar el desenvolupament basat en proves. Escrivim proves unitàries a Lua utilitzant el marc tarantool/tap, i proves d'integració a Python mitjançant el marc pytest. Al mateix temps, impliquem tant desenvolupadors com analistes en la redacció de proves d'integració.

Com utilitzem el desenvolupament basat en proves?

Si volem alguna característica nova, primer intentem escriure'n una prova. Quan descobrim un error, ens assegurem d'escriure primer una prova i només després la solucionem. Al principi és difícil treballar així, hi ha malentesos per part dels empleats, fins i tot sabotatge: "Arregelem-ho ràpidament, fem alguna cosa nova i després cobrem-ho amb proves". Només aquest "després" gairebé mai no arriba.

Per tant, cal forçar-se a escriure proves primer i demanar als altres que ho facin. Creieu-me, el desenvolupament basat en proves aporta beneficis fins i tot a curt termini. Sentiràs que la teva vida s'ha tornat més fàcil. Creiem que ara el 99% del codi està cobert per proves. Això sembla molt, però no tenim cap problema: les proves s'executen a cada commit.

No obstant això, el que més ens agrada són les proves de càrrega; considerem que és la més important i les fem amb regularitat.

Us explicaré una petita història sobre com vam dur a terme la primera etapa de proves de càrrega d'una de les primeres versions. Hem instal·lat el sistema a l'ordinador portàtil del desenvolupador, hem activat la càrrega i hem aconseguit 4 mil transaccions per segon. Bon resultat per a un ordinador portàtil. El vam instal·lar en un banc de càrrega virtual de quatre servidors, més feble que en producció. Desplegat al mínim. L'executem i obtenim un resultat pitjor que en un ordinador portàtil en un sol fil. Contingut de xoc.

Estàvem molt tristos. Mirem la càrrega del servidor, però resulta que estan inactius.

Truquem als desenvolupadors, i ens expliquen, gent que ve del món de Java, que Tarantool és d'un sol fil. Només pot ser utilitzat efectivament per un nucli de processador sota càrrega. A continuació, vam desplegar el màxim nombre possible d'instàncies de Tarantool a cada servidor, vam activar la càrrega i ja vam rebre 14,5 mil transaccions per segon.

Deixeu-me explicar de nou. A causa de la divisió en rols que utilitzen els recursos de manera diferent, els nostres rols encarregats de processar les connexions i la transformació de dades només carregaven el processador, i estrictament proporcionals a la càrrega.

En aquest cas, la memòria només es va utilitzar per processar connexions entrants i objectes temporals.

Al contrari, als servidors d'emmagatzematge, la càrrega del processador va augmentar, però molt més lenta que als servidors que processen connexions.

I el consum de memòria va créixer en proporció directa a la quantitat de dades carregades.

Serveis

Per desenvolupar el nostre nou producte específicament com a plataforma d'aplicacions, vam crear un component per desplegar-hi serveis i biblioteques.

Els serveis no són només petites peces de codi que operen en alguns camps. Poden ser estructures bastant grans i complexes que formen part d'un clúster, comproven dades de referència, executen la lògica empresarial i retornen respostes. També exportem l'esquema de servei a GraphQL i el consumidor rep un punt d'accés universal a les dades, amb introspecció a tot el model. És molt còmode.

Com que els serveis contenen moltes més funcions, vam decidir que hi hauria d'haver biblioteques en les quals mourem el codi d'ús freqüent. Els hem afegit a l'entorn segur, havent comprovat prèviament que no ens trenca res. I ara podem assignar entorns addicionals a funcions en forma de biblioteques.

Volíem tenir una plataforma no només per a l'emmagatzematge, sinó també per a la informàtica. I com que ja teníem un munt de rèpliques i fragments, vam implementar una mena de computació distribuïda i l'hem anomenat map reduce, perquè va resultar semblant al map reduce original.

Sistemes antics

No tots els nostres sistemes heretats ens poden trucar per HTTP i utilitzar GraphQL, tot i que admeten el protocol. Per tant, hem creat un mecanisme que permet replicar les dades en aquests sistemes.

Si alguna cosa canvia per a nosaltres, s'activen activadors únics a la funció d'emmagatzematge i el missatge amb els canvis acaba a la cua de processament. S'envia a un sistema extern mitjançant un rol de replicador independent. Aquesta funció no emmagatzema l'estat.

Noves millores

Com recordeu, des del punt de vista empresarial, vam fer gravació asíncrona. Però aleshores es van adonar que no n'hi hauria prou, perquè hi ha una classe de sistemes que han de rebre immediatament una resposta sobre l'estat de l'operació. Així que vam ampliar el nostre GraphQL i vam afegir mutacions. Encaixen orgànicament en el paradigma existent de treballar amb dades. Per a nosaltres, aquest és un punt únic de lectura i escriptura per a una altra classe de sistemes.

També ens vam adonar que els serveis sols no serien suficients per a nosaltres, perquè hi ha informes força pesats que s'han de fer un cop al dia, a la setmana, al mes. Això pot trigar molt de temps i els informes fins i tot poden bloquejar el bucle d'esdeveniments de Tarantool. Per tant, hem creat rols separats: planificador i corredor. Els corredors no emmagatzemen l'estat. Realitzen tasques pesades que no podem calcular sobre la marxa. I el rol del planificador supervisa el calendari d'inici d'aquestes tasques, que es descriu a la configuració. Les tasques en si s'emmagatzemen al mateix lloc que les dades empresarials. Quan arriba el moment adequat, el planificador agafa la tasca, la lliura a algun corredor, que la compta i guarda el resultat.

No totes les tasques s'han d'executar segons un calendari. Alguns informes s'han de llegir sota demanda. Tan bon punt arriba aquest requisit, es crea una tasca al sandbox i s'envia al corredor perquè l'executi. Després d'un temps, l'usuari rep una resposta asíncrona que tot s'ha calculat i l'informe està preparat.

Inicialment, ens vam adherir al paradigma d'emmagatzemar totes les dades, versionar-les i no eliminar-les. Però a la vida, de tant en tant encara has d'esborrar alguna cosa, sobretot informació bruta o intermèdia. A partir de la caducitat, vam crear un mecanisme per netejar l'emmagatzematge de dades obsoletes.

També entenem que tard o d'hora arribarà una situació en què no hi haurà prou espai per emmagatzemar dades a la memòria, però tanmateix les dades s'han d'emmagatzemar. Amb aquests propòsits, aviat farem emmagatzematge en disc.

Conclusió

Vam començar amb la tasca de carregar dades en un únic model i vam estar tres mesos desenvolupant-lo. Teníem sis sistemes de subministrament de dades. Tot el codi de transformació en un únic model té unes 30 mil línies a Lua. I la major part de la feina encara està per davant. A vegades hi ha falta de motivació per part dels equips veïns, i hi ha moltes circumstàncies que dificulten la feina. Si alguna vegada us enfronteu a una tasca similar, multipliqueu el temps que us sembla normal per a la seva implementació per tres, o fins i tot per quatre.

Recordeu també que els problemes existents en els processos empresarials no es poden resoldre amb un nou SGBD, encara que sigui molt productiu. El que vull dir? A l'inici del nostre projecte, vam crear la impressió entre els clients que ara portarem una nova base de dades ràpida, i viurem! Els processos aniran més ràpid, tot anirà bé. De fet, la tecnologia no resol els problemes que tenen els processos empresarials, perquè els processos empresarials són persones. I cal treballar amb persones, no amb tecnologia.

El desenvolupament basat en proves pot ser dolorós i requereix molt de temps en les primeres etapes. Però l'efecte positiu es notarà fins i tot a curt termini, quan no cal fer res per fer proves de regressió.

És extremadament important dur a terme proves de càrrega en totes les etapes de desenvolupament. Com més aviat noteu algun defecte en l'arquitectura, més fàcil serà arreglar-lo, cosa que us estalviarà molt de temps en el futur.

No hi ha res dolent amb Lua. Qualsevol persona pot aprendre a escriure-hi: desenvolupador Java, desenvolupador JavaScript, desenvolupador Python, front-end o back-end. Fins i tot els nostres analistes hi escriuen.

Quan parlem del fet que no tenim SQL, aterra a la gent. "Com s'obtenen dades sense SQL? Això és possible? Certament. En un sistema de classes OLTP, SQL no és necessari. Hi ha una alternativa en forma d'algun tipus de llenguatge que us retorna immediatament a una vista orientada al document. Per exemple, GraphQL. I hi ha una alternativa en forma de computació distribuïda.

Si enteneu que haureu d'escalar, dissenyeu la vostra solució a Tarantool de manera que es pugui executar en paral·lel a desenes d'instàncies de Tarantool. Si no ho feu, serà difícil i dolorós més endavant, ja que Tarantool només pot utilitzar de manera efectiva un nucli de processador.

Font: www.habr.com