"Our Secret Universe: The Hidden Life of the Cell" filmeko argazkia

Inbertsioen negozioa banku-munduko arlorik konplexuenetako bat da, maileguak, zorpetzeak eta gordailuak ez ezik, baloreak, monetak, lehengaiak, eratorriak eta era guztietako konplexutasunak baitaude produktu egituratuen moduan.

Azkenaldian, biztanleriaren finantza-alfabetizazioa areagotu egin da. Gero eta jende gehiago ari da parte hartzen balore merkatuetan negoziatzen. Inbertsio kontu indibidualak duela ez asko agertu ziren. Balore-merkatuetan negoziatzeko eta zerga-kenkariak jasotzeko edo zergak ordaintzea saihesteko aukera ematen dute. Eta guregana etortzen diren bezero guztiek beren zorroa kudeatu eta txostenak denbora errealean ikusi nahi dituzte. Gainera, gehienetan zorro hau produktu anitzekoa da, hau da, pertsonak negozio-lerro ezberdinetako bezeroak dira.

Gainera, erregulatzaileen beharrak, errusiarrak zein atzerrikoak, gero eta handiagoak dira.

Egungo beharrei erantzuteko eta etorkizuneko bertsio berritzeko oinarriak ezartzeko, Tarantool-en oinarritutako inbertsio negozio-nukleoa garatu dugu.

Estatistika batzuk. Alfa-Bank-en inbertsio-negozioak bitartekaritza-zerbitzuak eskaintzen ditu pertsona fisiko eta juridikoentzat, balore-merkatu ezberdinetan negoziatzeko aukera eskaintzeko, baloreak biltegiratzeko gordailu-zerbitzuak, kapital pribatua eta handia duten pertsonentzako konfiantza-kudeaketa zerbitzuak, beste enpresa batzuentzako baloreak jaulkitzeko zerbitzuak. . Alfa-Bank-en inbertsio-negozioak segundoko 3 mila aurrekontu baino gehiago biltzen ditu, merkataritza-plataforma ezberdinetatik deskargatzen direnak. Lanaldian, 300 mila transakzio baino gehiago egiten dira merkatuetan bankuaren edo bere bezeroen izenean. Gehienez 5 mila agindu exekutatu segundoko kanpoko eta barneko plataformetan. Aldi berean, bezero guztiek, barnekoak zein kanpokoak, euren posizioak denbora errealean ikusi nahi dituzte.

historiaurrea

2000ko hamarkadaren hasieratik, gure inbertsio-negozio-arloak modu independentean garatu ziren: truke-negozioa, bitartekaritza-zerbitzuak, moneta-negozioa, baloreen eta hainbat eratorritako burtsan merkataritza. Ondorioz, putzu funtzionalen tranpan erori gara. Zer da hau? Negozio-lerro bakoitzak bere sistemak ditu elkarren funtzioak bikoizten dituztenak. Sistema bakoitzak bere datu-eredua du, nahiz eta kontzeptu berdinekin funtzionatzen duten: transakzioak, tresnak, kontraparteak, aurrekontuak, etab. Eta sistema bakoitzak modu independentean eboluzionatu zuenez, teknologia-zoo anitza sortu zen.

Gainera, sistemen kode-oinarria nahiko zaharkituta dago jada, produktu batzuk 1990eko hamarkadaren erdialdean sortu zirelako. Eta arlo batzuetan horrek garapen prozesua moteldu zuen, eta errendimendu arazoak egon ziren.

Irtenbide berri baten baldintzak

Enpresak konturatu dira eraldaketa teknologikoa ezinbestekoa dela garapen gehiagorako. Zereginak eman zizkiguten:

1. Bildu negozio-datu guztiak biltegiratze bakar eta azkar batean eta datu-eredu bakarrean.
2. Ez dugu informazio hori galdu edo aldatu behar.
3. Datuak bertsionatu behar dira, edozein unetan erregulatzaileak aurreko urteetako estatistikak eskatu ditzakeelako.
4. Ez dugu DBMS berri eta modan ekarri behar, baizik eta negozio-arazoak konpontzeko plataforma bat sortu behar.

Gainera, gure arkitektoek beren baldintzak ezartzen dituzte:

1. Irtenbide berriak enpresa mailakoa izan behar du, hau da, dagoeneko enpresa handi batzuetan probatu behar da.
2. Irtenbidearen funtzionamendu moduak misio kritikoa izan behar du. Horrek esan nahi du hainbat datu-zentrotan aldi berean egon behar dugula eta datu-zentro baten etenalditik lasai biziraun behar dugula.
3. Sistemak horizontalki eskalagarria izan behar du. Kontua da gure egungo sistema guztiak bertikalki eskalagarriak direla eta dagoeneko sabaia jotzen ari garela hardwarearen potentziaren hazkunde txikia dela eta. Hori dela eta, bizirauteko sistema horizontalki eskalagarria izan behar dugun momentua iritsi da.
4. Besteak beste, konponbideak merkea izan behar zuela esan ziguten.

Ibilbide estandarra jarraitu genuen: baldintzak formulatu eta erosketa sailarekin harremanetan jarri ginen. Hortik jaso genuen, oro har, guretzat horretarako prest dauden enpresen zerrenda. Arazoaren berri eman genion guztiei, eta haietako seiren konponbideen balorazioa jaso genuen.

Bankuan ez dugu inoren hitza hartzen; dena probatzea gustatzen zaigu. Beraz, gure lizitazio-lehiaketako derrigorrezko baldintza karga-probak gainditzea zen. Karga-probaren zereginak formulatu genituen, eta sei enpresetatik hiruk dagoeneko onartu dute memoria barneko teknologietan oinarritutako soluzio prototipo bat ezartzea berau probatzeko.

Ez dizut esango nola probatu genuen dena eta zenbat denbora behar izan genuen, laburbilduko dut: karga probetan errendimendurik onena Mail.ru Taldeko garapen taldeko Tarantool-en oinarritutako soluzio prototipo batek erakutsi zuen. Hitzarmen bat sinatu eta garatzen hasi ginen. Mail.ru Taldeko lau pertsona zeuden, eta Alfa-Bankeko hiru garatzaile, hiru sistema-analista, soluzio-arkitekto bat, produktu-jabe bat eta Scrum master bat.

Jarraian, gure sistema nola hazi zen, nola eboluzionatu zuen, zer egin genuen eta zergatik zehazki hau kontatuko dizuet.

diseinua

Geure buruari egin genion lehenengo galdera gure egungo sistemetatik datuak nola lortu ziren. HTTP nahiko egokia zela erabaki genuen, egungo sistema guztiak elkarren artean komunikatzen direlako XML edo JSON HTTP bidez bidaliz.

Tarantool-en integratutako HTTP zerbitzaria erabiltzen dugu, ez dugulako SSL saioak amaitu behar, eta bere errendimendua nahikoa da guretzat.

Esan dudan bezala, gure sistema guztiak datu-eredu ezberdinetan bizi dira, eta sarreran objektua geuk deskribatzen dugun eredura eraman behar dugu. Datuak eraldatzeko aukera ematen zuen hizkuntza behar zen. Lua ezinbestekoa aukeratu dugu. Datu-bihurketa-kode guztiak sandbox batean exekutatzen ditugu; leku segurua da eta hortik kanpo exekutatzen ari den kodea ez da. Horretarako, behar den kodea kargatu besterik ez dugu egiten, ezer blokeatu edo jaregin ezin duten funtzioekin ingurune bat sortuz.

Bihurtu ondoren, datuak sortzen ari garen ereduarekin bat datozen egiaztatu behar da. Luzaroan eztabaidatu genuen zein izan behar zen eredua eta zein hizkuntza erabili hura deskribatzeko. Apache Avro aukeratu dugu hizkuntza sinplea delako eta Tarantool-en laguntza duelako. Ereduaren eta kode pertsonalizatuaren bertsio berriak egunean hainbat aldiz martxan jar daitezke, kargapean edo gabe, eguneko edozein unetan, eta aldaketetara oso azkar moldatzen dira.

Egiaztatu ondoren, datuak gorde behar dira. Hau vshard erabiliz egiten dugu (zatiren erreplikak geo-sakabanatutakoak ditugu).

Gainera, berezitasuna halakoa da, non datuak bidaltzen dizkiguten sistema gehienei ez zaiela axola jaso ditugun ala ez. Horregatik, hasiera-hasieratik ezarri genuen konponketa ilara bat. Zer da hau? Arrazoiren batengatik objektu batek ez badu datuen eraldaketarik edo egiaztapenik egiten, hala ere, jaso izana berresten dugu, baina aldi berean objektua konponketa-ilaran gordetzen dugu. Koherentea da eta negozioaren datu biltegi nagusian kokatzen da. Berehala idatzi genuen administratzaile interfaze bat, hainbat metrika eta alerta. Ondorioz, ez dugu daturik galtzen. Iturburuan zerbait aldatu bada ere, datu-eredua aldatu bada, berehala detektatuko dugu eta moldatuko gara.

Orain gordetako datuak nola berreskuratu ikasi behar duzu. Arretaz aztertu ditugu gure sistemak eta ikusi dugu Java eta Oracle-ren pila klasikoak nahitaez duela datuak erlazionaletatik objektu bihurtzen dituen ORM motaren bat. Beraz, zergatik ez berehala objektuak ematen grafio moduan sistemei? Beraz, pozik hartu genuen GraphQL, gure behar guztiak betetzen zituena. Datuak grafiko moduan jasotzeko eta une honetan behar duzuna bakarrik ateratzeko aukera ematen du. Nahiz eta malgutasun handiz bertsiotu dezakezu APIa.

Ia berehala konturatu ginen ateratzen ari ginen datuak nahikoak ez zirela. Ereduan objektuekin lotu daitezkeen funtzioak sortu ditugu, funtsean, kalkulatutako eremuak. Hau da, eremuari funtzio jakin bat eransten diogu, eta horrek, adibidez, aurrekontuaren batez besteko prezioa kalkulatzen du. Eta datuak eskatzen dituen kanpoko kontsumitzaileak ez daki ere eremu kalkulatua denik.

Autentifikazio sistema bat ezarri du.

Orduan ohartu ginen hainbat rol kristalizatu zirela gure erabakian. Rol bat funtzioen agregatzaile moduko bat da. Normalean, rolek ekipamenduen erabilera profil desberdinak dituzte:

• T-Connect: sarrerako konexioak kudeatzen ditu, CPU mugatua, memoria-kontsumo txikia, estaturik gabekoa.
• IB-Core: Tarantool protokoloaren bidez jasotzen dituen datuak eraldatzen ditu, hau da, taulekin funtzionatzen du. Gainera, ez du egoera gordetzen eta eskalagarria da.
• Biltegiratzea: datuak soilik gordetzen ditu, ez du inolako logikarik erabiltzen. Rol honek interfaze errazenak inplementatzen ditu. Eskalagarria vshard-i esker.

Hau da, rolak erabiliz, klusterraren zati desberdinak elkarrengandik desakoplatu ditugu, eta horiek elkarrengandik independentean eskala daitezke.

Beraz, datu-fluxu transakzional asinkronoaren grabaketa eta konponketa-ilara bat sortu dugu administrazio-interfaze batekin. Grabaketa asinkronoa da negozioaren ikuspuntutik: datuak geure buruari idaztea ziurtatzen badugu, edozein lekutan, baieztatu egingo dugu. Berresten ez bada, zerbait gaizki joan da eta datuak bidali behar dira. Hau grabaketa asinkronoa da.

Testing

Proiektuaren hasiera-hasieratik erabaki genuen test driven garapena ezartzen saiatuko ginela. Unitate-probak Luan idazten ditugu tarantool/tap markoa erabiliz, eta integrazio-probak Python-en pytest markoa erabiliz. Aldi berean, garatzaileek eta analistek integrazio-probak idazten parte hartzen dugu.

Nola erabiltzen dugu proba gidatutako garapena?

Ezaugarri berriren bat nahi badugu, proba bat idazten saiatzen gara lehenengo. Akats bat deskubritzen dugunean, proba bat idazten dugula ziurtatzen dugu lehenik, eta gero bakarrik konpondu. Hasieran zaila da horrela lan egitea, langileen aldetik gaizki-ulertua dago, baita sabotajea ere: «Konpon dezagun orain azkar, egin dezagun zerbait berria, eta gero probez estali». "Gero" hau bakarrik ez da ia inoiz etortzen.

Hori dela eta, zure burua behartu behar duzu probak idaztera lehenik eta besteei eskatu. Sinetsi iezadazu, probak bultzatutako garapenak onurak ekartzen ditu epe laburrean ere. Zure bizitza errazagoa bihurtu dela sentituko duzu. Kodearen % 99 orain probek estalita dagoela uste dugu. Asko dirudi, baina ez dugu arazorik: probak konpromezu guztietan exekutatzen dira.

Hala ere, gehien gustatzen zaiguna karga-probak dira; garrantzitsuena deritzogu eta aldizka egiten ditugu.

Istoriotxo bat kontatuko dizut lehen bertsioetako baten karga probaren lehen fasea nola egin genuen. Sistema garatzailearen ordenagailu eramangarrian instalatu genuen, karga piztu genuen eta segundoko 4 mila transakzio jaso genituen. Emaitza ona ordenagailu eramangarri baterako. Lau zerbitzariko karga-banku birtualean instalatu genuen, ekoizpenean baino ahulagoa. Gutxienera zabalduta. Exekutatzen dugu, eta ordenagailu eramangarri batean baino emaitza okerragoa lortzen dugu hari batean. Shock edukia.

Oso triste geunden. Zerbitzariaren kargari erreparatzen diogu, baina inaktibo daudela ematen du.

Garatzaileei deitzen diegu, eta haiek azaltzen digute, Java mundutik datozen pertsonei, Tarantool hari bakarrekoa dela. Kargapean prozesadore-nukleo batek bakarrik erabil dezake eraginkortasunez. Ondoren, Tarantool-en instantzia kopuru handiena zabaldu genuen zerbitzari bakoitzean, karga piztu genuen eta 14,5 mila transakzio jaso genituen segundoko.

Utzidazu berriro azaltzen. Baliabideak modu ezberdinean erabiltzen dituzten rolen zatiketa dela eta, konexioak prozesatzeko eta datuen eraldaketaz arduratzen diren gure rolek prozesadorea soilik kargatzen zuten, eta kargarekiko zorrozki proportzionalak.

Kasu honetan, memoria sarrerako konexioak eta aldi baterako objektuak prozesatzeko soilik erabiltzen zen.

Aitzitik, biltegiratze zerbitzarietan, prozesadorearen karga handitu egin da, baina konexioak prozesatzen dituzten zerbitzarietan baino askoz motelagoa.

Eta memoria-kontsumoa hazi zen kargatutako datu kopuruaren proportzio zuzenean.

Zerbitzuak

Gure produktu berria aplikazio-plataforma gisa bereziki garatzeko, bertan zerbitzuak eta liburutegiak zabaltzeko osagai bat sortu dugu.

Zerbitzuak ez dira eremu batzuetan funtzionatzen duten kode txikiak soilik. Nahiko egitura handiak eta konplexuak izan daitezke, kluster baten parte direnak, erreferentzia-datuak egiaztatu, negozio-logika exekutatu eta erantzunak itzultzen dituztenak. Zerbitzu-eskema GraphQLra ere esportatzen dugu, eta kontsumitzaileak datuetarako sarbide unibertsal bat jasotzen du, eredu osoan zehar introspekzioarekin. Oso erosoa da.

Zerbitzuek funtzio askoz gehiago dituztenez, maiz erabiltzen den kodea mugituko dugun liburutegiak egon behar zirela erabaki genuen. Ingurune segurura gehitu ditugu, aldez aurretik ezer hausten ez digula egiaztatuta. Eta orain funtzioei ingurune osagarriak esleitu diezazkiekegu liburutegi moduan.

Biltegiratzeko ez ezik, informatiketarako ere plataforma bat izan nahi genuen. Eta jadanik erreplika eta zati mordo bat geneukanez, konputazio banatu moduko bat inplementatu genuen eta map reduce deitu genion, jatorrizko map reduceraren antzekoa izan zelako.

Sistema zaharrak

Gure ondareko sistema guztiek ezin gaituzte HTTP bidez deitu eta GraphQL erabili, nahiz eta protokoloa onartzen duten. Hori dela eta, sistema horietan datuak erreplikatzea ahalbidetzen duen mekanismo bat sortu dugu.

Zerbait aldatzen badigugu, abiarazle bakarrak Biltegiratze rolean abiarazten dira eta aldaketak dituen mezua prozesatzeko ilaran amaitzen da. Kanpoko sistema batera bidaltzen da erreplikatzaile rol bereizia erabiliz. Rol honek ez du egoera gordetzen.

Hobekuntza berriak

Gogoratzen duzuenez, negozioaren ikuspuntutik, grabaketa asinkronoa egin genuen. Baina orduan konturatu ziren ez zela nahikoa izango, sistema-klase bat dagoelako operazioaren egoerari buruzko erantzuna berehala jaso behar duena. Beraz, gure GraphQL zabaldu genuen eta mutazioak gehitu genituen. Organikoki sartzen dira datuekin lan egiteko dagoen paradigman. Guretzat, hau irakurtzeko eta idazteko puntu bakarra da beste sistema-klase baterako.

Gainera, konturatu ginen zerbitzuak bakarrik ez zirela nahikoa izango guretzat, nahiko txosten astunak baitaude egunean, astean, hilabetean behin eraiki behar direnak. Horrek denbora luzea izan dezake, eta txostenek Tarantool-en gertaeren begizta ere blokeatu dezakete. Horregatik, rol bereiziak sortu ditugu: programatzailea eta korrikalaria. Korrikalariek ez dute egoera gordetzen. Hegan kalkulatu ezin ditugun lan astunak egiten dituzte. Eta planifikatzailearen rolak zeregin horien abiarazte-egutegia kontrolatzen du, konfigurazioan azaltzen dena. Zereginak beraiek negozioaren datuen leku berean gordetzen dira. Une egokia iristen denean, programatzaileak zeregina hartzen du, korrikalari bati ematen dio, eta honek zenbatu eta emaitza gordetzen du.

Zeregin guztiak ez dira programazio batean exekutatu behar. Txosten batzuk eskatuta irakurri behar dira. Baldintza hori iritsi bezain laster, zeregin bat sortzen da hareatzan eta korrikalariari bidaltzen zaio exekutatzeko. Denbora pixka bat igaro ondoren, erabiltzaileak erantzun asinkrono bat jasotzen du dena kalkulatuta dagoela eta txostena prest dagoela.

Hasieran, datu guztiak gordetzeko, bertsionatu eta ez ezabatzeko paradigmari eutsi genion. Baina bizitzan, noizean behin oraindik zerbait ezabatu behar duzu, gehienetan informazio gordina edo tarteko. Iraungitzean oinarrituta, biltegiratzea datu zaharkituetatik garbitzeko mekanismo bat sortu dugu.

Ulertzen dugu, gainera, lehenago edo beranduago, datuak memorian gordetzeko leku nahikorik egongo ez den egoera bat etorriko dela, baina, hala ere, datuak gorde behar dira. Helburu horietarako, laster disko biltegiratzea egingo dugu.

Ondorioa

Datuak eredu bakarrean kargatzeko zereginarekin hasi eta hiru hilabete eman genituen garatzen. Datuak hornitzeko sei sistema genituen. Eraldaketa-kode osoa eredu bakarrean 30 mila lerro ingurukoa da Luan. Eta lan gehiena aurretik dago oraindik. Batzuetan aldameneko taldeen motibazio falta izaten da, eta asko dira lana zailtzen duten egoerak. Inoiz antzeko zeregin bati aurre egiten bazaizu, biderkatu ezazu hori gauzatzeko normala iruditzen zaizun denbora hiru, edo are lau.

Era berean, gogoratu negozio-prozesuetan dauden arazoak ezin direla konpondu DBMS berri bat erabiliz, nahiz eta oso emankorra izan. Zer esan nahi dut? Gure proiektuaren hasieran, bezeroen artean inpresioa sortu genuen orain datu-base azkar berri bat ekarriko dugula eta biziko garela! Prozesuak azkarrago joango dira, dena ondo egongo da. Izan ere, teknologiak ez ditu negozio-prozesuek dituzten arazoak konpontzen, negozio-prozesuak pertsonak direlako. Eta jendearekin lan egin behar duzu, ez teknologiarekin.

Probak bultzatutako garapena mingarria eta denbora luzea izan daiteke hasierako etapetan. Baina horren eragin positiboa nabaria izango da epe laburrean ere, erregresio probak egiteko ezer egin behar ez duzunean.

Oso garrantzitsua da karga-probak egitea garapen-fase guztietan. Zenbat eta lehenago nabaritu arkitekturan akatsen bat, orduan eta errazagoa izango da konpontzea, eta horrek denbora asko aurreztuko dizu etorkizunean.

Lua-rekin ez dago gaizki. Edonork ikas dezake bertan idazten: Java garatzailea, JavaScript garatzailea, Python garatzailea, frontend edo backend. Gure analistek ere bertan idazten dute.

SQL ez dugula hitz egiten dugunean, jendea izutzen du. "Nola lortzen dituzu datuak SQL gabe? Hori posible al da? Zalantzarik gabe. OLTP klase-sistema batean, SQL ez da beharrezkoa. Badago alternatiba bat dokumentuetara zuzendutako ikuspegira berehala itzultzen zaituen hizkuntza mota baten moduan. Adibidez, GraphQL. Eta alternatiba bat dago konputazio banatuaren moduan.

Eskalatu beharko duzula ulertzen baduzu, diseina ezazu zure irtenbidea Tarantool-en, Tarantool-en dozenaka instantziatan paraleloan exekutatzeko moduan. Hau egiten ez baduzu, zaila eta mingarria izango da geroago, Tarantool-ek prozesadore-nukleo bakarra bakarrik erabil dezake eta eraginkortasunez.

Iturria: www.habr.com