Wiwit taun 2019, Rusia duwe undang-undang babagan label wajib. Angger-anggering Toret ora ditrapake kanggo kabeh klompok barang, lan tanggal sing ditrapake kanggo label wajib kanggo klompok produk beda-beda. Tembakau, sepatu, lan obat-obatan bakal dadi sing pertama kena label wajib; produk liyane bakal ditambahake mengko, contone, minyak wangi, tekstil, lan susu. Inovasi legislatif iki nyebabake pangembangan solusi IT anyar sing bakal bisa nglacak kabeh rantai urip produk saka produksi nganti tuku dening konsumen pungkasan, kanggo kabeh peserta ing proses kasebut: negara kasebut dhewe lan kabeh organisasi sing adol barang. labeling wajib.
Ing X5, sistem sing bakal nglacak barang sing dilabeli lan ijol-ijolan data karo negara lan pemasok diarani "Marcus". Ayo dadi pitutur marang kowe ing urutan carane lan sing dikembangaké, apa tumpukan teknologi, lan apa kita kudu bangga.
HighLoad Nyata
"Marcus" ngrampungake akeh masalah, sing utama yaiku interaksi integrasi antarane sistem informasi X5 lan sistem informasi negara kanggo produk berlabel (GIS MP) kanggo nglacak gerakan produk berlabel. Platform kasebut uga nyimpen kabeh kode label sing ditampa dening kita lan kabeh sejarah gerakan kode kasebut ing obyek, lan mbantu ngilangi re-grading produk label. Nggunakake conto produk tembakau, sing kalebu ing klompok pisanan barang sing dilabeli, mung siji truk rokok ngemot sekitar 600 bungkus, sing saben duwe kode unik dhewe. Lan tugas sistem kita yaiku kanggo nglacak lan verifikasi legalitas obahe saben paket kasebut ing antarane gudang lan toko, lan pungkasane verifikasi admissibility adol menyang panuku pungkasan. Lan kita nyathet babagan 000 transaksi awis saben jam, lan kita uga kudu ngrekam carane saben paket kasebut mlebu ing toko. Mangkono, njupuk menyang akun kabeh obahe antarane obyek, kita ngarepake puluhan milyar cathetan saben taun.
Tim M
Senadyan kasunyatan manawa Marcus dianggep minangka proyek ing X5, iki ditindakake kanthi nggunakake pendekatan produk. Tim kerja miturut Scrum. Proyek kasebut diwiwiti ing musim panas pungkasan, nanging asil pisanan mung ing Oktober - tim kita dhewe wis dirakit kanthi lengkap, arsitektur sistem dikembangake lan peralatan dituku. Saiki tim duwe 16 wong, enem sing melu pembangunan backend lan frontend, telu sing melu analisis sistem. Enem wong liyane melu manual, mbukak, tes otomatis, lan pangopènan produk. Kajaba iku, kita duwe spesialis SRE.
Ora mung pangembang nulis kode ing tim kita; meh kabeh wong lanang ngerti carane program lan nulis autotes, mbukak skrip lan skrip otomatisasi. Kita menehi perhatian khusus babagan iki, amarga dhukungan produk mbutuhake otomatisasi tingkat dhuwur. Kita tansah nyoba kanggo menehi saran lan bantuan kolega sing durung diprogram sadurunge, lan menehi sawetara tugas cilik kanggo bisa.
Amarga pandemi koronavirus, kita nransfer kabeh tim menyang kerja remot; kasedhiyan kabeh alat kanggo manajemen pangembangan, alur kerja sing dibangun ing Jira lan GitLab nggawe gampang ngliwati tahap iki. Sasi sing ditindakake kanthi jarak jauh nuduhake manawa produktivitas tim ora nandhang sangsara; kanggo akeh, kepenak ing pakaryan saya tambah, siji-sijine sing ilang yaiku komunikasi langsung.
Rapat tim jarak jauh
Rapat sajrone kerja jarak jauh
Teknologi tumpukan saka solusi
Repositori standar lan alat CI / CD kanggo X5 yaiku GitLab. Kita digunakake kanggo panyimpenan kode, tes terus-terusan, lan penyebaran kanggo nyoba lan server produksi. Kita uga nggunakake praktik review kode, nalika paling ora 2 kolega kudu nyetujoni owah-owahan sing digawe dening pangembang kanggo kode kasebut. Analisa kode statis SonarQube lan JaCoCo mbantu supaya kode tetep resik lan njamin tingkat jangkoan tes unit sing dibutuhake. Kabeh owah-owahan ing kode kudu liwat mriksa iki. Kabeh skrip tes sing ditindakake kanthi manual banjur otomatis.
Kanggo implementasine sukses proses bisnis dening "Marcus", kita kudu ngatasi sawetara masalah teknologi, bab saben urutan.
Tugas 1. Perlu kanggo skalabilitas horisontal sistem
Kanggo ngatasi masalah iki, kita milih pendekatan microservice kanggo arsitektur. Ing wektu sing padha, penting banget kanggo ngerti wilayah tanggung jawab layanan kasebut. Kita nyoba kanggo dibagi menyang operasi bisnis, njupuk menyang akun tartamtu saka proses. Contone, panriman ing gudang ora kerep banget, nanging operasi skala gedhe banget, sajrone perlu cepet entuk informasi saka regulator negara babagan unit barang sing ditampa, jumlah sing ing siji pangiriman tekan 600000. , mriksa admissibility nampa produk iki menyang gudang lan bali kabeh informasi sing perlu kanggo sistem otomatis gudang. Nanging kiriman saka gudang nduweni intensitas sing luwih gedhe, nanging ing wektu sing padha dioperasikake kanthi volume data sing cilik.
Kita ngleksanakake kabeh layanan ing basis stateless lan malah nyoba kanggo dibagi operasi internal menyang langkah-langkah, nggunakake apa kita nelpon Kafka poto-topik. Iki nalika microservice ngirim pesen kanggo awake dhewe, sing ngidini sampeyan ngimbangi beban ing operasi sing luwih intensif sumber daya lan nyederhanakake pangopènan produk, nanging luwih akeh mengko.
Kita mutusake kanggo misahake modul kanggo interaksi karo sistem eksternal menyang layanan sing kapisah. Iki ndadekake iku bisa kanggo ngatasi masalah kerep ngganti API saka sistem external, karo sakbenere ora impact ing layanan karo fungsi bisnis.
Kabeh layanan mikro disebarake ing kluster OpenShift, sing ngrampungake masalah skala saben layanan mikro lan ngidini kita ora nggunakake alat Penemuan Layanan pihak katelu.
Tugas 2. Kebutuhan kanggo njaga beban dhuwur lan ijol-ijolan data sing intensif banget ing antarane layanan platform: Sajrone fase peluncuran proyek mung, kira-kira 600 operasi per detik ditindakake. Kita ngarepake nilai iki mundhak dadi 5000 ops / detik amarga toko eceran nyambung menyang platform kita.
Masalah iki ditanggulangi kanthi nyebarake kluster Kafka lan meh kabeh nolak interaksi sinkron antarane layanan mikro platform. Iki mbutuhake analisis sing ati-ati babagan syarat sistem, amarga ora kabeh operasi bisa dadi asinkron. Ing wektu sing padha, kita ora mung ngirim acara liwat makelar, nanging uga ngirim kabeh informasi bisnis sing dibutuhake ing pesen kasebut. Mangkono, ukuran pesen bisa tekan sawetara atus kilobyte. Watesan ukuran pesen ing Kafka mbutuhake kita prédhiksi kanthi akurat ukuran pesen, lan yen perlu, kita dibagi, nanging divisi kasebut logis, ana hubungane karo operasi bisnis.
Contone, kita dibagi barang sing teka ing mobil menyang kothak. Kanggo operasi sinkron, layanan mikro sing kapisah diwenehake lan tes beban sing lengkap ditindakake. Nggunakake Kafka menehi tantangan liyane - nguji operasi layanan kita kanthi nimbang integrasi Kafka ndadekake kabeh tes unit ora sinkron. Kita ngrampungake masalah iki kanthi nulis metode sarana dhewe nggunakake Embedded Kafka Broker. Iki ora ngilangi kebutuhan kanggo nulis tes unit kanggo metode individu, nanging luwih seneng nyoba kasus rumit nggunakake Kafka.
Kawigatosan banget kanggo nglacak log supaya TraceId ora ilang nalika ana pengecualian sajrone operasi layanan utawa nalika nggarap kumpulan Kafka. Lan yen ora ana masalah khusus karo sing sepisanan, banjur ing kasus kaloro kita dipeksa kanggo log kabeh TraceIds sing kumpulan teka karo lan pilih salah siji kanggo terus nelusuri. Banjur, nalika nelusuri TraceId asli, pangguna bakal gampang ngerteni apa sing diterusake.
Tugas 3. Kebutuhan kanggo nyimpen data sing akeh: Luwih saka 1 milyar label saben taun kanggo rokok mung teka ing X5. Dheweke mbutuhake akses sing tetep lan cepet. Secara total, sistem kasebut kudu ngolah udakara 10 milyar cathetan babagan sejarah gerakan barang sing dilabeli kasebut.
Kanggo ngatasi masalah katelu, database NoSQL MongoDB dipilih. Kita wis mbangun pecahan 5 simpul lan saben simpul duwe Replika Set 3 server. Iki ngidini sampeyan kanggo ukuran sistem horisontal, nambah server anyar kanggo kluster, lan mesthekake toleransi fault sawijining. Ing kene kita nemoni masalah liyane - njamin transaksi ing kluster mongo, kanthi nggunakake layanan mikro sing bisa diukur kanthi horisontal. Contone, salah sawijining tugas sistem kita yaiku ngenali upaya kanggo adol maneh produk kanthi kode label sing padha. Ing kene, overlay katon kanthi pindai sing salah utawa operasi sing salah dening kasir. Kita nemokake manawa duplikat kasebut bisa kedadeyan sajrone siji batch Kafka sing diproses, lan ing rong batch sing diproses bebarengan. Mangkono, mriksa duplikat kanthi takon database ora menehi apa-apa. Kanggo saben layanan mikro, kita ngrampungake masalah kasebut kanthi kapisah adhedhasar logika bisnis layanan iki. Contone, kanggo mriksa, kita nambah mriksa nang kumpulan lan Processing kapisah kanggo katon duplikat nalika masang.
Kanggo mesthekake yen karya pangguna kanthi riwayat operasi ora mengaruhi sing paling penting - fungsi proses bisnis, kita wis misahake kabeh data sejarah dadi layanan sing kapisah kanthi basis data sing kapisah, sing uga nampa informasi liwat Kafka. . Kanthi cara iki, pangguna bisa nggarap layanan sing terisolasi tanpa mengaruhi layanan sing ngolah data kanggo operasi sing lagi ditindakake.
Tugas 4: Pemrosesan maneh lan ngawasi antrian:
Ing sistem sing disebarake, masalah lan kesalahan mesthi muncul ing kasedhiyan database, antrian, lan sumber data eksternal. Ing kasus Marcus, sumber kesalahan kasebut yaiku integrasi karo sistem eksternal. Sampeyan kudu nemokake solusi sing bakal ngidini panjaluk bola-bali kanggo tanggapan sing salah karo sawetara wektu entek sing ditemtokake, nanging ing wektu sing padha ora mandheg ngolah panjaluk sing sukses ing antrian utama. Kanggo tujuan iki, sing diarani konsep "coba maneh adhedhasar topik" dipilih. Kanggo saben topik utama, siji utawa luwih topik coba maneh digawe kanggo pesen sing salah dikirim lan ing wektu sing padha wektu tundha ngolah pesen saka topik utama diilangi. Skema interaksi -
Kanggo ngleksanakake skema kasebut, kita butuh ing ngisor iki: kanggo nggabungake solusi iki karo Spring lan ngindhari duplikasi kode. Nalika surfing web, kita nemokake solusi sing padha adhedhasar Spring BeanPostProccessor, nanging katon ora perlu kanggo kita. Tim kita wis nggawe solusi sing luwih gampang sing ngidini kita nggabungake menyang siklus Spring kanggo nggawe konsumen lan nambahake Konsumen Coba maneh. Kita nawakake prototipe solusi kanggo tim Spring, sampeyan bisa ndeleng . Jumlah Konsumen Coba maneh lan jumlah usaha kanggo saben konsumen dikonfigurasi liwat paramèter, gumantung saka kabutuhan proses bisnis, lan supaya kabeh bisa digunakake, kabeh sing isih ana yaiku nambah anotasi org.springframework.kafka.annotation.KafkaListener , sing akrab karo kabeh pangembang Spring.
Yen pesen ora bisa diproses sawise kabeh nyoba maneh, iku menyang DLT (topik surat mati) nggunakake Spring DeadLetterPublishingRecoverer. Ing panyuwunan dhukungan, kita nggedhekake fungsi iki lan nggawe layanan kapisah sing ngidini sampeyan ndeleng pesen sing kalebu ing DLT, stackTrace, traceId lan informasi migunani liyane babagan dheweke. Kajaba iku, pemantauan lan tandha ditambahake ing kabeh topik DLT, lan saiki, nyatane, katon pesen ing topik DLT minangka alesan kanggo nganalisa lan ndandani cacat. Iki trep banget - kanthi jeneng topik, kita langsung ngerti apa langkah proses masalah kasebut muncul, sing bisa nyepetake telusuran sababe.
Paling anyar, kita wis ngleksanakake antarmuka sing ngidini kita ngirim pesen kanthi nggunakake dhukungan sawise ngilangi panyebabe (contone, mulihake fungsi sistem eksternal) lan, mesthi, netepake cacat sing cocog kanggo analisis. Iki ngendi topik poto kita teka ing Handy: supaya ora miwiti maneh chain Processing dawa, sampeyan bisa miwiti maneh saka langkah sing dikarepake.
Operasi Platform
Platform kasebut wis aktif ing operasi sing produktif, saben dina kita nindakake pangiriman lan pengiriman, nyambungake pusat distribusi lan toko anyar. Minangka bagéan saka pilot, sistem dianggo karo kelompok produk "Tembakau" lan "Sepatu".
Kabeh tim kita melu nganakake pilot, nganalisa masalah sing muncul lan menehi saran kanggo nambah produk, saka nambah log nganti ganti proses.
Supaya ora ngulang kesalahane, kabeh kasus sing ditemokake sajrone pilot dibayangke ing tes otomatis. Ana akeh tes otomatis lan tes unit ngidini sampeyan nganakake tes regresi lan nginstal hotfix kanthi harfiah sajrone sawetara jam.
Saiki kita terus ngembangake lan nambah platform, lan terus-terusan ngadhepi tantangan anyar. Yen sampeyan kasengsem, kita bakal ngomong babagan solusi ing artikel ing ngisor iki.
Source: www.habr.com