Kusabab 2019, Rusia ngagaduhan undang-undang ngeunaan panyiri wajib. Hukum henteu dilarapkeun ka sadaya grup barang, sareng kaping pikeun asupna panyiri wajib pikeun grup produk béda. Bako, sapatu, sareng obat-obatan bakal janten anu pangheulana tunduk kana labél wajib; produk-produk sanésna bakal ditambah engké, contona, parfum, tékstil, sareng susu. Inovasi législatif ieu nyababkeun pamekaran solusi IT énggal anu bakal ngamungkinkeun pikeun ngalacak sakumna ranté kahirupan produk tina produksi pikeun ngagaleuh ku konsumen akhir, ka sadaya pamilon dina prosés: boh nagara sorangan sareng sadaya organisasi anu ngajual barang kalayan labél wajib.
Dina X5, sistem anu bakal ngalacak barang anu dilabélan sareng tukeur data sareng nagara sareng supplier disebut "Marcus". Hayu urang terangkeun anjeun dina urutan kumaha sareng saha anu ngembangkeun éta, naon tumpukan téknologi na, sareng naha urang gaduh anu bangga.
HighLoad nyata
"Marcus" ngarengsekeun seueur masalah, anu utama nyaéta interaksi integrasi antara sistem inpormasi X5 sareng sistem inpormasi nagara pikeun produk anu dilabélan (GIS MP) pikeun ngalacak gerakan produk anu dilabélan. Platform ogé nyimpen sadaya kode panyiri anu ditampi ku kami sareng sadaya sajarah gerakan kodeu ieu dina objék, sareng ngabantosan ngaleungitkeun gradasi ulang produk anu dilabélan. Ngagunakeun conto produk bako, nu kaasup dina grup munggaran barang dilabélan, ngan hiji truk muatan roko ngandung kira 600 bungkus, nu masing-masing boga kode unik sorangan. Sareng tugas sistem kami nyaéta pikeun ngalacak sareng pariksa legalitas gerakan unggal bungkus sapertos antara gudang sareng toko, sareng pamustunganana pariksa katerimaan penjualanna ka pembeli akhir. Sareng urang ngarékam sakitar 000 transaksi tunai per jam, sareng urang ogé kedah ngarékam kumaha unggal bungkus sapertos kitu asup ka toko. Ku kituna, nyokot kana akun sagala gerakan antara objék, urang expecting puluhan milyar rékaman per taun.
Tim M
Sanaos kanyataan yén Marcus dianggap proyék dina X5, éta dilaksanakeun nganggo pendekatan produk. Tim gawéna nurutkeun Scrum. Proyék dimimitian usum panas kamari, tapi hasil anu munggaran ngan ukur dina Oktober - tim urang sorangan parantos dirakit, arsitéktur sistem dikembangkeun sareng alat-alat anu dipésér. Ayeuna tim ngagaduhan 16 urang, genep diantarana aub dina pamekaran backend sareng frontend, tilu diantarana aub dina analisis sistem. Genep deui jalma kalibet dina manual, beban, uji otomatis, sareng pangropéa produk. Salaku tambahan, urang gaduh spesialis SRE.
Henteu ngan ukur pamekar nyerat kode dina tim kami; ampir sadayana lalaki terang kumaha program sareng nyerat autotes, ngamuat skrip sareng skrip otomatis. Urang nengetan husus ka ieu, saprak malah rojongan produk merlukeun tingkat luhur automation. Kami salawasna nyobian mamatahan sareng ngabantosan kolega anu teu acan diprogram sateuacanna, sareng masihan aranjeunna sababaraha tugas leutik pikeun digarap.
Kusabab pandémik coronavirus, urang mindahkeun sadaya tim ka padamelan jarak jauh; kasadiaan sadaya alat pikeun manajemén pamekaran, alur kerja anu diwangun dina Jira sareng GitLab ngamungkinkeun gampang ngalangkungan tahap ieu. Bulan-bulan anu jarak jauh nunjukkeun yén produktivitas tim henteu sangsara salaku hasilna; pikeun seueur, kanyamanan di tempat kerja ningkat, hiji-hijina anu leungit nyaéta komunikasi langsung.
Rapat tim jauh
Rapat nalika damel jarak jauh
Téknologi tumpukan solusi
Repository standar sareng alat CI / CD pikeun X5 nyaéta GitLab. Kami nganggo éta pikeun neundeun kode, uji kontinyu, sareng panyebaran pikeun nguji sareng server produksi. Urang ogé ngagunakeun prakték review kode, lamun sahanteuna 2 kolega kudu approve parobahan dijieun ku pamekar kode. Analis kode statik SonarQube sareng JaCoCo ngabantosan urang ngajaga kodeu bersih sareng mastikeun tingkat sinyalna tés unit anu diperyogikeun. Sadaya parobihan kana kode kedah ngalangkungan cek ieu. Sadaya skrip tés anu dijalankeun sacara manual saterasna otomatis.
Pikeun palaksanaan suksés prosés bisnis ku "Marcus", urang kudu ngajawab sababaraha masalah téhnologis, ngeunaan unggal dina urutan.
tugas 1. Kabutuhan pikeun scalability horizontal sistem
Pikeun ngajawab masalah ieu, kami milih pendekatan microservice kana arsitektur. Dina waktos anu sami, penting pisan pikeun ngartos bidang tanggung jawab jasa. Kami nyobian ngabagi aranjeunna kana operasi bisnis, ngiringan spésifik prosésna. Salaku conto, katampi di gudang sanés sering pisan, tapi operasi skala ageung, dimana anjeun kedah gancang kéngingkeun inpormasi régulator nagara ngeunaan unit barang anu ditampi, jumlahna dina hiji pangiriman ngahontal 600000. , pariksa admissibility tina narima produk ieu kana gudang sarta balikkeun sagala informasi diperlukeun pikeun sistem automation gudang. Tapi kiriman ti gudang boga inténsitas loba gede, tapi di waktu nu sami ngoperasikeun kalawan volume leutik data.
Urang ngalaksanakeun sagala jasa dina dasar stateless komo nyoba ngabagi operasi internal kana hambalan, ngagunakeun naon urang nelepon Kafka timer topik. Ieu nalika microservice ngirim pesen ka dirina sorangan, nu ngidinan Anjeun pikeun nyaimbangkeun beban dina operasi leuwih sumberdaya-intensif jeung simplifies pangropéa produk, tapi nu langkung lengkep ihwal nu engké.
Urang mutuskeun pikeun misahkeun modul pikeun interaksi jeung sistem éksternal kana jasa misah. Hal ieu ngamungkinkeun pikeun ngarengsekeun masalah sering ngarobah API tina sistem éksternal, kalawan ampir euweuh dampak dina jasa jeung fungsionalitas bisnis.
Sadaya jasa mikro disebarkeun dina klaster OpenShift, anu ngarengsekeun duanana masalah skala unggal jasa mikro sareng ngamungkinkeun urang henteu nganggo alat Penemuan Layanan pihak katilu.
Tugas 2. Kabutuhan pikeun ngajaga beban tinggi sareng bursa data anu intensif pisan antara jasa platform: Salila fase peluncuran proyék nyalira, ngeunaan 600 operasi per detik dipigawé. Kami ngarepkeun nilai ieu ningkat kana 5000 ops / detik nalika toko ritel nyambung ka platform kami.
Masalah ieu direngsekeun ku deploying hiji klaster Kafka sarta ampir sakabéhna abandoning interaksi sinkron antara microservices platform urang. Ieu ngabutuhkeun analisa anu ati-ati ngeunaan syarat sistem, sabab henteu sadayana operasi tiasa henteu sinkron. Dina waktu nu sarua, urang teu ngan ngirimkeun acara ngaliwatan calo, tapi ogé ngirimkeun sagala informasi bisnis diperlukeun dina suratna. Ku kituna, ukuran pesen bisa ngahontal sababaraha ratus kilobytes. Watesan ukuran pesen di Kafka merlukeun kami akurat ngaduga ukuran pesen, sarta lamun perlu, urang ngabagi aranjeunna, tapi division nu logis, patali jeung operasi bisnis.
Contona, urang ngabagi barang nu datang dina mobil kana kotak. Pikeun operasi sinkron, jasa mikro anu misah dialokasikeun sareng uji beban lengkep dilaksanakeun. Nganggo Kafka masihan kami tantangan anu sanés - nguji operasi jasa kami kalayan merhatikeun integrasi Kafka ngajantenkeun sadaya tés unit kami henteu sinkron. Kami ngarengsekeun masalah ieu ku cara nyerat metode utilitas sorangan nganggo Embedded Kafka Broker. Ieu henteu ngaleungitkeun kabutuhan nyerat tés unit pikeun padika individu, tapi urang langkung milih pikeun nguji kasus rumit nganggo Kafka.
Seueur perhatian anu dibayar pikeun ngalacak log supados TraceIdna henteu leungit nalika aya pengecualian nalika operasi jasa atanapi nalika damel sareng angkatan Kafka. Sareng upami teu aya masalah khusus sareng anu kahiji, maka dina kasus anu kadua urang kedah log in sadaya TraceId anu sumping sareng pilih hiji pikeun neraskeun ngalacak. Teras, nalika milarian ku TraceId asli, pangguna bakal gampang mendakan anu teras-terasan diteruskeun.
Pancén 3. Kabutuhan pikeun nyimpen data anu ageung: Langkung ti 1 milyar labél per taun pikeun bako waé dugi ka X5. Aranjeunna peryogi aksés konstan sareng gancang. Dina total, sistem kedah ngolah kira-kira 10 milyar rékaman tina sajarah gerakan barang-barang anu dilabélan ieu.
Pikeun ngajawab masalah katilu, database NoSQL MongoDB dipilih. Kami parantos ngawangun beling 5 titik sareng unggal titik ngagaduhan Replika Set tina 3 server. Ieu ngidinan Anjeun pikeun skala sistem horisontal, nambahkeun server anyar kana klaster, sarta mastikeun kasabaran lepat na. Di dieu urang encountered masalah sejen - mastikeun transactionality dina klaster mongo, nyokot kana akun pamakéan microservices horisontal scalable. Salaku conto, salah sahiji tugas sistem kami nyaéta pikeun ngaidentipikasi usaha pikeun ngajual deui produk sareng kode panyiri anu sami. Di dieu, overlay muncul kalayan scan anu salah atanapi operasi anu salah ku kasir. Urang manggihan yén duplikat misalna bisa lumangsung duanana dina hiji bets Kafka keur diolah, sarta dina dua bets keur diolah dina paralel. Ku kituna, mariksa duplikat ku querying database teu masihan nanaon. Pikeun unggal layanan mikro, kami ngarengsekeun masalah sacara misah dumasar kana logika bisnis jasa ieu. Contona, pikeun cék, urang ditambahkeun cék jero bets jeung ngolah misah pikeun penampilan duplikat nalika inserting.
Pikeun mastikeun yén pagawéan pangguna sareng sajarah operasi henteu mangaruhan naon waé anu paling penting - fungsi prosés bisnis urang, kami parantos misahkeun sadaya data sajarah kana layanan anu misah sareng database anu misah, anu ogé nampi inpormasi ngalangkungan Kafka. . Ku cara ieu, pamaké tiasa dianggo sareng jasa terasing tanpa mangaruhan jasa anu ngolah data pikeun operasi anu lumangsung.
Pancén 4: Ngolah ulang antrian sareng ngawaskeun:
Dina sistem anu disebarkeun, masalah sareng kasalahan pasti timbul dina kasadiaan database, antrian, sareng sumber data éksternal. Dina kasus Marcus, sumber kasalahan sapertos kitu nyaéta integrasi sareng sistem éksternal. Ieu diperlukeun pikeun manggihan solusi anu bakal ngidinan ulang requests pikeun réspon erroneous kalawan sababaraha timeout husus, tapi dina waktos anu sareng teu eureun ngolah requests suksés dina antrian utama. Pikeun tujuan ieu, nu disebut "topik dumasar ulang" konsep dipilih. Pikeun unggal topik utama, hiji atawa leuwih jejer coba deui dijieun nu pesen erroneous dikirim tur dina waktos anu sareng reureuh ngolah pesen ti topik utama dileungitkeun. Skéma interaksi -
Pikeun nerapkeun skéma sapertos kitu, urang peryogi ieu: pikeun ngahijikeun solusi ieu sareng Spring sareng ngahindarkeun duplikasi kode. Nalika surfing wéb, kami mendakan solusi anu sami dumasar kana Spring BeanPostProccessor, tapi sigana teu perlu pikeun urang. Tim kami parantos ngadamel solusi anu langkung saderhana anu ngamungkinkeun urang ngahijikeun kana siklus Spring pikeun nyiptakeun konsumen sareng nambihan deui Konsumén. Kami nawiskeun prototipe solusi kami ka tim Spring, anjeun tiasa ningali éta . Jumlah Konsumén Coba deui sareng jumlah usaha pikeun unggal konsumen dikonpigurasi ngaliwatan parameter, gumantung kana kabutuhan prosés bisnis, sareng pikeun sadayana tiasa dianggo, sadayana anu tetep nyaéta nambihan annotation org.springframework.kafka.annotation.KafkaListener , nu wawuh ka sadaya pamekar Spring.
Lamun talatah teu bisa diolah sanggeus sagala usaha ulang, eta mana ka DLT (topik surat maot) ngagunakeun Spring DeadLetterPublishingRecoverer. Dina pamundut rojongan, urang dilegakeun pungsi ieu sarta nyieun layanan misah nu ngidinan Anjeun pikeun nempo pesen kaasup dina DLT, stackTrace, traceId sarta informasi mangpaat séjén ngeunaan aranjeunna. Salaku tambahan, ngawaskeun sareng panggeuing ditambahkeun kana sadaya topik DLT, sareng ayeuna, kanyataanna, penampilan pesen dina topik DLT mangrupikeun alesan pikeun nganalisis sareng ngalereskeun cacad. Ieu pohara merenah - ku nami topik, urang langsung ngartos dina naon hambalan tina prosés masalah timbul, nu nyata speeds up pilarian pikeun akar na.
Paling anyar, kami geus nerapkeun hiji panganteur anu ngamungkinkeun urang pikeun ngirim deui pesen ngagunakeun rojongan kami sanggeus ngaleungitkeun sabab maranéhna (contona, malikkeun fungsionalitas sistem éksternal) jeung, tangtosna, ngadegkeun cacad pakait pikeun analisis. Ieu tempat topik diri urang tiasa dianggo: supados henteu ngamimitian deui ranté pamrosésan anu panjang, anjeun tiasa ngabalikan deui tina léngkah anu dipikahoyong.
Operasi Platform
Platformna parantos aya dina operasi produktif, unggal dinten urang ngalaksanakeun pangiriman sareng kiriman, nyambungkeun pusat distribusi sareng toko énggal. Salaku bagian tina pilot, sistem jalan jeung grup produk "Bako" jeung "Sapatu".
Sakabeh tim urang ilubiung dina ngalaksanakeun pilots, nganalisa masalah munculna sarta nyieun saran pikeun ngaronjatkeun produk urang, ti ngaronjatkeun log pikeun ngarobah prosés.
Pikeun henteu ngulang kasalahan urang, sadaya kasus anu dipendakan nalika pilot ditingalikeun dina tés otomatis. Ayana sajumlah ageung tés otomatis sareng tés unit ngamungkinkeun anjeun ngalaksanakeun uji régrési sareng masang hotfix sacara harfiah dina sababaraha jam.
Ayeuna urang terus ngembangkeun sarta ngaronjatkeun platform urang, sarta terus nyanghareupan tantangan anyar. Upami anjeun kabetot, kami bakal ngobrol ngeunaan solusi kami dina tulisan di handap ieu.
sumber: www.habr.com