Ankoraŭ el la filmo "Nia Sekreta Universo: La Kaŝa Vivo de la Ĉelo"

La investa komerco estas unu el la plej kompleksaj areoj en la banka mondo, ĉar ekzistas ne nur pruntoj, pruntoj kaj deponejoj, sed ankaŭ valorpaperoj, valutoj, varoj, derivaĵoj kaj ĉiaj kompleksaĵoj en formo de strukturitaj produktoj.

Lastatempe, ni vidis pliiĝon en la financa alfabeteco de la loĝantaro. Pli kaj pli da homoj okupiĝas pri komerco en la valorpaperaj merkatoj. Individuaj investkontoj aperis antaŭ ne longe. Ili permesas vin komerci la valorpaperajn merkatojn kaj aŭ ricevi impostajn deduktojn aŭ eviti pagi impostojn. Kaj ĉiuj klientoj, kiuj venas al ni, volas administri sian biletujon kaj vidi raportadon en reala tempo. Plie, plej ofte ĉi tiu biletujo estas multprodukta, tio estas, homoj estas klientoj de diversaj komercaj linioj.

Krome, la bezonoj de regulistoj, kaj rusaj kaj eksterlandaj, kreskas.

Por renkonti aktualajn bezonojn kaj meti la fundamenton por estontaj ĝisdatigoj, ni evoluigis investan komercan kernon bazitan sur Tarantool.

Kelkaj statistikoj. La investkomerco de Alfa-Bank disponigas kurtaĝajn servojn por individuoj kaj juraj entoj por doni la ŝancon komerci sur diversaj valorpaperaj merkatoj, deponejoj por stokado de valorpaperoj, fidadministradservoj por individuoj kun privata kaj granda kapitalo, servoj por eldonado de valorpaperoj por aliaj kompanioj. . La investa komerco de Alfa-Banko inkluzivas pli ol 3 mil citaĵojn por sekundo, kiuj estas elŝutitaj de diversaj komercaj platformoj. Dum la labortago, pli ol 300 mil transakcioj estas finitaj sur la merkatoj nome de la banko aŭ ĝiaj klientoj. Ĝis 5 mil ordaj ekzekutoj sekundo okazas sur eksteraj kaj internaj platformoj. Samtempe, ĉiuj klientoj, kaj internaj kaj eksteraj, volas vidi siajn poziciojn en reala tempo.

antaŭhistorio

Ie de la komenco de la 2000-aj jaroj, niaj areoj de investkomerco evoluis sendepende: interŝanĝkomerco, kurtadservoj, valutkomerco, senkomerca komerco de valorpaperoj kaj diversaj derivaĵoj. Kiel rezulto, ni falis en la kaptilon de funkciaj putoj. Kio ĝi estas? Ĉiu komerca linio havas siajn proprajn sistemojn, kiuj duobligas la funkciojn de unu la alian. Ĉiu sistemo havas sian propran datummodelon, kvankam ili funkcias kun la samaj konceptoj: transakcioj, instrumentoj, kontraŭpartioj, citaĵoj, ktp. Kaj ĉar ĉiu sistemo evoluis sendepende, diversa zoo de teknologioj aperis.

Krome, la kodbazo de la sistemoj jam estas sufiĉe malaktuala, ĉar iuj produktoj originis meze de la 1990-aj jaroj. Kaj en iuj lokoj ĉi tio malrapidigis la evoluprocezon, kaj estis agado problemoj.

Postuloj por nova solvo

Entreprenoj rimarkis, ke teknologia transformo estas esenca por plua evoluo. Ni ricevis taskojn:

1. Kolektu ĉiujn komercajn datumojn en ununura, rapida stokado kaj en ununura datummodelo.
2. Ni ne devas perdi aŭ ŝanĝi ĉi tiun informon.
3. Necesas versio de la datumoj, ĉar ĉiumomente la reguligisto povas peti statistikojn pri antaŭaj jaroj.
4. Ni devas ne nur alporti novajn, modajn DBMS, sed krei platformon por solvi komercajn problemojn.

Krome, niaj arkitektoj starigas siajn proprajn kondiĉojn:

1. La nova solvo devas esti entreprena klaso, tio estas, ĝi devas esti jam provita en iuj grandaj kompanioj.
2. La operacia reĝimo de la solvo devus esti misiokritika. Ĉi tio signifas, ke ni devas ĉeesti en pluraj datumcentroj samtempe kaj trankvile travivi la malfunkcion de unu datumcentro.
3. La sistemo devas esti horizontale skalebla. La fakto estas, ke ĉiuj niaj nunaj sistemoj estas nur vertikale skaleblaj, kaj ni jam trafas la plafonon pro la malalta kresko de aparatara potenco. Tial venis la momento, kiam ni bezonas havi horizontale skaleblan sistemon por pluvivi.
4. Interalie oni diris al ni, ke la solvo devas esti malmultekosta.

Ni sekvis la norman vojon: ni formulis la postulojn kaj kontaktis la aĉetsekcion. De tie ni ricevis liston de kompanioj, kiuj ĝenerale pretas fari tion por ni. Ni rakontis al ĉiuj pri la problemo, kaj ricevis takson de la solvoj de ses el ili.

Ĉe la banko, ni ne prenas la vorton de iu ajn; ni ŝatas provi ĉion mem. Sekve, deviga kondiĉo de nia licita konkurso estis trapasi ŝarĝtestojn. Ni formulis ŝarĝtestajn taskojn, kaj tri el ses kompanioj jam konsentis efektivigi prototipan solvon bazitan sur en-memoraj teknologioj je sia propra elspezo por testi ĝin.

Mi ne diros al vi, kiel ni provis ĉion kaj kiom da tempo ĝi daŭris, mi nur resumos: la plej bona agado en ŝarĝtestoj estis montrita per prototipa solvo bazita sur Tarantool de la disvolva teamo de Mail.ru Group. Ni subskribis interkonsenton kaj komencis evoluon. Estis kvar homoj de Mail.ru Group, kaj de Alfa-Banko estis tri programistoj, tri sistemanalizistoj, solvo-arkitekto, produktposedanto kaj Scrum-majstro.

Poste mi rakontos al vi kiel nia sistemo kreskis, kiel ĝi evoluis, kion ni faris kaj kial ĝuste ĉi tion.

Disvolviĝo

La unua demando, kiun ni demandis al ni, estis kiel akiri datumojn de niaj nunaj sistemoj. Ni decidis, ke HTTP sufiĉe taŭgas por ni, ĉar ĉiuj nunaj sistemoj komunikas unu kun la alia sendante XML aŭ JSON per HTTP.

Ni uzas la HTTP-servilon konstruitan en Tarantool ĉar ni ne bezonas ĉesigi SSL-sesiojn, kaj ĝia agado sufiĉas por ni.

Kiel mi jam diris, ĉiuj niaj sistemoj vivas en malsamaj datummodeloj, kaj ĉe la enigo ni devas alporti la objekton al la modelo, kiun ni mem priskribas. Necesis lingvo, kiu permesis transformi datumojn. Ni elektis imperativo Lua. Ni rulas ĉiun datuman konvertan kodon en sablokesto - ĉi tio estas sekura loko preter kiu la rulkodo ne iras. Por fari tion, ni simple ŝarĝas la bezonatan kodon, kreante medion kun funkcioj, kiuj ne povas bloki aŭ faligi ion ajn.

Post konvertiĝo, la datumoj devas esti kontrolitaj por konformeco al la modelo, kiun ni kreas. Ni longe diskutis, kia estu la modelo kaj kian lingvon oni uzu por priskribi ĝin. Ni elektis Apache Avro ĉar la lingvo estas simpla kaj ĝi havas subtenon de Tarantool. Novaj versioj de la modelo kaj kutima kodo povas funkcii plurfoje tage, eĉ sub ŝarĝo aŭ sen, en ajna momento de la tago, kaj adaptiĝas al ŝanĝoj tre rapide.

Post konfirmo, la datumoj devas esti konservitaj. Ni faras ĉi tion uzante vshard (ni havas geo-disigitajn kopiojn de fragmentoj).

Krome, la specifeco estas tia, ke la plej multaj sistemoj, kiuj sendas al ni datumojn, ne zorgas, ĉu ni ricevis ĝin aŭ ne. Tial ni efektivigis riparvicon de la komenco mem. Kio ĝi estas? Se ial objekto ne spertas datuman transformon aŭ kontrolon, ni ankoraŭ konfirmas kvitancon, sed samtempe konservas la objekton en la riparvico. Ĝi estas konsekvenca kaj situas en la ĉefa komerca datuma stokejo. Ni tuj skribis administrantan interfacon por ĝi, diversajn metrikojn kaj atentigojn. Kiel rezulto, ni ne perdas datumojn. Eĉ se io ŝanĝiĝis en la fonto, se la datummodelo ŝanĝiĝis, ni tuj detektos ĝin kaj povos adaptiĝi.

Nun vi devas lerni kiel reakiri konservitajn datumojn. Ni zorge analizis niajn sistemojn kaj vidis, ke la klasika stako de Java kaj Oracle nepre enhavas ian ORM, kiu konvertas datumojn de rilata al objekto. Do kial ne tuj doni objektojn al sistemoj en formo de grafeo? Do ni feliĉe adoptis GraphQL, kiu renkontis ĉiujn niajn bezonojn. Ĝi permesas vin ricevi datumojn en formo de grafikaĵoj kaj eltiri nur tion, kion vi bezonas nun. Vi eĉ povas version la API kun tre multe da fleksebleco.

Preskaŭ tuj ni rimarkis, ke la datumoj, kiujn ni ĉerpis, ne sufiĉas. Ni kreis funkciojn, kiuj povas esti ligitaj al objektoj en la modelo - esence, kalkulitaj kampoj. Tio estas, ni almetas certan funkcion al la kampo, kiu, ekzemple, kalkulas la mezan citprezon. Kaj la ekstera konsumanto, kiu petas la datumojn, eĉ ne scias, ke tio estas kalkulita kampo.

Efektivigis aŭtentikigsistemon.

Tiam ni rimarkis, ke pluraj roloj kristaliĝis en nia decido. Rolo estas speco de agregaciilo de funkcioj. Tipe, roloj havas malsamajn ekipaĵuzoprofilojn:

• T-Connect: pritraktas envenantajn konektojn, CPU limigitan, malaltan memorkonsumon, sennacian.
• IB-Core: transformas la datumojn, kiujn ĝi ricevas per la protokolo Tarantool, tio estas, ĝi funkcias per tabeloj. Ĝi ankaŭ ne konservas staton kaj estas skalebla.
• Stokado: nur konservas datumojn, ne uzas ajnan logikon. Ĉi tiu rolo efektivigas la plej simplajn interfacojn. Skalebla danke al vshard.

Tio estas, uzante rolojn, ni malkunligas malsamajn partojn de la areto unu de la alia, kiuj povas esti skalaj sendepende unu de la alia.

Do, ni kreis nesinkronan transakcian datumfluan registradon kaj riparvicon kun administra interfaco. La registrado estas nesinkrona el komerca vidpunkto: se ni garantias skribi datumojn al ni mem, ne gravas kie, tiam ni konfirmos ĝin. Se ĝi ne estas konfirmita, tiam io misfunkciis kaj la datumoj devas esti senditaj. Ĉi tio estas la nesinkrona registrado.

Testado

Ekde la komenco mem de la projekto, ni decidis, ke ni provos efektivigi testan disvolviĝon. Ni skribas unutestojn en Lua uzante la tarantool/tap-kadron, kaj integrigajn testojn en Python uzante la pytest-kadron. Samtempe, ni implikas kaj programistojn kaj analizistojn en verkado de integrigaj testoj.

Kiel ni uzas testan disvolviĝon?

Se ni volas iun novan funkcion, ni unue provas skribi teston por ĝi. Kiam ni malkovras cimon, ni certigas unue verki teston, kaj nur tiam ripari ĝin. Komence estas malfacile labori tiel, estas miskompreno flanke de dungitoj, eĉ sabotado: "Ni rapide riparu ĝin nun, faru ion novan, kaj poste kovru ĝin per testoj." Nur ĉi tiu "poste" preskaŭ neniam venas.

Tial vi devas devigi vin unue skribi testojn kaj peti aliajn fari ĝin. Kredu min, test-movita evoluo alportas avantaĝojn eĉ baldaŭ. Vi sentos, ke via vivo fariĝis pli facila. Ni sentas, ke 99% de la kodo nun estas kovritaj de testoj. Ĉi tio ŝajnas multe, sed ni ne havas problemojn: testoj funkcias ĉe ĉiu komitaĵo.

Tamen, kion ni plej amas, estas ŝarĝotestado; ni konsideras ĝin la plej grava kaj faras ĝin regule.

Mi rakontos al vi etan historion pri kiel ni faris la unuan etapon de ŝarĝotestado de unu el la unuaj versioj. Ni instalis la sistemon sur la tekkomputilo de la programisto, ŝaltis la ŝarĝon kaj ricevis 4 mil transakciojn por sekundo. Bona rezulto por tekkomputilo. Ni instalis ĝin sur virtuala ŝarĝa benko de kvar serviloj, pli malforta ol en produktado. Deplojita al minimumo. Ni kuras ĝin, kaj ni ricevas rezulton pli malbona ol sur tekkomputilo en unu fadeno. Ŝoka enhavo.

Ni estis tre malĝojaj. Ni rigardas la servilon-ŝarĝon, sed rezultas, ke ili estas neaktivaj.

Ni vokas la programistojn, kaj ili klarigas al ni, homoj kiuj venas el la mondo de Java, ke Tarantool estas unufadena. Ĝi nur povas esti efike uzata de unu procesora kerno sub ŝarĝo. Tiam ni deplojis la maksimuman eblan nombron da Tarantool-instancoj sur ĉiu servilo, ŝaltis la ŝarĝon kaj jam ricevis 14,5 mil transakciojn por sekundo.

Lasu min klarigi denove. Pro la divido en roloj, kiuj uzas rimedojn malsame, niaj roloj respondecaj pri prilaborado de konektoj kaj datumtransformo ŝarĝis nur la procesoron, kaj strikte proporciaj al la ŝarĝo.

En ĉi tiu kazo, memoro estis uzata nur por prilaborado de envenantaj ligoj kaj provizoraj objektoj.

Male, ĉe stokaj serviloj, procesoroŝarĝo pliiĝis, sed multe pli malrapida ol ĉe serviloj, kiuj prilaboras konektojn.

Kaj la konsumo de memoro kreskis rekte proporcie al la kvanto de datumoj ŝarĝitaj.

Servoj

Por evoluigi nian novan produkton specife kiel aplikaĵplatformo, ni kreis komponenton por deploji servojn kaj bibliotekojn sur ĝi.

Servoj ne estas nur malgrandaj pecoj de kodo, kiuj funkcias sur iuj kampoj. Ili povas esti sufiĉe grandaj kaj kompleksaj strukturoj kiuj estas parto de areto, kontrolas referencajn datumojn, funkciigas komercan logikon kaj resendas respondojn. Ni ankaŭ eksportas la servoskemon al GraphQL, kaj la konsumanto ricevas universalan alirpunkton al la datumoj, kun introspekto tra la tuta modelo. Ĝi estas tre komforta.

Ĉar servoj enhavas multe pli da funkcioj, ni decidis, ke estu bibliotekoj, en kiuj ni movos ofte uzatan kodon. Ni aldonis ilin al la sekura medio, antaŭe kontrolinte, ke ĝi ne rompas ion ajn por ni. Kaj nun ni povas asigni pliajn mediojn al funkcioj en la formo de bibliotekoj.

Ni volis havi platformon ne nur por stokado, sed ankaŭ por komputado. Kaj ĉar ni jam havis amason da kopioj kaj pecetoj, ni efektivigis specon de distribuita komputado kaj nomis ĝin mapredukto, ĉar ĝi rezultis simila al la originala mapredukto.

Malnovaj sistemoj

Ne ĉiuj niaj heredaj sistemoj povas voki nin per HTTP kaj uzi GraphQL, kvankam ili subtenas la protokolon. Tial ni kreis mekanismon, kiu ebligas reprodukti datumojn en ĉi tiujn sistemojn.

Se io ŝanĝiĝas por ni, unikaj ellasiloj estas ekigitaj en la Stokado-rolo kaj la mesaĝo kun la ŝanĝoj finiĝas en la pretigvico. Ĝi estas sendita al ekstera sistemo uzante apartan reproduktan rolon. Ĉi tiu rolo ne konservas staton.

Novaj plibonigoj

Kiel vi memoras, el komerca vidpunkto, ni faris nesinkronan registradon. Sed tiam ili rimarkis, ke ĝi ne sufiĉus, ĉar ekzistas klaso de sistemoj, kiuj bezonas tuj ricevi respondon pri la stato de la operacio. Do ni etendis nian GraphQL kaj aldonis mutaciojn. Ili organike konvenas en la ekzistantan paradigmon labori kun datumoj. Por ni, ĉi tio estas ununura punkto de kaj legado kaj skribo por alia klaso de sistemoj.

Ni ankaŭ rimarkis, ke nur servoj ne sufiĉus por ni, ĉar estas sufiĉe pezaj raportoj, kiujn oni devas konstrui unufoje tage, semajne, monate. Ĉi tio povas daŭri longan tempon, kaj raportoj eĉ povas bloki la okazaĵbuklon de Tarantool. Tial ni kreis apartajn rolojn: planisto kaj kuristo. Kuristoj ne konservas staton. Ili plenumas pezajn taskojn, kiujn ni ne povas kalkuli sur la flugo. Kaj la planisto-rolo kontrolas la lanĉan horaron de ĉi tiuj taskoj, kiu estas priskribita en la agordo. La taskoj mem estas konservitaj en la sama loko kiel komercaj datumoj. Kiam la ĝusta tempo venas, la planisto prenas la taskon, donas ĝin al iu kuristo, kiu kalkulas ĝin kaj konservas la rezulton.

Ne ĉiuj taskoj devas esti rulitaj laŭ horaro. Iuj raportoj devas esti legitaj laŭpeto. Tuj kiam ĉi tiu postulo alvenas, tasko estas kreita en la sablokesto kaj sendita al la kuristo por ekzekuto. Post iom da tempo, la uzanto ricevas nesinkronan respondon, ke ĉio estas kalkulita kaj la raporto estas preta.

Komence, ni aliĝis al la paradigmo konservi ĉiujn datumojn, versioni ĝin kaj ne forigi ĝin. Sed en la vivo, de tempo al tempo vi ankoraŭ devas forigi ion, plejparte iom da kruda aŭ meza informo. Surbaze de eksvalidiĝo, ni kreis mekanismon por purigi la stokadon de malnoviĝintaj datumoj.

Ni ankaŭ komprenas, ke baldaŭ aŭ malfrue venos situacio, kiam ne estos sufiĉe da spaco por konservi datumojn en memoro, sed tamen la datumoj devas esti konservitaj. Por ĉi tiuj celoj, ni baldaŭ faros disko-stokadon.

konkludo

Ni komencis kun la tasko ŝargi datumojn en ununuran modelon kaj pasigis tri monatojn disvolvi ĝin. Ni havis ses datumprovizsistemojn. La tuta transformkodo en ununuran modelon estas ĉirkaŭ 30 mil linioj en Lua. Kaj la plej granda parto de la laboro estas ankoraŭ antaŭen. Foje mankas motivado de najbaraj teamoj, kaj estas multaj cirkonstancoj, kiuj malfaciligas la laboron. Se vi iam alfrontas similan taskon, tiam multigu la tempon, kiu ŝajnas al vi normala por ĝia efektivigo, per tri, aŭ eĉ kvar.

Memoru ankaŭ, ke ekzistantaj problemoj en komercaj procezoj ne povas esti solvitaj per nova DBMS, eĉ tre produktiva. Kion mi volas diri? Komence de nia projekto, ni kreis la impreson inter klientoj, ke nun ni alportos novan rapidan datumbazon, kaj ni vivos! La procezoj iros pli rapide, ĉio estos en ordo. Fakte, teknologio ne solvas la problemojn kiujn havas komercaj procezoj, ĉar komercaj procezoj estas homoj. Kaj vi devas labori kun homoj, ne kun teknologio.

Test-movita evoluo povas esti dolora kaj tempopostula en la fruaj stadioj. Sed la pozitiva efiko de ĝi estos rimarkebla eĉ baldaŭ, kiam vi ne bezonas fari ion ajn por fari regrestestojn.

Estas ege grave fari ŝarĝtestadon en ĉiuj stadioj de evoluo. Ju pli frue vi rimarkos iun difekton en la arkitekturo, des pli facile estos ripari ĝin, kio ŝparos al vi multan tempon en la estonteco.

Estas nenio malbona kun Lua. Ĉiu povas lerni skribi en ĝi: Java-programisto, JavaScript-programisto, Python-programisto, front-end aŭ back-end. Eĉ niaj analizistoj skribas sur ĝi.

Kiam ni parolas pri tio, ke ni ne havas SQL, tio teruras homojn. “Kiel vi ricevas datumojn sen SQL? Ĉu tio eblas? Certe. En OLTP klassistemo, SQL ne estas bezonata. Estas alternativo en la formo de ia lingvo, kiu tuj resendas vin al dokument-orientita vidpunkto. Ekzemple, GraphQL. Kaj ekzistas alternativo en la formo de distribuita komputado.

Se vi komprenas, ke vi devos skali, tiam desegni vian solvon sur Tarantool tiel, ke ĝi povas funkcii paralele sur dekoj da Tarantool-instancoj. Se vi ne faras tion, ĝi estos malfacila kaj dolora poste, ĉar Tarantool povas efike uzi nur unu procesoran kernon.

fonto: www.habr.com