Kita kabeh seneng crita. Kita seneng njagong ngubengi geni lan ngomong babagan kamenangan, perang, utawa mung pengalaman kerja kita.
Dina iki mung dina kaya ngono. Lan sanajan sampeyan ora ana ing geni saiki, kita duwe crita kanggo sampeyan. Crita babagan carane kita miwiti nggarap panyimpenan ing Tarantool.
Biyen, perusahaan kita duwe sawetara "monoliths" lan siji "langit-langit" kanggo kabeh, sing monoliths iki alon-alon nanging mesthi nyedhak, mbatesi penerbangan perusahaan kita, pangembangan kita. Lan ana pangerten sing jelas: sawijining dina kita bakal kenek langit-langit iki kanthi keras.
Saiki dadi ideologi sing umum kanggo misahake kabeh lan kabeh wong, saka peralatan nganti logika bisnis. Akibaté, kita, contone, duwe loro DC sing praktis sawijining ing tingkat jaringan. Banjur kabeh iku temen beda.
Saiki, ana akeh alat lan alat kanggo nggawe owah-owahan ing wangun CI/CD, K8S, lsp. Ing wektu "monolitik", kita ora butuh akeh tembung manca. Iku cukup kanggo mbenerake "panyimpenan" ing database.
Nanging wektu maju, lan jumlah panjaluk maju bebarengan, kadhangkala njupuk RPS ngluwihi kemampuan kita. Kanthi mlebu negara-negara CIS menyang pasar, beban ing prosesor basis data monolit pisanan ora mudhun ing ngisor 90%, lan RPS tetep ing tingkat 2400. Lan iki ora mung pamilih cilik, nanging pitakon sing akeh banget karo a Bunch saka kir lan GABUNGAN sing bisa mbukak meh setengah saka data marang latar mburi IO gedhe.
Nalika dodolan Black Friday lengkap wiwit katon ing pemandangan - lan Wildberries minangka salah sawijining sing pertama sing nyekel ing Rusia - kahanan dadi sedhih. Sawise kabeh, beban ing dina kasebut mundhak kaping telu.
Oh, iki "jaman monolitik"! Aku manawa sampeyan wis ngalami bab padha, lan sampeyan isih ora bisa ngerti carane iki bisa kelakon kanggo sampeyan.
Apa sampeyan bisa nindakake - fashion iku gawan ing teknologi. Kira-kira 5 taun kepungkur, kita kudu mikir maneh salah sawijining mod iki ing wangun situs sing wis ana ing server .NET lan MS SQL, sing kanthi ati-ati nyimpen kabeh logika situs kasebut dhewe. Aku tetep kanthi ati-ati supaya sawing monolith kuwi dadi kesenengan sing dawa lan ora gampang.
A digression cilik.
Ing macem-macem acara, aku ujar: "yen sampeyan ora weruh monolit, mula sampeyan ora tuwuh!" Aku kasengsem karo pendapat sampeyan babagan perkara iki, tulisen ing komentar.
Swara Guntur
Ayo bali menyang "geni api". Kanggo nyebarake beban fungsi "monolitik", kita mutusake kanggo mbagi sistem kasebut dadi layanan mikro adhedhasar teknologi opensource. Amarga, paling ora, luwih murah kanggo skala. Lan kita duwe 100% pangerten yen kita kudu skala (lan akeh). Sawise kabeh, wis ing wektu iku bisa kanggo ngetik pasar negara tetanggan, lan nomer registrasi, uga nomer pesenan, wiwit tuwuh luwih kuwat.
Sawise analisa calon pisanan kanggo departure saka monolith kanggo microservices, kita temen maujud sing 80% saka nulis ing wong asalé saka sistem back office, lan maca saka kantor ngarep. Kaping pisanan, iki gegayutan karo sawetara subsistem penting kanggo kita - data pangguna lan sistem kanggo ngitung biaya pungkasan barang adhedhasar informasi babagan diskon lan kupon pelanggan tambahan.
Indentasi. Saiki medeni kanggo mbayangno, nanging saliyane subsistem sing kasebut ing ndhuwur, katalog produk, keranjang belanja pangguna, sistem telusuran produk, sistem panyaring kanggo katalog produk, lan macem-macem sistem rekomendasi uga dibusak saka monolit kita. Kanggo operasi saben wong, ana kelas kapisah saka sistem narrowly ngarang, nanging biyen padha manggon ing siji "omah".
Kita langsung ngrancang kanggo nransfer data babagan klien kita menyang sistem sharded. Ngilangi fungsi kanggo ngitung biaya pungkasan barang mbutuhake skalabilitas sing apik kanggo maca, amarga nggawe beban RPS paling gedhe lan paling angel ditindakake kanggo database (akeh data sing melu proses pitungan).
Akibaté, kita teka karo rencana sing cocog karo Tarantool.
Ing wektu kasebut, kanggo operasi layanan mikro, skema kanggo nggarap sawetara pusat data ing mesin virtual lan hardware dipilih. Kaya sing dituduhake ing gambar kasebut, opsi replikasi Tarantool ditrapake ing mode master-master lan master-slave.
Arsitektur. Pilihan 1. Layanan pangguna
Ing wektu saiki, ana 24 shards, sing saben duwe 2 conto (siji kanggo saben DC), kabeh ing mode master-master.
Ing ndhuwur database ana aplikasi sing ngakses replika database. Aplikasi bisa digunakake karo Tarantool liwat perpustakaan khusus, sing ngetrapake antarmuka driver Tarantool Go. Dheweke ndeleng kabeh replika lan bisa nggarap master kanggo maca lan nulis. Ateges, iku ngleksanakake model pesawat tiron, kang nambah logika kanggo milih tiron, nindakake retries, mbobol sirkuit lan watesan tarif.
Ing kasus iki, sampeyan bisa ngatur kabijakan pilihan replika ing konteks shards. Contone, roundrobin.
Arsitektur. Pilihan 2. Layanan kanggo ngitung biaya pungkasan barang
Sawetara sasi kepungkur, sebagian besar panjalukan kanggo ngitung biaya pungkasan barang menyang layanan anyar, sing, ing prinsip, bisa digunakake tanpa database, nanging sawetara wektu kepungkur kabeh diproses 100% dening layanan karo Tarantool ing sangisore hood.
Database layanan kasusun saka 4 master ing ngendi sinkronisasi ngumpulake data, lan saben master replikasi iki nyebarake data menyang replika mung diwaca. Saben master duwe kira-kira 15 replika kasebut.
Ing skema pisanan utawa ing skema kaloro, yen siji DC ora kasedhiya, aplikasi bisa nampa data ing kaloro.
Wigati dicathet yen replikasi ing Tarantool cukup fleksibel lan bisa dikonfigurasi nalika runtime. Ing sistem liyane, ana alangan. Contone, ngganti max_wal_senders lan max_replication_slots paramèter ing PostgreSQL mbutuhake restart saka tuntunan, kang ing sawetara kasus bisa mimpin kanggo severing sambungan antarane aplikasi lan DBMS.
Golek lan golek!
Yagene kita ora nindakake "kaya wong normal", nanging milih cara sing ora biasa? Iku gumantung apa sing dianggep normal. Akeh wong umume nggawe kluster saka Mongo lan nyebar ing telung DC sing disebarake geo.
Ing wektu kasebut, kita wis duwe rong proyek Redis. Sing pertama yaiku cache, lan sing nomer loro minangka panyimpenan sing terus-terusan kanggo data sing ora kritis. Iku cukup angel karo wong, sebagéyan liwat fault kita. Kadhangkala volume cukup gedhe ana ing kunci, lan saka wektu kanggo wektu situs dadi ora sehat. Kita nggunakake sistem iki ing versi master-slave. Lan ana akeh kasus sing kedadeyan ing master lan replikasi rusak.
Tegese, Redis apik kanggo tugas tanpa kewarganegaraan, dudu tugas negara. Ing asas, iku ngidini mecahaken paling masalah, nanging mung yen padha solusi tombol-nilai karo pasangan indeks. Nanging Redis ing wektu iku cukup sedih karo terus-terusan lan replikasi. Kajaba iku, ana keluhan babagan kinerja.
Kita mikir babagan MySQL lan PostgreSQL. Nanging sing pisanan piye wae ora nyekel karo kita, lan sing kapindho minangka produk sing rada canggih, lan ora pantes kanggo mbangun layanan sing prasaja.
Kita nyoba RIAK, Cassandra, malah database grafik. Iki kabeh solusi sing cukup ceruk sing ora cocog kanggo peran alat universal umum kanggo nggawe layanan.
Wekasanipun kita mapan ing Tarantool.
We nguripake kanggo iku nalika iku ing versi 1.6. Kita padha kasengsem ing simbiosis saka key-nilai lan fungsi saka database relasional. Ana indeks sekunder, transaksi lan spasi, iki kaya tabel, nanging ora prasaja, sampeyan bisa nyimpen macem-macem kolom ing kono. Nanging fitur pembunuh Tarantool yaiku indeks sekunder sing digabungake karo nilai kunci lan transaksional.
Komunitas sing nganggo basa Rusia sing responsif, siap mbantu ing obrolan, uga duwe peran. We aktif digunakake iki lan manggon langsung ing chatting. Lan aja lali babagan prayoga terus-terusan tanpa kesalahan lan kesalahan sing jelas. Yen katon ing sajarah kita karo Tarantool, kita wis akèh pain lan gagal karo réplikasi, nanging kita ora tau ilang data amarga fault sawijining!
Implementasine diwiwiti kanthi kasar
Ing wektu kasebut, tumpukan pangembangan utama kita yaiku .NET, sing ora ana konektor kanggo Tarantool. Kita langsung miwiti nindakake soko ing Go. Iku uga apik karo Lua. Masalah utama ing wektu iku karo debugging: ing .NET kabeh apik karo iki, nanging sawise iku angel terjun menyang donya Lua ditempelake, nalika sampeyan ora duwe debugging kajaba log. Kajaba iku, kanggo sawetara alesan réplikasi periodik ambruk, supaya aku kudu delve menyang struktur mesin Tarantool. Obrolan mbantu iki, lan luwih sithik, dokumentasi; kadhangkala kita ndeleng kode kasebut. Ing wektu iku, dokumentasi wis kaya-kaya.
Dadi, sajrone pirang-pirang wulan, aku bisa ngubengi lan entuk asil sing apik saka nggarap Tarantool. Kita nyusun pangembangan referensi ing git sing mbantu nggawe layanan mikro anyar. Contone, nalika ana tugas: nggawe layanan mikro liyane, pangembang ndeleng kode sumber solusi referensi ing repositori, lan ora butuh luwih saka seminggu kanggo nggawe sing anyar.
Iki minangka wektu khusus. Secara konvensional, sampeyan bisa pindhah menyang admin ing meja sabanjure lan takon: "Wenehana mesin virtual." Kira-kira telung puluh menit mobil wis ana karo sampeyan. Sampeyan nyambungake dhewe, nginstal kabeh, lan lalu lintas dikirim menyang sampeyan.
Dina iki, iki ora bakal bisa digunakake maneh: sampeyan kudu nambah ngawasi lan mlebu menyang layanan, nutupi fungsi kasebut kanthi tes, supaya mesin virtual utawa pangiriman menyang Kuber, lsp. Umumé, cara iki bakal luwih apik, sanajan bakal luwih suwe lan luwih angel.
Dibagi lan aturan. Apa urusan karo Lua?
Ana dilema serius: sawetara tim ora bisa andal ngowahi owah-owahan menyang layanan kanthi akeh logika ing Lua. Iki asring diiringi layanan sing ora bisa digunakake.
Yaiku, para pangembang nyiapake sawetara owah-owahan. Tarantool wiwit nindakake migrasi, nanging tiron isih nganggo kode lawas; Sawetara DDL utawa liya teka liwat replikasi, lan kode kasebut mung ambruk amarga ora dianggep. Akibaté, prosedur nganyari kanggo pangurus wis dilebokake ing sheet A4: mungkasi replikasi, nganyari iki, nguripake replikasi, mateni kene, nganyari ana. Ngimpi elek!
Akibaté, saiki kita paling kerep nyoba ora nindakake apa-apa ing Lua. Mung nggunakake iproto (protokol binar kanggo sesambungan karo server), lan iku. Mbok menawa iki minangka kekurangan kawruh ing antarane pangembang, nanging saka sudut pandang iki sistem kasebut rumit.
Kita ora tansah wuta tindakake script iki. Saiki kita ora duwe ireng lan putih: kabeh ana ing Lua, utawa kabeh ana ing Go. Kita wis ngerti carane bisa nggabungake supaya ora ana masalah migrasi mengko.
Endi Tarantool saiki?
Tarantool digunakake ing layanan kanggo ngitung biaya final saka barang njupuk menyang akun diskon Kupon, uga dikenal minangka "Promoter". Kaya sing dakkandhakake sadurunge, dheweke saiki pensiun: dheweke diganti karo layanan katalog anyar kanthi rega sing wis diwilang, nanging nem sasi kepungkur kabeh petungan digawe ing Promotizer. Sadurunge, setengah saka logika ditulis ing Lua. Rong taun kepungkur, layanan kasebut diowahi dadi fasilitas panyimpenan, lan logika kasebut ditulis maneh ing Go, amarga mekanika diskon wis diganti sethithik lan layanan kasebut ora nduweni kinerja.
Salah sawijining layanan sing paling kritis yaiku profil pangguna. Tegese, kabeh pangguna Wildberries disimpen ing Tarantool, lan ana kira-kira 50 yuta. A sistem sharded dening ID pangguna, mbagekke ing sawetara DC disambungake menyang layanan Go.
Miturut RPS, Promoter nate dadi pimpinan, nganti 6 ewu panjaluk. Ing salah siji titik kita duwe 50-60 salinan. Saiki pimpinan ing RPS yaiku profil pangguna, sekitar 12 ewu. Layanan iki nggunakake sharding khusus, dibagi karo kisaran ID pangguna. Layanan kasebut nglayani luwih saka 20 mesin, nanging iki akeh banget, kita rencana nyuda sumber daya sing diparengake, amarga kapasitas mesin 4-5 cukup.
Layanan sesi minangka layanan pertama kita ing vshard lan Cartridge. Nyetel vshard lan nganyari Cartridge mbutuhake sawetara gaweyan saka kita, nanging ing pungkasan kabeh bisa metu.
Layanan kanggo nampilake spanduk sing beda ing situs web lan ing aplikasi seluler minangka salah sawijining sing pisanan dirilis langsung ing Tarantool. Layanan iki misuwur amarga umure 6-7 taun, isih aktif lan durung nate urip maneh. Replikasi master-master digunakake. Ora ana sing rusak.
Ana conto nggunakake Tarantool kanggo fungsi referensi cepet ing sistem warehouse kanggo cepet pindho mriksa informasi ing sawetara kasus. Kita nyoba nggunakake Redis kanggo iki, nanging data ing memori njupuk papan luwih akeh tinimbang Tarantool.
Layanan dhaptar tunggu, langganan klien, crita sing saiki modis lan barang sing ditundha uga bisa digunakake karo Tarantool. Layanan pungkasan ing memori njupuk watara 120 GB. Iki minangka layanan paling lengkap ing ndhuwur.
kesimpulan
Thanks kanggo indeks sekunder sing digabungake karo nilai kunci lan transaksional, Tarantool cocog kanggo arsitektur basis layanan mikro. Nanging, kita nemoni kangelan nalika ngowahi owah-owahan menyang layanan kanthi logika sing akeh ing Lua - layanan kasebut asring mandheg. Kita ora bisa ngatasi iki, lan liwat wektu kita teka ing kombinasi beda Lua lan Go: kita ngerti ngendi kanggo nggunakake basa siji lan ngendi kanggo nggunakake liyane.
Apa maneh kanggo maca babagan topik kasebut
- Nggawe aplikasi dhuwur-load saka ngeruk nggunakake Tarantool
- Pilihan pimpinan sing dipercaya ing Tarantool Cartridge
- Saluran Telegram Tarantool kanthi warta babagan produk kasebut
- Rembugan Tarantool ing obrolan komunitas
Source: www.habr.com