Isih saka film "Our Secret Universe: The Hidden Life of the Cell"

Bisnis investasi minangka salah sawijining wilayah sing paling rumit ing jagad perbankan, amarga ora mung utangan, utangan lan simpenan, nanging uga sekuritas, mata uang, komoditas, derivatif lan kabeh kerumitan ing bentuk produk terstruktur.

Bubar, kita wis nyumurupi paningkatan literasi finansial saka populasi. Akeh wong sing melu dagang ing pasar sekuritase. Akun investasi individu muncul durung suwe. Dheweke ngidini sampeyan perdagangan pasar sekuritas lan nampa potongan pajak utawa ora mbayar pajak. Lan kabeh klien sing teka menyang kita pengin ngatur portofolio lan ndeleng laporan kanthi nyata. Kajaba iku, paling asring portofolio iki multi-produk, yaiku, wong minangka klien saka macem-macem garis bisnis.

Kajaba iku, kabutuhan regulator, loro Rusia lan manca, saya tambah akeh.

Kanggo nyukupi kabutuhan saiki lan nggawe dhasar kanggo nganyarke mangsa, kita wis ngembangake inti bisnis investasi adhedhasar Tarantool.

Sawetara statistik. Bisnis investasi Alfa-Bank nyedhiyakake layanan perantara kanggo individu lan entitas legal kanggo nyedhiyakake kesempatan dagang ing macem-macem pasar sekuritas, layanan depository kanggo panyimpenan sekuritas, layanan manajemen kepercayaan kanggo individu kanthi modal pribadi lan gedhe, layanan kanggo ngetokake sekuritas kanggo perusahaan liyane . Bisnis investasi Alfa-Bank kalebu luwih saka 3 ewu kuotasi per detik, sing diundhuh saka macem-macem platform dagang. Sajrone dina kerja, luwih saka 300 ewu transaksi rampung ing pasar atas jenenge bank utawa klien. Nganti 5 ewu eksekusi pesenan per detik dumadi ing platform eksternal lan internal. Ing wektu sing padha, kabeh klien, internal lan eksternal, pengin ndeleng posisi ing wektu nyata.

prasejarah

Ing endi wae wiwit wiwitan taun 2000-an, wilayah bisnis investasi kita berkembang kanthi mandiri: perdagangan ijol-ijolan, layanan broker, dagang mata uang, perdagangan sekuritas lan macem-macem derivatif. Akibaté, kita wis tiba ing jebakan saka sumur fungsional. Opo iki? Saben baris bisnis duwe sistem dhewe sing duplikat fungsi saben liyane. Saben sistem nduweni model data dhewe-dhewe, sanajan padha ngoperasikake konsep sing padha: transaksi, instrumen, mitra, kuotasi, lan liya-liyane. Lan nalika saben sistem berkembang kanthi mandiri, macem-macem zoo teknologi muncul.

Kajaba iku, basis kode sistem wis cukup kuna, amarga sawetara produk asalé ing pertengahan 1990-an. Lan ing sawetara wilayah iki kalem proses pembangunan, lan ana masalah kinerja.

Requirements kanggo solusi anyar

Bisnis wis nyadari yen transformasi teknologi penting kanggo pangembangan luwih lanjut. Kita diwenehi tugas:

1. Nglumpukake kabeh data bisnis ing siji, panyimpenan cepet lan ing model data siji.
2. Kita kudu ora ilang utawa ngganti informasi iki.
3. Sampeyan perlu kanggo versi data, amarga ing sembarang wektu regulator bisa njaluk statistik kanggo taun sadurunge.
4. Kita ora mung kudu nggawa sawetara DBMS anyar, nanging nggawe platform kanggo ngrampungake masalah bisnis.

Kajaba iku, arsitek kita nyetel kahanan dhewe:

1. Solusi anyar kudu kelas perusahaan, yaiku, kudu diuji ing sawetara perusahaan gedhe.
2. Mode operasi solusi kudu kritis misi. Iki tegese kita kudu ana ing sawetara pusat data bebarengan lan kanthi tenang bisa slamet nalika mati siji pusat data.
3. Sistem kudu skala horisontal. Kasunyatane, kabeh sistem saiki mung bisa diukur kanthi vertikal, lan kita wis tekan langit-langit amarga saya suwe saya suwe saya suwe. Mulane, wayahe wis teka nalika kita kudu duwe sistem skala horisontal supaya bisa urip.
4. Antarane liyane, kita dikandhani manawa solusi kasebut kudu murah.

Kita ngetutake rute standar: kita ngrumusake syarat lan ngubungi departemen purchasing. Saka ing kono, kita nampa dhaptar perusahaan sing, umume, siap nindakake iki kanggo kita. We marang everyone bab masalah, lan nampa Assessment saka solusi saka enem wong.

Ing bank, kita ora njupuk tembung sapa wae; kita seneng nyoba kabeh dhewe. Mula, syarat wajib kompetisi tender yaiku lulus tes beban. Kita ngrumusake tugas tes beban, lan telu saka enem perusahaan wis sarujuk kanggo ngetrapake solusi prototipe adhedhasar teknologi ing memori kanthi biaya dhewe kanggo nyoba.

Aku ora bakal pitutur marang kowe carane kita dites kabeh lan suwene iku njupuk, aku mung bakal ngringkes: kinerja paling apik ing tes mbukak dituduhake dening solusi prototipe adhedhasar Tarantool saka tim pangembangan Mail.ru Group. We mlebu persetujuan lan miwiti pembangunan. Ana papat wong saka Mail.ru Group, lan saka Alfa-Bank ana telung pangembang, telung analis sistem, arsitek solusi, pemilik produk lan master Scrum.

Sabanjure, aku bakal menehi pitutur marang kowe babagan carane sistem kita tuwuh, kepiye berkembang, apa sing ditindakake lan kenapa persis iki.

Pangembangan saka

Pitakonan pisanan sing kita takoni yaiku carane entuk data saka sistem saiki. Kita mutusake yen HTTP cukup cocok kanggo kita, amarga kabeh sistem saiki komunikasi karo siji liyane kanthi ngirim XML utawa JSON liwat HTTP.

Kita nggunakake server HTTP dibangun ing Tarantool amarga kita ora perlu kanggo siksa mau SSL, lan kinerja cukup kanggo kita.

Kaya sing wis dakkandhakake, kabeh sistem kita manggon ing model data sing beda-beda, lan ing input kita kudu nggawa obyek kasebut menyang model sing digambarake dhewe. Dibutuhake basa sing ngidini data bisa diowahi. Kita milih Lua imperatif. Kita mbukak kabeh kode konversi data ing kothak wedhi - iki minangka papan sing aman sing ora ana kode sing mlaku. Kanggo nindakake iki, kita mung ngemot kode sing dibutuhake, nggawe lingkungan kanthi fungsi sing ora bisa mblokir utawa nyelehake apa wae.

Sawise konversi, data kudu dicenthang kanggo tundhuk karo model sing digawe. We rembugan kanggo dangu model apa lan apa basa digunakake kanggo njlèntrèhaké. Kita milih Apache Avro amarga basa kasebut prasaja lan duwe dhukungan saka Tarantool. Versi anyar saka model lan kode adat bisa dileksanakake kaping pirang-pirang dina, sanajan ing mbukak utawa tanpa, ing sembarang wektu dina, lan adaptasi kanggo owah-owahan cepet banget.

Sawise verifikasi, data kudu disimpen. Kita nindakake iki nggunakake vshard (kita duwe replika geo-dispersed shards).

Menapa malih, kekhususan kasebut saengga umume sistem sing ngirim data ora peduli apa kita nampa utawa ora. Pramila kita ngetrapake antrian ndandani wiwit wiwitan. Opo iki? Yen sakperangan alesan obyek ora ngalami transformasi data utawa verifikasi, kita isih konfirmasi panrimo, nanging ing wektu sing padha nyimpen obyek ing antrian repair. Iku konsisten lan dumunung ing gudang data bisnis utama. Kita langsung nulis antarmuka administrator, macem-macem metrik lan tandha. Akibaté, kita ora kelangan data. Sanajan ana sing diganti ing sumber, yen model data wis diganti, kita bakal langsung ndeteksi lan bisa adaptasi.

Saiki sampeyan kudu sinau carane njupuk data sing disimpen. Kita kanthi ati-ati nganalisa sistem kita lan weruh yen tumpukan klasik Jawa lan Oracle kudu ngemot sawetara jinis ORM sing ngowahi data saka relasional dadi obyek. Dadi kenapa ora langsung menehi obyek menyang sistem kanthi bentuk grafik? Dadi, kita seneng nggunakake GraphQL, sing nyukupi kabeh kabutuhan. Iki ngidini sampeyan nampa data ing bentuk grafik lan mung narik apa sing sampeyan butuhake saiki. Sampeyan bisa malah versi API karo cukup akèh keluwesan.

Meh langsung kita nyadari yen data sing diekstrak ora cukup. Kita nggawe fungsi sing bisa disambungake menyang obyek ing model - ateges, kolom sing diwilang. Yaiku, kita masang fungsi tartamtu menyang lapangan, sing, contone, ngetung rega penawaran rata-rata. Lan konsumen eksternal sing njaluk data kasebut ora ngerti manawa iki minangka lapangan sing diitung.

Dilaksanakake sistem otentikasi.

Banjur kita ngerteni manawa sawetara peran kristal ing keputusan kita. Peran minangka jinis aggregator fungsi. Biasane, peran duwe profil panggunaan peralatan sing beda:

• T-Connect: nangani sambungan mlebu, CPU winates, konsumsi memori kurang, stateless.
• IB-Core: ngowahi data sing ditampa liwat protokol Tarantool, yaiku, operasi karo tabel. Uga ora nyimpen negara lan bisa diukur.
• Panyimpenan: mung nyimpen data, ora nggunakake logika. Peran iki ngetrapake antarmuka sing paling gampang. Scalable thanks kanggo vshard.

Sing, nggunakake peran, kita decoupled bagean beda kluster saka saben liyane, kang bisa scaled independen saka saben liyane.

Dadi, kita wis nggawe rekaman aliran data transaksional asinkron lan antrian ndandani kanthi antarmuka admin. Rekaman kasebut ora sinkron saka sudut pandang bisnis: yen kita dijamin nulis data kanggo awake dhewe, ora ketompo ing ngendi wae, mula kita bakal konfirmasi. Yen ora dikonfirmasi, ana sing salah lan data kudu dikirim. Iki minangka rekaman asinkron.

Tes

Wiwit wiwitan proyek kasebut, kita mutusake manawa bakal nyoba ngleksanakake pangembangan uji coba. Kita nulis tes unit ing Lua nggunakake kerangka tarantool/tap, lan tes integrasi ing Python nggunakake kerangka pytest. Ing wektu sing padha, kita melu pangembang lan analis ing nulis tes integrasi.

Kepiye cara nggunakake pangembangan adhedhasar uji coba?

Yen kita pengin sawetara fitur anyar, kita nyoba kanggo nulis test kanggo pisanan. Nalika nemokake bug, kita priksa manawa sampeyan nulis tes dhisik, banjur ndandani. Wiwitane angel kerja kaya iki, ana salah pangerten ing bagean karyawan, malah sabotase: "Ayo cepet ndandani saiki, nindakake sing anyar, banjur nutupi tes." Mung iki "mengko" meh ora teka.

Mula, sampeyan kudu meksa dhewe nulis tes dhisik lan njaluk wong liya nindakake. Pracayaa, pangembangan sing didorong uji nggawa keuntungan sanajan ing wektu sing cendhak. Sampeyan bakal ngrasa yen uripmu dadi luwih gampang. Kita rumangsa yen 99% kode saiki ditutupi tes. Iki katon kaya akeh, nanging ora ana masalah: tes ditindakake ing saben komitmen.

Nanging, sing paling kita tresnani yaiku tes beban; kita nganggep sing paling penting lan nindakake kanthi rutin.

Aku bakal nyritakake babagan carane nindakake uji coba beban tahap pertama ing salah sawijining versi pisanan. Kita nginstal sistem ing laptop pangembang, nguripake beban lan nampa 4 ewu transaksi per detik. Hasil apik kanggo laptop. Kita nginstal ing bangku beban virtual saka papat server, luwih lemah tinimbang ing produksi. Disebarake kanthi minimal. Kita miwiti, lan kita entuk asil sing luwih elek tinimbang ing laptop ing siji thread. Konten kejut.

Kita padha sedhih banget. We katon ing mbukak server, nanging dadi metu lagi nganggur.

Kita nelpon pangembang, lan padha nerangake kanggo kita, wong sing teka saka donya Jawa, sing Tarantool iku siji-Utas. Iku mung bisa èfèktif digunakake dening siji inti prosesor ing mbukak. Banjur kita nyebarake jumlah maksimum instans Tarantool ing saben server, nguripake beban lan wis nampa 14,5 ewu transaksi per detik.

Ayo kula nerangake maneh. Amarga divisi menyang peran sing nggunakake sumber daya beda, peran kita tanggung jawab kanggo Processing sambungan lan transformasi data dimuat mung prosesor, lan strictly proporsional kanggo mbukak.

Ing kasus iki, memori mung digunakake kanggo ngolah sambungan sing mlebu lan obyek sementara.

Kosok baline, ing server panyimpenan, beban prosesor mundhak, nanging luwih alon tinimbang ing server sing ngolah sambungan.

Lan konsumsi memori tansaya ing babagan langsung kanggo jumlah data dimuat.

Layanan

Kanggo ngembangake produk anyar khusus minangka platform aplikasi, kita nggawe komponen kanggo nyebarake layanan lan perpustakaan.

Layanan ora mung potongan kode cilik sing beroperasi ing sawetara lapangan. Bisa dadi struktur sing cukup gedhe lan kompleks sing dadi bagean saka kluster, mriksa data referensi, mbukak logika bisnis lan menehi respon. Kita uga ngekspor skema layanan menyang GraphQL, lan konsumen nampa titik akses universal menyang data, kanthi introspeksi ing kabeh model. Iku banget nyaman.

Wiwit layanan ngemot luwih akeh fungsi, kita mutusake manawa kudu ana perpustakaan sing bakal dipindhah kode sing asring digunakake. Kita nambahake menyang lingkungan sing aman, sadurunge mriksa manawa ora ngrusak apa-apa kanggo kita. Lan saiki kita bisa nemtokake lingkungan tambahan kanggo fungsi ing wangun perpustakaan.

Kita pengin duwe platform ora mung kanggo panyimpenan, nanging uga kanggo komputasi. Lan wiwit kita wis duwe Bunch saka réplika lan shards, kita dipun ginakaken jenis komputasi mbagekke lan disebut nyuda peta, amarga iku padha karo peta asli ngurangi.

Sistem lawas

Ora kabeh sistem warisan bisa nelpon kita liwat HTTP lan nggunakake GraphQL, sanajan padha ndhukung protokol. Mulane, kita nggawe mekanisme sing ngidini data bisa ditiru menyang sistem kasebut.

Yen ana owah-owahan kanggo kita, micu unik micu ing peran Storage lan pesen karo owah-owahan rampung ing antrian Processing. Iki dikirim menyang sistem eksternal nggunakake peran replikator sing kapisah. Peran iki ora nyimpen negara.

dandan anyar

Nalika sampeyan ngelingi, saka sudut pandang bisnis, kita nindakake rekaman asinkron. Nanging banjur padha nyadari yen ora bakal cukup, amarga ana kelas sistem sing kudu langsung nampa respon babagan status operasi kasebut. Dadi kita ngluwihi GraphQL lan nambah mutasi. Padha sacara organik cocog karo paradigma sing ana kanggo nggarap data. Kanggo kita, iki minangka titik siji saka maca lan nulis kanggo kelas sistem liyane.

Kita uga nyadari yen layanan mung ora cukup kanggo kita, amarga ana laporan sing cukup abot sing kudu dibangun sapisan dina, minggu, sasi. Iki bisa njupuk wektu suwe, lan laporan malah bisa ngalangi loop acara Tarantool. Mula, kita nggawe peran sing kapisah: panjadwal lan pelari. Pelari ora nyimpen negara. Dheweke nindakake tugas abot sing ora bisa kita etung kanthi cepet. Lan peran panjadwal ngawasi jadwal peluncuran tugas kasebut, sing diterangake ing konfigurasi kasebut. Tugas kasebut disimpen ing panggonan sing padha karo data bisnis. Nalika wektu sing tepat teka, panjadwal njupuk tugas, menehi kanggo sawetara runner, sing counts lan nyimpen asil.

Ora kabeh tugas kudu ditindakake kanthi jadwal. Sawetara laporan kudu diwaca yen dikarepake. Sanalika syarat iki teka, tugas digawe ing kothak wedhi lan dikirim menyang pelari kanggo eksekusi. Sawise sawetara wektu, pangguna nampa respon asinkron sing kabeh wis diwilang lan laporan wis siyap.

Kaping pisanan, kita netepi paradigma nyimpen kabeh data, nggawe versi lan ora mbusak. Nanging ing urip, saka wektu kanggo wektu sampeyan isih kudu mbusak soko, biasane sawetara informasi mentah utawa penengah. Adhedhasar kadaluwarsa, kita nggawe mekanisme kanggo ngresiki panyimpenan saka data sing wis kadaluwarsa.

Kita uga ngerti manawa cepet utawa mengko ana kahanan nalika ora ana papan sing cukup kanggo nyimpen data ing memori, nanging data kasebut kudu disimpen. Kanggo tujuan kasebut, kita bakal nggawe panyimpenan disk.

kesimpulan

Kita miwiti kanthi tugas ngemot data menyang model siji lan ngenteni telung sasi kanggo ngembangake. Kita duwe enem sistem pasokan data. Kabeh kode transformasi dadi model siji kira-kira 30 ewu baris ing Lua. Lan umume karya isih ana ing ngarep. Kadhangkala ana kekurangan motivasi saka tim tetanggan, lan ana akeh kahanan sing nggawe rumit karya. Yen sampeyan nate ngadhepi tugas sing padha, banjur tikelake wektu sing katon normal kanggo sampeyan kanggo implementasine kanthi telung, utawa malah papat.

Uga elinga yen masalah sing ana ing proses bisnis ora bisa ditanggulangi nggunakake DBMS anyar, malah sing produktif banget. Maksudku opo? Ing wiwitan proyek, kita nggawe kesan ing antarane para pelanggan sing saiki bakal nggawa database cepet anyar lan kita bakal urip! Proses bakal luwih cepet, kabeh bakal apik. Nyatane, teknologi ora ngrampungake masalah sing ana ing proses bisnis, amarga proses bisnis yaiku wong. Lan sampeyan kudu nggarap wong, dudu teknologi.

Pangembangan sing didorong tes bisa nglarani lan butuh wektu ing tahap awal. Nanging efek positif kasebut bakal katon sanajan ing wektu sing cendhak, nalika sampeyan ora perlu nindakake apa-apa kanggo nganakake tes regresi.

Penting banget kanggo nganakake tes beban ing kabeh tahap pangembangan. Cepet sampeyan sok dong mirsani sawetara cacat ing arsitektur, bakal luwih gampang kanggo ndandani iku, kang bakal ngirit wektu akeh ing mangsa.

Ora ana sing salah karo Lua. Sapa wae bisa sinau nulis ing: pangembang Java, pangembang JavaScript, pangembang Python, front-end utawa back-end. Malah analis kita nulis babagan iki.

Nalika kita pirembagan bab kasunyatan sing kita ora duwe SQL, medeni wong. "Kepiye sampeyan entuk data tanpa SQL? Apa iku bisa? temtunipun. Ing sistem kelas OLTP, SQL ora dibutuhake. Ana alternatif ing wangun sawetara jinis basa sing langsung bali menyang tampilan document-oriented. Contone, GraphQL. Lan ana alternatif ing wangun komputasi disebarake.

Yen sampeyan ngerti yen sampeyan kudu nggawe skala, banjur desain solusi sampeyan ing Tarantool kanthi cara sing bisa mlaku bebarengan ing puluhan instans Tarantool. Yen sampeyan ora nindakake iki, iku bakal angel lan nglarani mengko, wiwit Tarantool mung bisa èfèktif nggunakake siji inti prosesor.

Source: www.habr.com