Masih daripada filem "Our Secret Universe: The Hidden Life of the Cell"

Perniagaan pelaburan adalah salah satu bidang yang paling kompleks dalam dunia perbankan, kerana terdapat bukan sahaja pinjaman, pinjaman dan deposit, tetapi juga sekuriti, mata wang, komoditi, derivatif dan segala macam kerumitan dalam bentuk produk berstruktur.

Baru-baru ini, kita telah melihat peningkatan dalam celik kewangan penduduk. Semakin ramai orang terlibat dalam perdagangan dalam pasaran sekuriti. Akaun pelaburan individu muncul tidak lama dahulu. Mereka membenarkan anda berdagang pasaran sekuriti dan sama ada menerima potongan cukai atau mengelak daripada membayar cukai. Dan semua pelanggan yang datang kepada kami ingin mengurus portfolio mereka dan melihat pelaporan dalam masa nyata. Lebih-lebih lagi, selalunya portfolio ini adalah pelbagai produk, iaitu, orang ramai adalah pelanggan pelbagai bidang perniagaan.

Di samping itu, keperluan pengawal selia, kedua-dua Rusia dan asing, semakin meningkat.

Untuk memenuhi keperluan semasa dan meletakkan asas untuk peningkatan masa depan, kami telah membangunkan teras perniagaan pelaburan berdasarkan Tarantool.

Beberapa statistik. Perniagaan pelaburan Alfa-Bank menyediakan perkhidmatan pembrokeran untuk individu dan entiti undang-undang untuk memberi peluang untuk berdagang di pelbagai pasaran sekuriti, perkhidmatan depositori untuk penyimpanan sekuriti, perkhidmatan pengurusan amanah untuk individu yang mempunyai modal persendirian dan besar, perkhidmatan untuk mengeluarkan sekuriti untuk syarikat lain. . Perniagaan pelaburan Alfa-Bank termasuk lebih daripada 3 ribu sebut harga sesaat, yang dimuat turun daripada pelbagai platform dagangan. Pada hari bekerja, lebih daripada 300 ribu transaksi dibuat di pasaran bagi pihak bank atau pelanggannya. Sehingga 5 ribu pelaksanaan pesanan sesaat berlaku pada platform luaran dan dalaman. Pada masa yang sama, semua pelanggan, dalaman dan luaran, ingin melihat kedudukan mereka dalam masa nyata.

prasejarah

Di suatu tempat dari awal tahun 2000-an, bidang perniagaan pelaburan kami berkembang secara bebas: perdagangan pertukaran, perkhidmatan pembrokeran, perdagangan mata wang, dagangan di kaunter dalam sekuriti dan pelbagai derivatif. Akibatnya, kita telah jatuh ke dalam perangkap telaga berfungsi. Apa ini? Setiap barisan perniagaan mempunyai sistem sendiri yang menduplikasi fungsi satu sama lain. Setiap sistem mempunyai model datanya sendiri, walaupun ia beroperasi dengan konsep yang sama: urus niaga, instrumen, rakan niaga, sebut harga dan sebagainya. Dan apabila setiap sistem berkembang secara bebas, zoo pelbagai teknologi muncul.

Di samping itu, asas kod sistem sudah agak ketinggalan zaman, kerana beberapa produk berasal pada pertengahan 1990-an. Dan di beberapa kawasan ini memperlahankan proses pembangunan, dan terdapat masalah prestasi.

Keperluan untuk penyelesaian baharu

Perniagaan telah menyedari bahawa transformasi teknologi adalah penting untuk pembangunan selanjutnya. Kami diberi tugasan:

1. Kumpul semua data perniagaan dalam satu storan yang cepat dan dalam satu model data.
2. Kita tidak boleh kehilangan atau menukar maklumat ini.
3. Ia adalah perlu untuk versi data, kerana pada bila-bila masa pengawal selia boleh meminta statistik untuk tahun-tahun sebelumnya.
4. Kita bukan sahaja harus membawa beberapa DBMS baharu yang bergaya, tetapi mencipta platform untuk menyelesaikan masalah perniagaan.

Di samping itu, arkitek kami menetapkan syarat mereka sendiri:

1. Penyelesaian baharu mestilah bertaraf perusahaan, iaitu, ia mesti sudah diuji di beberapa syarikat besar.
2. Mod pengendalian penyelesaian harus menjadi misi kritikal. Ini bermakna kita mesti berada di beberapa pusat data secara serentak dan dengan tenang bertahan daripada gangguan satu pusat data.
3. Sistem mesti berskala mendatar. Hakikatnya ialah semua sistem semasa kami hanya berskala menegak, dan kami sudah mencapai siling kerana pertumbuhan rendah kuasa perkakasan. Oleh itu, masanya telah tiba apabila kita perlu mempunyai sistem berskala mendatar untuk terus hidup.
4. Antara lain, kami diberitahu bahawa penyelesaiannya mestilah murah.

Kami mengikuti laluan standard: kami merumuskan keperluan dan menghubungi jabatan pembelian. Dari situ kami menerima senarai syarikat yang, secara amnya, bersedia untuk melakukan ini untuk kami. Kami memberitahu semua orang tentang masalah itu, dan menerima penilaian penyelesaian daripada enam daripada mereka.

Di bank, kami tidak menerima kata-kata sesiapa; kami suka menguji semuanya sendiri. Oleh itu, syarat wajib pertandingan tender kami adalah untuk lulus ujian beban. Kami merumuskan tugas ujian beban, dan tiga daripada enam syarikat telah pun bersetuju untuk melaksanakan penyelesaian prototaip berdasarkan teknologi dalam memori dengan perbelanjaan mereka sendiri untuk mengujinya.

Saya tidak akan memberitahu anda bagaimana kami menguji segala-galanya dan berapa lama masa yang diambil, saya hanya akan meringkaskan: prestasi terbaik dalam ujian beban ditunjukkan oleh penyelesaian prototaip berdasarkan Tarantool daripada pasukan pembangunan Kumpulan Mail.ru. Kami menandatangani perjanjian dan memulakan pembangunan. Terdapat empat orang dari Kumpulan Mail.ru, dan dari Alfa-Bank terdapat tiga pembangun, tiga penganalisis sistem, arkitek penyelesaian, pemilik produk dan master Scrum.

Seterusnya saya akan memberitahu anda tentang bagaimana sistem kami berkembang, bagaimana ia berkembang, perkara yang kami lakukan dan mengapa ini sebenarnya.

Pembangunan

Soalan pertama yang kami tanyakan kepada diri sendiri ialah cara mendapatkan data daripada sistem semasa kami. Kami memutuskan bahawa HTTP agak sesuai untuk kami, kerana semua sistem semasa berkomunikasi antara satu sama lain dengan menghantar XML atau JSON melalui HTTP.

Kami menggunakan pelayan HTTP terbina dalam Tarantool kerana kami tidak perlu menamatkan sesi SSL, dan prestasinya sudah memadai untuk kami.

Seperti yang telah saya katakan, semua sistem kami hidup dalam model data yang berbeza, dan pada input kami perlu membawa objek kepada model yang kami gambarkan sendiri. Bahasa diperlukan yang membenarkan data diubah. Kami memilih Lua imperatif. Kami menjalankan semua kod penukaran data dalam kotak pasir - ini adalah tempat yang selamat di mana kod berjalan tidak pergi. Untuk melakukan ini, kami hanya memuatkan rentetan kod yang diperlukan, mewujudkan persekitaran dengan fungsi yang tidak boleh menyekat atau menjatuhkan apa-apa.

Selepas penukaran, data mesti diperiksa untuk pematuhan dengan model yang kami cipta. Kami membincangkan untuk masa yang lama tentang model yang sepatutnya dan bahasa yang digunakan untuk menerangkannya. Kami memilih Apache Avro kerana bahasanya mudah dan mempunyai sokongan daripada Tarantool. Versi baharu model dan kod tersuai boleh digunakan beberapa kali sehari, walaupun di bawah beban atau tanpa, pada bila-bila masa sepanjang hari, dan menyesuaikan diri dengan perubahan dengan cepat.

Selepas pengesahan, data mesti disimpan. Kami melakukan ini menggunakan vshard (kami mempunyai replika serpihan geo-dispersi).

Selain itu, kekhususan adalah sedemikian rupa sehingga kebanyakan sistem yang menghantar data kepada kami tidak peduli sama ada kami menerimanya atau tidak. Itulah sebabnya kami melaksanakan baris gilir pembaikan dari awal lagi. Apa ini? Jika atas sebab tertentu objek tidak mengalami transformasi atau pengesahan data, kami masih mengesahkan penerimaan, tetapi pada masa yang sama menyimpan objek dalam baris gilir pembaikan. Ia konsisten dan terletak di gudang data perniagaan utama. Kami segera menulis antara muka pentadbir untuknya, pelbagai metrik dan makluman. Akibatnya, kami tidak kehilangan data. Walaupun sesuatu telah berubah dalam sumber, jika model data telah berubah, kami akan segera mengesannya dan boleh menyesuaikan diri.

Kini anda perlu belajar cara mendapatkan semula data yang disimpan. Kami menganalisis sistem kami dengan teliti dan melihat bahawa susunan klasik Java dan Oracle semestinya mengandungi beberapa jenis ORM yang menukar data daripada hubungan kepada objek. Jadi mengapa tidak segera memberikan objek kepada sistem dalam bentuk graf? Jadi kami dengan senang hati menerima pakai GraphQL, yang memenuhi semua keperluan kami. Ia membolehkan anda menerima data dalam bentuk graf dan mengeluarkan hanya apa yang anda perlukan sekarang. Anda juga boleh membuat versi API dengan banyak fleksibiliti.

Hampir serta-merta kami menyedari bahawa data yang kami ekstrak tidak mencukupi. Kami mencipta fungsi yang boleh dipautkan kepada objek dalam model - medan pengiraan pada dasarnya. Iaitu, kami melampirkan fungsi tertentu pada medan, yang, sebagai contoh, mengira purata harga sebut harga. Dan pengguna luar yang meminta data tidak tahu bahawa ini adalah medan yang dikira.

Melaksanakan sistem pengesahan.

Kemudian kami menyedari bahawa beberapa peranan menjadi jelas dalam keputusan kami. Peranan ialah sejenis agregator fungsi. Biasanya, peranan mempunyai profil penggunaan peralatan yang berbeza:

• T-Connect: mengendalikan sambungan masuk, CPU terhad, penggunaan memori yang rendah, tanpa kewarganegaraan.
• IB-Core: mengubah data yang diterima melalui protokol Tarantool, iaitu, ia beroperasi dengan jadual. Ia juga tidak menyimpan keadaan dan boleh berskala.
• Storan: hanya menyimpan data, tidak menggunakan sebarang logik. Peranan ini melaksanakan antara muka yang paling mudah. Berskala terima kasih kepada vshard.

Iaitu, menggunakan peranan, kami mengasingkan bahagian kluster yang berlainan antara satu sama lain, yang boleh diskalakan secara berasingan antara satu sama lain.

Jadi, kami telah mencipta rakaman aliran data transaksi tak segerak dan baris gilir pembaikan dengan antara muka pentadbir. Rakaman tidak segerak dari sudut perniagaan: jika kami dijamin untuk menulis data kepada diri kami sendiri, tidak kira di mana, kami akan mengesahkannya. Jika ia tidak disahkan, maka berlaku masalah dan data perlu dihantar. Ini ialah rakaman tak segerak.

Ujian

Dari awal projek, kami memutuskan bahawa kami akan cuba melaksanakan pembangunan dipacu ujian. Kami menulis ujian unit dalam Lua menggunakan rangka kerja tarantool/tap, dan ujian integrasi dalam Python menggunakan rangka kerja pytest. Pada masa yang sama, kami melibatkan kedua-dua pembangun dan penganalisis dalam menulis ujian integrasi.

Bagaimanakah kita menggunakan pembangunan dipacu ujian?

Jika kami mahukan beberapa ciri baharu, kami cuba menulis ujian untuknya terlebih dahulu. Apabila kami menemui pepijat, kami memastikan anda menulis ujian terlebih dahulu, dan kemudian membetulkannya. Pada mulanya sukar untuk bekerja seperti ini, terdapat salah faham di pihak pekerja, malah sabotaj: "Mari kita perbaiki dengan cepat sekarang, lakukan sesuatu yang baharu, dan kemudian tutup dengan ujian." Hanya "kemudian" ini hampir tidak pernah datang.

Oleh itu, anda perlu memaksa diri anda untuk menulis ujian terlebih dahulu dan meminta orang lain melakukannya. Percayalah, pembangunan berasaskan ujian membawa manfaat walaupun dalam jangka pendek. Anda akan merasakan bahawa hidup anda telah menjadi lebih mudah. Kami merasakan bahawa 99% daripada kod kini dilindungi oleh ujian. Ini kelihatan seperti banyak, tetapi kami tidak menghadapi sebarang masalah: ujian dijalankan pada setiap komit.

Walau bagaimanapun, perkara yang paling kami gemari ialah ujian beban; kami menganggapnya sebagai yang paling penting dan melaksanakannya dengan kerap.

Saya akan memberitahu anda sedikit cerita tentang cara kami menjalankan peringkat pertama ujian beban bagi salah satu versi pertama. Kami memasang sistem pada komputer riba pembangun, menghidupkan beban dan mendapat 4 ribu transaksi sesaat. Hasil yang baik untuk komputer riba. Kami memasangnya pada bangku beban maya empat pelayan, lebih lemah daripada dalam pengeluaran. Digunakan pada tahap minimum. Kami menjalankannya, dan kami mendapat hasil yang lebih teruk daripada pada komputer riba dalam satu utas. Kandungan kejutan.

Kami sangat sedih. Kami melihat beban pelayan, tetapi ternyata ia melahu.

Kami memanggil pembangun, dan mereka menerangkan kepada kami, orang yang berasal dari dunia Java, bahawa Tarantool adalah satu benang. Ia hanya boleh digunakan dengan berkesan oleh satu teras pemproses di bawah beban. Kemudian kami menggunakan bilangan maksimum kemungkinan kejadian Tarantool pada setiap pelayan, menghidupkan beban dan sudah menerima 14,5 ribu transaksi sesaat.

Biar saya terangkan sekali lagi. Disebabkan pembahagian kepada peranan yang menggunakan sumber secara berbeza, peranan kami yang bertanggungjawab untuk memproses sambungan dan transformasi data hanya memuatkan pemproses, dan berkadar ketat dengan beban.

Dalam kes ini, memori hanya digunakan untuk memproses sambungan masuk dan objek sementara.

Sebaliknya, pada pelayan storan, beban pemproses meningkat, tetapi jauh lebih perlahan daripada pelayan yang memproses sambungan.

Dan penggunaan memori meningkat secara berkadar langsung dengan jumlah data yang dimuatkan.

Perkhidmatan

Untuk membangunkan produk baharu kami secara khusus sebagai platform aplikasi, kami mencipta komponen untuk menggunakan perkhidmatan dan perpustakaan padanya.

Perkhidmatan bukan hanya cebisan kecil kod yang beroperasi pada beberapa medan. Mereka boleh menjadi struktur yang agak besar dan kompleks yang merupakan sebahagian daripada kluster, menyemak data rujukan, menjalankan logik perniagaan dan membalas respons. Kami juga mengeksport skema perkhidmatan ke GraphQL, dan pengguna menerima titik akses universal kepada data, dengan introspeksi merentas keseluruhan model. Ia sangat selesa.

Memandangkan perkhidmatan mengandungi lebih banyak fungsi, kami memutuskan bahawa perlu ada perpustakaan di mana kami akan memindahkan kod yang kerap digunakan. Kami menambahkannya ke persekitaran yang selamat, setelah memeriksa sebelum ini bahawa ia tidak merosakkan apa-apa untuk kami. Dan kini kita boleh menetapkan persekitaran tambahan kepada fungsi dalam bentuk perpustakaan.

Kami mahu mempunyai platform bukan sahaja untuk penyimpanan, tetapi juga untuk pengkomputeran. Dan kerana kami sudah mempunyai sekumpulan replika dan serpihan, kami melaksanakan sejenis pengkomputeran teragih dan memanggilnya pengurangan peta, kerana ia ternyata serupa dengan pengurangan peta asal.

Sistem lama

Tidak semua sistem warisan kami boleh menghubungi kami melalui HTTP dan menggunakan GraphQL, walaupun mereka menyokong protokol. Oleh itu, kami mencipta mekanisme yang membolehkan data direplikasi ke dalam sistem ini.

Jika sesuatu berubah untuk kami, pencetus unik akan dicetuskan dalam peranan Storan dan mesej dengan perubahan berakhir dalam baris gilir pemprosesan. Ia dihantar ke sistem luaran menggunakan peranan replikator yang berasingan. Peranan ini tidak menyimpan keadaan.

Penambahbaikan baharu

Seperti yang anda ingat, dari sudut perniagaan, kami melakukan rakaman tak segerak. Tetapi kemudian mereka menyedari bahawa ia tidak akan mencukupi, kerana terdapat kelas sistem yang perlu segera menerima maklum balas mengenai status operasi. Jadi kami melanjutkan GraphQL kami dan menambah mutasi. Mereka secara organik sesuai dengan paradigma sedia ada untuk bekerja dengan data. Bagi kami, ini adalah satu titik untuk membaca dan menulis untuk kelas sistem yang lain.

Kami juga menyedari bahawa perkhidmatan sahaja tidak akan mencukupi untuk kami, kerana terdapat laporan yang agak berat yang perlu dibina sekali sehari, seminggu, sebulan. Ini boleh mengambil masa yang lama, dan laporan juga boleh menyekat gelung acara Tarantool. Oleh itu, kami mencipta peranan berasingan: penjadual dan pelari. Pelari tidak menyimpan keadaan. Mereka menjalankan tugas berat yang tidak dapat kita kira dengan cepat. Dan peranan penjadual memantau jadual pelancaran tugas-tugas ini, yang diterangkan dalam konfigurasi. Tugasan itu sendiri disimpan di tempat yang sama dengan data perniagaan. Apabila tiba masa yang sesuai, penjadual mengambil tugas itu, memberikannya kepada beberapa pelari, yang mengiranya dan menyimpan hasilnya.

Tidak semua tugas perlu dijalankan mengikut jadual. Beberapa laporan perlu dibaca atas permintaan. Sebaik sahaja keperluan ini tiba, tugas dibuat dalam kotak pasir dan dihantar kepada pelari untuk dilaksanakan. Selepas beberapa lama, pengguna menerima respons tak segerak bahawa semuanya telah dikira dan laporan itu sudah sedia.

Pada mulanya, kami mematuhi paradigma menyimpan semua data, membuat versi dan tidak memadamkannya. Tetapi dalam kehidupan, dari semasa ke semasa anda masih perlu memadamkan sesuatu, kebanyakannya beberapa maklumat mentah atau perantaraan. Berdasarkan tamat tempoh, kami mencipta mekanisme untuk membersihkan storan daripada data lapuk.

Kami juga memahami bahawa lambat laun situasi akan datang apabila tidak akan ada ruang yang cukup untuk menyimpan data dalam ingatan, tetapi bagaimanapun data itu mesti disimpan. Untuk tujuan ini, kami akan membuat storan cakera tidak lama lagi.

Kesimpulan

Kami bermula dengan tugas memuatkan data ke dalam satu model dan menghabiskan masa tiga bulan untuk membangunkannya. Kami mempunyai enam sistem bekalan data. Keseluruhan kod transformasi menjadi model tunggal adalah kira-kira 30 ribu baris di Lua. Dan kebanyakan kerja masih di hadapan. Kadangkala terdapat kekurangan motivasi daripada pasukan jiran, dan terdapat banyak keadaan yang merumitkan kerja. Jika anda pernah menghadapi tugasan yang serupa, maka darabkan masa yang kelihatan biasa kepada anda untuk pelaksanaannya dengan tiga, atau bahkan empat.

Juga ingat bahawa masalah sedia ada dalam proses perniagaan tidak boleh diselesaikan menggunakan DBMS baharu, malah yang sangat produktif. Apa yang saya maksudkan? Pada permulaan projek kami, kami mencipta tanggapan di kalangan pelanggan bahawa kini kami akan membawa pangkalan data pantas baharu dan kami akan terus hidup! Proses akan berjalan lebih cepat, semuanya akan baik-baik saja. Malah, teknologi tidak menyelesaikan masalah yang dihadapi oleh proses perniagaan, kerana proses perniagaan adalah manusia. Dan anda perlu bekerja dengan orang, bukan teknologi.

Perkembangan yang didorong oleh ujian boleh menyakitkan dan memakan masa pada peringkat awal. Tetapi kesan positifnya akan ketara walaupun dalam jangka pendek, apabila anda tidak perlu melakukan apa-apa untuk menjalankan ujian regresi.

Adalah amat penting untuk menjalankan ujian beban pada semua peringkat pembangunan. Lebih cepat anda melihat beberapa kecacatan dalam seni bina, lebih mudah untuk memperbaikinya, yang akan menjimatkan banyak masa anda pada masa hadapan.

Tidak ada yang salah dengan Lua. Sesiapa sahaja boleh belajar menulis di dalamnya: pembangun Java, pembangun JavaScript, pembangun Python, bahagian hadapan atau bahagian belakang. Malah penganalisis kami menulis di atasnya.

Apabila kita bercakap tentang fakta bahawa kita tidak mempunyai SQL, ia menakutkan orang ramai. “Bagaimana anda mendapatkan data tanpa SQL? Adakah itu mungkin? Sudah tentu. Dalam sistem kelas OLTP, SQL tidak diperlukan. Terdapat alternatif dalam bentuk beberapa jenis bahasa yang segera mengembalikan anda kepada paparan berorientasikan dokumen. Contohnya, GraphQL. Dan terdapat alternatif dalam bentuk pengkomputeran teragih.

Jika anda faham bahawa anda perlu membuat skala, kemudian reka bentuk penyelesaian anda pada Tarantool dengan cara yang boleh dijalankan selari pada berpuluh-puluh contoh Tarantool. Jika anda tidak melakukan ini, ia akan menjadi sukar dan menyakitkan kemudian, kerana Tarantool hanya boleh menggunakan satu teras pemproses dengan berkesan.

Sumber: www.habr.com