Masih tina pilem "Rusiah Semesta Urang: Kahirupan Hidden of the Cell"

Usaha investasi mangrupikeun salah sahiji daérah anu paling kompleks di dunya perbankan, sabab henteu ngan ukur pinjaman, injeuman sareng deposit, tapi ogé sekuritas, mata uang, komoditas, turunan sareng sagala rupa pajeulitna dina bentuk produk terstruktur.

Anyar-anyar ieu, urang ningali paningkatan literasi kauangan penduduk. Beuki loba jalma anu kalibet dina dagang di pasar sekuritas. Rekening investasi individu mucunghul teu jadi lila pisan. Aranjeunna ngidinan Anjeun pikeun dagangan pasar jaminan na boh nampi deductions pajeg atawa ulah mayar pajeg. Sareng sadaya klien anu sumping ka kami hoyong ngatur portopolio sareng ningali ngalaporkeun sacara real waktos. Leuwih ti éta, paling sering portopolio ieu multi-produk, nyaeta, jalma anu klien tina sagala rupa garis bisnis.

Salaku tambahan, kabutuhan régulator, boh Rusia sareng asing, ngembang.

Pikeun minuhan kabutuhan ayeuna jeung iklas yayasan pikeun upgrades hareup, kami geus ngembangkeun hiji inti bisnis investasi dumasar kana Tarantool.

Sababaraha statistik. Bisnis investasi Alfa-Bank nyadiakeun ladenan brokerage pikeun individu jeung badan hukum pikeun nyadiakeun kasempetan pikeun dagang di sagala rupa pasar securities, jasa depository pikeun neundeun jaminan, jasa manajemén trust pikeun individu jeung modal swasta jeung gede, ladenan pikeun ngaluarkeun sekuritas keur pausahaan séjén. . Usaha investasi Alfa-Bank kalebet langkung ti 3 rébu tanda petik per detik, anu diunduh tina sababaraha platform dagang. Dina dinten kerja, langkung ti 300 rébu transaksi disimpulkeun dina pasar atas nama bank atanapi klienna. Nepi ka 5 rébu palaksanaan pesenan per detik lumangsung dina platform éksternal sareng internal. Dina waktos anu sami, sadaya klien, boh internal sareng eksternal, hoyong ningali posisina sacara real waktos.

prasajarah

Ti mimiti taun 2000-an, wewengkon bisnis investasi urang dimekarkeun sacara mandiri: dagang bursa, jasa brokerage, dagang mata uang, over-the-counter dagang di securities sarta sagala rupa turunan. Hasilna, urang geus fallen kana bubu fungsi sumur. Naon éta? Unggal garis bisnis gaduh sistem sorangan anu duplikat fungsi masing-masing. Unggal sistem boga model data sorangan, sanajan aranjeunna beroperasi kalawan konsep sarua: transaksi, instrumen, counterparties, tanda petik, jeung saterusna. Sareng nalika unggal sistem mekar sacara mandiri, téknologi kebon binatang anu rupa-rupa muncul.

Sajaba ti éta, dasar kode tina sistem geus rada luntur, sabab sababaraha produk asalna dina pertengahan 1990s. Sareng di sababaraha daérah ieu ngalambatkeun prosés pangwangunan, sareng aya masalah kinerja.

Sarat pikeun solusi anyar

Usaha parantos sadar yén transformasi téknologi penting pikeun pangwangunan salajengna. Kami dibéré tugas:

1. Kumpulkeun sadaya data bisnis dina hiji panyimpenan gancang sareng dina modél data tunggal.
2. Urang teu kudu leungit atawa ngarobah informasi ieu.
3. Ieu diperlukeun pikeun versi data, sabab iraha wae regulator bisa ménta statistik keur taun saméméhna.
4. Urang teu kudu ngan mawa sababaraha anyar, fashionable DBMS, tapi nyieun platform pikeun ngarengsekeun masalah bisnis.

Salaku tambahan, arsiték kami nyetél kaayaan sorangan:

1. Solusi anyar kedah janten kelas perusahaan, nyaéta, éta kedah diuji di sababaraha perusahaan ageung.
2. Modeu operasi solusi kedah kritis misi. Ieu ngandung harti yén urang kudu hadir dina sababaraha puseur data sakaligus tur tenang salamet outage sahiji puseur data.
3. Sistim nu kudu horizontal scalable. Kanyataan yén sadaya sistem urang ayeuna ngan ukur tiasa skala vertikal, sareng kami parantos pencét siling kusabab pertumbuhan kakuatan hardware anu rendah. Ku alatan éta, momen geus datangna nalika urang kudu boga sistem horizontal scalable pikeun salamet.
4. Diantara hal séjén, kami ngawartoskeun yen solusi kedah mirah.

Kami nuturkeun jalur standar: kami ngarumuskeun syarat sareng ngahubungi departemén pameseran. Ti dinya kami nampi daptar perusahaan anu, sacara umum, siap ngalakukeun ieu pikeun kami. Urang ngawartoskeun dulur ngeunaan masalah, sarta narima hiji assessment sahiji solusi ti genep di antarana.

Di bank, kami henteu nyandak kecap saha waé pikeun éta; kami resep nguji sadayana nyalira. Ku alatan éta, kaayaan wajib kompetisi lembut urang nya éta lulus tés beban. Kami ngarumuskeun tugas uji beban, sareng tilu tina genep perusahaan parantos sapuk pikeun nerapkeun solusi prototipe dumasar kana téknologi mémori kalayan biaya sorangan pikeun nguji éta.

Kuring moal ngabejaan ka maneh kumaha urang nguji sagalana jeung sabaraha lila waktu nu diperlukeun, kuring ngan bakal nyimpulkeun: kinerja pangalusna dina tés beban ditémbongkeun ku solusi prototipe dumasar kana Tarantool ti tim ngembangkeun Mail.ru Grup. Urang nandatanganan hiji perjangjian sarta mimiti ngembangkeun. Aya opat jalma ti Mail.ru Grup, sareng ti Alfa-Bank aya tilu pamekar, tilu analis sistem, arsiték solusi, pamilik produk sareng master Scrum.

Salajengna, kuring bakal nyarioskeun ka anjeun ngeunaan kumaha sistem kami tumbuh, kumaha éta mekar, naon anu urang laksanakeun sareng kunaon persisna ieu.

rarancang

Patarosan kahiji anu urang naroskeun ka diri urang sorangan nyaéta kumaha carana kéngingkeun data tina sistem urang ayeuna. Urang mutuskeun yén HTTP éta rada cocog pikeun urang, sabab sakabeh sistem ayeuna komunikasi saling ku ngirim XML atanapi JSON ngaliwatan HTTP.

Kami nganggo server HTTP anu diwangun kana Tarantool sabab kami henteu kedah ngeureunkeun sesi SSL, sareng prestasina cekap pikeun kami.

Sakumaha anu kuring parantos nyarios, sadaya sistem urang hirup dina modél data anu béda-béda, sareng dina inputna urang kedah nyangking obyék kana modél anu urang ngajelaskeun diri urang sorangan. Diperlukeun basa anu ngamungkinkeun data dirobah. Kami milih Lua imperatif. Kami ngajalankeun sadaya kode konversi data dina kotak pasir - ieu mangrupikeun tempat anu aman dimana kodeu jalan henteu angkat. Jang ngalampahkeun ieu, urang ngan loadstring kode diperlukeun, nyieun hiji lingkungan jeung fungsi nu teu bisa meungpeuk atawa leupaskeun nanaon.

Saatos konvérsi, data kedah dipariksa pikeun patuh kana modél anu urang ciptakeun. Urang bahas pikeun lila naon model kudu jeung naon basa dipaké pikeun ngajelaskeun eta. Kami milih Apache Avro sabab basana basajan sareng gaduh dukungan ti Tarantool. Vérsi anyar model jeung kode custom bisa nempatkeun kana operasi sababaraha kali sapoé, sanajan dina beban atawa tanpa, iraha wae dina sapoe, sarta adaptasi jeung parobahan pisan gancang.

Saatos verifikasi, data kedah disimpen. Urang ngalakukeun ieu ngagunakeun vshard (urang gaduh réplika geo-dispersed of shards).

Sumawona, spésifisitas sapertos kitu seueur sistem anu ngirim data ka kami henteu paduli naha kami nampi atanapi henteu. Éta sababna urang ngalaksanakeun antrian perbaikan ti mimiti. Naon éta? Mun keur sababaraha alesan obyék teu ngalaman transformasi data atawa verifikasi, urang masih mastikeun resi, tapi dina waktos anu sareng nyimpen objék dina antrian perbaikan. Éta konsisten sareng ayana di gudang data bisnis utama. Kami langsung nyerat antarmuka administrator pikeun éta, rupa-rupa métrik sareng panggeuing. Hasilna, urang teu leungit data. Sanaos aya anu robih dina sumberna, upami modél data parantos robih, kami bakal langsung ngadeteksi sareng tiasa adaptasi.

Ayeuna anjeun kedah diajar kumaha nyandak data anu disimpen. Urang taliti dianalisis sistem kami sarta nempo yén tumpukan Palasik of Java jeung Oracle merta ngandung sababaraha jenis ORM nu ngarobah data tina relational ka objék. Janten naha henteu langsung masihan obyék kana sistem dina bentuk grafik? Ku kituna kami happily diadopsi GraphQL, nu minuhan sagala kaperluan urang. Éta ngamungkinkeun anjeun nampi data dina bentuk grafik sareng ngan ukur tarik anu anjeun peryogikeun ayeuna. Anjeun malah tiasa versi API kalawan cukup loba kalenturan.

Ampir langsung kami sadar yén data anu kami ékstrak henteu cekap. Urang dijieun fungsi nu bisa numbu ka objék dina modél - dasarna, widang diitung. Hartina, urang ngagantelkeun hiji fungsi nu tangtu ka sawah, nu, contona, Etang harga cutatan rata. Sareng konsumen éksternal anu nyuhunkeun datana henteu terang yén ieu mangrupikeun lapangan anu diitung.

Dilaksanakeun sistem auténtikasi.

Teras we noticed nu sababaraha kalungguhan crystallized dina kaputusan urang. Peran mangrupikeun jinis agrégator fungsi. Ilaharna, peran gaduh profil pamakean alat anu béda:

• T-Connect: handles sambungan asup, CPU kawates, konsumsi memori low, stateless.
• IB-Core: transforms data eta narima via protokol Tarantool, nyaeta, eta beroperasi kalawan tabel. Ogé teu nyimpen kaayaan sarta scalable.
• Panyimpenan: ngan ukur nyimpen data, henteu nganggo logika naon waé. Peran ieu ngalaksanakeun antarmuka pangbasajanna. Scalable berkat vshard.

Hartina, ngagunakeun peran, urang decoupled bagian béda tina klaster ti silih, nu bisa diskalakeun bebas unggal lianna.

Janten, kami parantos nyiptakeun rékaman aliran data transaksional Asynchronous sareng antrian perbaikan sareng antarmuka admin. Rekamanna henteu sinkron tina sudut pandang bisnis: upami urang dijamin nyerat data ka diri urang sorangan, dimana waé, maka kami bakal mastikeun éta. Upami éta henteu dikonfirmasi, maka aya anu salah sareng data kedah dikirim. Ieu rekaman asynchronous.

Tés

Ti mimiti proyek, urang mutuskeun yén urang bakal coba pikeun nerapkeun test driven ngembangkeun. Kami nyerat unit tés dina Lua nganggo kerangka tarantool / ketok, sareng tés integrasi dina Python nganggo kerangka pytest. Dina waktos anu sami, urang ngalibetkeun pamekar sareng analis dina nyerat tés integrasi.

Kumaha urang ngagunakeun ngembangkeun test driven?

Upami urang hoyong sababaraha fitur énggal, urang nyobian nyerat tés heula. Nalika urang mendakan bug, urang pastikeun nyerat tés heula, teras ngalereskeunana. Mimitina sesah damel sapertos kieu, aya salah paham di pihak karyawan, bahkan sabotase: "Hayu urang gancang ngalereskeun ayeuna, laksanakeun anu énggal, teras tutup ku tés." Ngan ieu "engké" ampir pernah datang.

Ku alatan éta, anjeun kudu maksa diri nulis tés munggaran tur ménta batur pikeun ngalakukeunana. Percanten ka kuring, pamekaran anu didorong ku uji mawa kauntungan bahkan dina jangka pondok. Anjeun bakal ngarasa yén hirup anjeun geus jadi leuwih gampang. Kami ngarasa yén 99% kode ayeuna katutupan ku tés. Ieu sigana pisan, tapi kami henteu ngagaduhan masalah: tés dijalankeun dina unggal komitmen.

Nanging, anu paling kami pikahoyong nyaéta uji beban; kami nganggap éta anu paling penting sareng ngalaksanakeunana rutin.

Kuring gé ngabejaan Anjeun carita saeutik ngeunaan kumaha urang dilumangsungkeun tahap mimiti nguji beban salah sahiji versi munggaran. Kami masang sistem dina laptop pamekar, hurungkeun beban sareng nampi 4 rébu transaksi per detik. Hasilna alus pikeun laptop. Kami dipasang dina bangku beban virtual tina opat server, langkung lemah tibatan produksi. Dipasangkeun ka minimum. Urang ngajalankeun eta, sarta kami meunang hasilna leuwih goreng ti on laptop dina hiji thread. Eusi ngajempolan.

Kami sedih pisan. Urang tingali dina beban server, tapi tétéla aranjeunna dianggurkeun.

Urang nelepon pamekar, sarta aranjeunna ngajelaskeun ka urang, jalma anu asalna ti dunya Java, yén Tarantool téh single-threaded. Ieu ngan bisa éféktif dipaké ku hiji inti processor dina beban. Teras we deployed jumlah maksimum mungkin tina instansi Tarantool dina unggal server, dihurungkeun beban sarta geus narima 14,5 sarébu transaksi per detik.

Hayu atuh ngajelaskeun deui. Alatan division kana kalungguhan anu ngagunakeun sumberdaya béda, kalungguhan urang jawab ngolah sambungan jeung transformasi data dimuat ukur processor, sarta mastikeun sabanding jeung beban.

Dina hal ieu, mémori ngan dipaké pikeun ngolah sambungan asup jeung objék samentara.

Sabalikna, dina server panyimpen, beban prosesor ningkat, tapi langkung laun tibatan server anu ngolah sambungan.

Sareng konsumsi mémori ningkat saimbang langsung kana jumlah data anu dimuat.

Jasa

Pikeun ngembangkeun produk anyar urang sacara khusus salaku platform aplikasi, kami nyiptakeun komponén pikeun nyebarkeun jasa sareng perpustakaan di dinya.

Jasa henteu ngan potongan leutik kode anu beroperasi dina sababaraha widang. Éta tiasa janten struktur anu cukup ageung sareng kompleks anu bagian tina klaster, pariksa data rujukan, ngajalankeun logika bisnis sareng réspon balik. Urang ogé ngékspor skéma layanan ka GraphQL, sarta pamakéna narima titik aksés universal kana data, kalawan introspeksi sakuliah sakabéh modél. Nyaan pisan.

Kusabab jasa ngandung seueur deui fungsi, kami mutuskeun yén kedah aya perpustakaan dimana urang bakal mindahkeun kode anu sering dianggo. Urang ditambahkeun kana lingkungan aman, sanggeus dipariksa saméméhna yén éta teu megatkeun nanaon keur urang. Sareng ayeuna urang tiasa napelkeun lingkungan tambahan pikeun fungsi dina bentuk perpustakaan.

Kami hoyong gaduh platform sanés ngan ukur pikeun neundeun, tapi ogé pikeun komputasi. Sarta saprak urang geus kungsi kebat réplika jeung beling, urang dilaksanakeun jenis komputasi disebarkeun sarta disebut ngurangan peta, sabab tétéla sarupa jeung ngurangan peta aslina.

Sistem heubeul

Henteu sakabéh sistem warisan urang bisa nelepon kami ngaliwatan HTTP na make GraphQL, sanajan aranjeunna ngarojong protokol. Ku alatan éta, urang dijieun mékanisme nu ngidinan data bisa replicated kana sistem ieu.

Lamun hal robah pikeun urang, micu unik dipicu dina peran Panyimpenan jeung pesen kalawan parobahan ends up dina antrian processing. Ieu dikirim ka sistem éksternal ngagunakeun peran replicator misah. Peran ieu henteu nyimpen kaayaan.

perbaikan anyar

Sakumaha anjeun émut, tina sudut pandang bisnis, kami ngarékam asynchronous. Tapi lajeng maranéhna sadar yén éta moal cukup, sabab aya hiji kelas sistem anu kudu geuwat nampa respon ngeunaan status operasi. Janten urang ngalegaan GraphQL sareng nambihan mutasi. Aranjeunna sacara organik cocog kana paradigma anu aya pikeun damel sareng data. Pikeun kami, ieu mangrupikeun titik tunggal pikeun maca sareng nyerat pikeun kelas sistem anu sanés.

Kami ogé sadar yén jasa nyalira henteu cekap pikeun kami, sabab aya laporan anu cukup beurat anu kedah didamel sadinten, saminggu, sabulan sakali. Ieu tiasa nyandak lila, sarta laporan malah bisa meungpeuk loop acara Tarantool urang. Ku alatan éta, urang dijieun peran misah: scheduler jeung runner. Runners teu nyimpen kaayaan. Aranjeunna ngajalankeun tugas beurat nu urang teu bisa ngitung on laleur. Sareng peran scheduler ngawas jadwal peluncuran tugas ieu, anu dijelaskeun dina konfigurasi. Tugas sorangan disimpen di tempat anu sami sareng data bisnis. Nalika waktuna pas, scheduler nyokot tugas, masihan ka sababaraha runner, anu cacah eta sarta ngahemat hasilna.

Henteu sadayana tugas kedah dijalankeun dina jadwal. Sababaraha laporan kedah dibaca dina paménta. Pas sarat ieu datang, hiji tugas dijieun dina sandbox jeung dikirim ka runner pikeun palaksanaan. Saatos sababaraha waktos, pangguna nampi réspon asynchronous yén sadayana parantos diitung sareng laporan parantos siap.

Dina awalna, urang taat kana paradigma nyimpen sakabeh data, versioning eta teu ngahapus eta. Tapi dina kahirupan, ti jaman ka jaman anjeun masih kudu mupus hiji hal, lolobana sababaraha informasi atah atawa panengah. Dumasar kadaluwarsa, kami nyiptakeun mékanisme pikeun ngabersihan neundeun tina data anu luntur.

Urang ogé ngarti yén sooner atanapi engké kaayaan bakal datang nalika aya moal cukup spasi pikeun nyimpen data dina mémori, tapi Tapi data kudu disimpen. Pikeun tujuan ieu, urang badé ngadamel panyimpen disk.

kacindekan

Urang mimitian ku tugas ngamuat data kana model tunggal sareng nyéépkeun tilu bulan pikeun ngembangkeun éta. Kami ngagaduhan genep sistem suplai data. Sakabéh kode transformasi kana model tunggal nyaeta ngeunaan 30 sarébu garis di Lua. Sarta lolobana karya masih payun. Kadang-kadang aya kakurangan motivasi ti tim tatangga, sareng seueur kaayaan anu ngahesekeun padamelan. Upami anjeun kantos nyanghareupan tugas anu sami, teras kalikeun waktos anu sigana normal pikeun anjeun pikeun palaksanaan ku tilu, atanapi bahkan opat.

Ogé émut yén masalah anu aya dina prosés bisnis teu tiasa direngsekeun nganggo DBMS énggal, bahkan anu produktif pisan. Naon maksud kuring? Dina mimiti proyék urang, kami nyiptakeun kesan diantara para nasabah yén ayeuna urang bakal mawa database gancang anyar jeung urang bakal hirup! Prosésna bakal langkung gancang, sadayana bakal saé. Nyatana, téknologi henteu ngabéréskeun masalah anu aya dina prosés bisnis, sabab prosés bisnis mangrupikeun jalma. Sareng anjeun kedah damel sareng jalma, sanés téknologi.

Pangwangunan anu didorong ku tés tiasa nyeri sareng nyéépkeun waktos dina tahap awal. Tapi pangaruh positipna bakal katingali sanajan dina jangka pondok, nalika anjeun henteu kedah ngalakukeun nanaon pikeun nguji régrési.

Penting pisan pikeun ngalaksanakeun uji beban dina sadaya tahap pangwangunan. Langkung gancang anjeun perhatikeun sababaraha cacad dina arsitéktur, langkung gampang pikeun ngalereskeunana, anu bakal nyalametkeun anjeun seueur waktos di hareup.

Teu aya anu lepat sareng Lua. Saha waé tiasa diajar nyerat di dinya: pamekar Java, pamekar JavaScript, pamekar Python, payun-tungtung atanapi tukang-tukang. Malah analis urang nulis dina eta.

Lamun urang ngobrol ngeunaan kanyataan yén urang teu boga SQL, éta terrifies jalma. "Kumaha anjeun kéngingkeun data tanpa SQL? Éta mungkin? Tangtu. Dina sistem kelas OLTP, SQL henteu diperlukeun. Aya alternatif dina bentuk sababaraha jinis basa anu langsung mulangkeun anjeun kana pandangan berorientasi dokumen. Contona, GraphQL. Tur aya alternatif dina bentuk komputasi disebarkeun.

Upami anjeun ngartos yén anjeun kedah skala, teras rancang solusi anjeun dina Tarantool ku cara anu tiasa dijalankeun paralel dina puluhan instansi Tarantool. Mun anjeun teu ngalakukeun ieu, bakal hésé tur nyeri engké, saprak Tarantool ngan bisa éféktif ngagunakeun hiji inti processor.

sumber: www.habr.com