2019 yildan beri Rossiyada majburiy markalash to'g'risidagi qonun mavjud. Qonun tovarlarning barcha guruhlariga taalluqli emas va mahsulot guruhlari uchun majburiy markalashning kuchga kirish sanalari boshqacha. Tamaki, poyafzal va dori-darmonlar birinchi bo'lib majburiy markalanadi, boshqa mahsulotlar esa keyinchalik qo'shiladi, masalan, parfyumeriya, to'qimachilik va sut. Ushbu qonunchilik innovatsiyasi yangi IT-yechimlarni ishlab chiqishga turtki bo'ldi, bu mahsulotning ishlab chiqarishdan tortib to yakuniy iste'molchi tomonidan sotib olinishigacha, jarayonning barcha ishtirokchilari: davlatning o'zi ham, tovarlarni sotuvchi barcha tashkilotlar uchun ham butun hayot zanjirini kuzatish imkonini beradi. majburiy markalash.
X5-da etiketlangan tovarlarni kuzatib boradigan va davlat va etkazib beruvchilar bilan ma'lumot almashadigan tizim "Marcus" deb nomlanadi. Keling, uni qanday va kim ishlab chiqqani, uning texnologik stacki nima va nega bizda faxrlanadigan narsa borligini tartibda aytib beraylik.
Haqiqiy yuqori yuk
"Marcus" ko'plab muammolarni hal qiladi, asosiysi X5 axborot tizimlari va etiketli mahsulotlarning harakatini kuzatish uchun etiketli mahsulotlarning davlat axborot tizimi (GIS MP) o'rtasidagi integratsiyalashgan o'zaro ta'sir. Platforma, shuningdek, biz olgan barcha etiketka kodlarini va ushbu kodlarning ob'ektlar bo'ylab harakatlanishining butun tarixini saqlaydi va etiketlangan mahsulotlarni qayta tasniflashni bartaraf etishga yordam beradi. Yorliqli tovarlarning birinchi guruhlariga kiritilgan tamaki mahsulotlari misolida, bor-yo‘g‘i bitta yuk mashinasi sigaretda 600 000 ga yaqin quti bo‘lib, ularning har biri o‘ziga xos kodga ega. Va bizning tizimimizning vazifasi har bir bunday paketning omborlar va do'konlar o'rtasida harakatlanishining qonuniyligini kuzatish va tekshirish va oxir-oqibat ularni oxirgi xaridorga sotishning maqbulligini tekshirishdir. Va biz soatiga 125 000 ga yaqin naqd pul tranzaksiyalarini qayd etamiz, shuningdek, har bir bunday paket do'konga qanday kirganini yozib olishimiz kerak. Shunday qilib, ob'ektlar orasidagi barcha harakatlarni hisobga olgan holda, biz yiliga o'nlab milliardlab yozuvlarni kutmoqdamiz.
M jamoasi
Markus X5 doirasidagi loyiha hisoblanishiga qaramay, u mahsulot yondashuvidan foydalangan holda amalga oshirilmoqda. Jamoa Scrum bo'yicha ishlaydi. Loyiha o'tgan yozda boshlangan, biroq birinchi natijalar faqat oktyabr oyida bo'ldi - o'z jamoamiz to'liq yig'ildi, tizim arxitekturasi ishlab chiqildi va uskunalar sotib olindi. Hozir jamoada 16 kishi bor, ulardan olti nafari backend va frontend ishlab chiqish bilan shug‘ullanadi, ulardan uchtasi tizim tahlili bilan shug‘ullanadi. Yana olti kishi qo‘lda, yuklash, avtomatlashtirilgan sinov va mahsulotga texnik xizmat ko‘rsatish bilan shug‘ullanadi. Bundan tashqari, bizda SRE bo'yicha mutaxassis bor.
Bizning jamoamizda nafaqat ishlab chiquvchilar kod yozadilar; deyarli barcha bolalar avtotestlarni qanday dasturlash va yozishni, skriptlarni yuklashni va avtomatlashtirish skriptlarini bilishadi. Biz bunga alohida e'tibor beramiz, chunki hatto mahsulotni qo'llab-quvvatlash ham yuqori darajadagi avtomatlashtirishni talab qiladi. Biz har doim ilgari dasturlashmagan hamkasblarimizga maslahat va yordam berishga harakat qilamiz va ularga ishlash uchun kichik vazifalarni beramiz.
Koronavirus pandemiyasi tufayli biz butun jamoani masofaviy ishlashga o‘tkazdik; ishlab chiqishni boshqarish uchun barcha vositalarning mavjudligi, Jira va GitLab-da yaratilgan ish jarayoni ushbu bosqichdan osongina o‘tish imkonini berdi. Masofadan o'tkazilgan oylar natijada jamoaning unumdorligi pasaymaganini ko'rsatdi; ko'pchilik uchun ishdagi qulaylik oshdi, etishmayotgan yagona narsa jonli muloqot edi.
Masofaviy guruh yig'ilishi
Masofaviy ish paytida uchrashuvlar
Yechimning texnologik to'plami
X5 uchun standart ombor va CI/CD vositasi GitLab hisoblanadi. Biz undan kodni saqlash, uzluksiz sinov va serverlarni sinovdan o'tkazish va ishlab chiqarish uchun foydalanish uchun foydalanamiz. Biz, shuningdek, ishlab chiquvchi tomonidan kodga kiritilgan o'zgarishlarni kamida 2 hamkasb tasdiqlashi kerak bo'lganda, kodni ko'rib chiqish amaliyotidan foydalanamiz. Statik kod analizatorlari SonarQube va JaCoCo kodimizni toza saqlashga yordam beradi va birlik sinovini talab darajasida qamrab oladi. Kodga kiritilgan barcha o'zgarishlar ushbu tekshiruvlardan o'tishi kerak. Qo'lda ishlaydigan barcha test skriptlari keyinchalik avtomatlashtiriladi.
"Marcus" tomonidan biznes-jarayonlarni muvaffaqiyatli amalga oshirish uchun biz bir qator texnologik muammolarni hal qilishimiz kerak edi, ularning har biri haqida.
Vazifa 1. Tizimning gorizontal miqyosidagi zarurati
Ushbu muammoni hal qilish uchun biz arxitekturaga mikroservis yondashuvini tanladik. Shu bilan birga, xizmatlarning mas'uliyat sohalarini tushunish juda muhim edi. Biz jarayonlarning o'ziga xos xususiyatlarini hisobga olgan holda ularni biznes operatsiyalariga ajratishga harakat qildik. Masalan, omborga qabul qilish juda tez-tez emas, balki juda keng ko'lamli operatsiya bo'lib, uning davomida davlat regulyatoridan qabul qilinadigan tovarlar birliklari to'g'risida tezda ma'lumot olish kerak, ularning soni bir etkazib berishda 600000 XNUMX ga etadi. , ushbu mahsulotni omborga qabul qilishning maqbulligini tekshiring va omborni avtomatlashtirish tizimi uchun barcha kerakli ma'lumotlarni qaytaring. Ammo omborlardan jo'natish ancha katta intensivlikka ega, lekin ayni paytda kichik hajmdagi ma'lumotlar bilan ishlaydi.
Biz barcha xizmatlarni fuqaroligi bo'lmagan asosda amalga oshiramiz va hatto Kafka o'z-o'zidan mavzular deb ataydigan narsadan foydalanib, ichki operatsiyalarni bosqichlarga bo'lishga harakat qilamiz. Bu mikroservis o'ziga xabar yuborganda, bu sizga ko'proq resurs talab qiladigan operatsiyalardagi yukni muvozanatlash imkonini beradi va mahsulotga texnik xizmat ko'rsatishni soddalashtiradi, lekin keyinroq bu haqda ko'proq.
Biz tashqi tizimlar bilan o'zaro ishlash modullarini alohida xizmatlarga ajratishga qaror qildik. Bu tashqi tizimlarning API-larini tez-tez o'zgartirish muammosini hal qilish imkonini berdi, bu esa biznes funksionalligi bilan xizmatlarga deyarli ta'sir qilmadi.
Barcha mikroservislar OpenShift klasterida joylashtirilgan, bu har bir mikroservisni masshtablash muammosini hal qiladi va bizga uchinchi tomon Service Discovery vositalaridan foydalanmaslikka imkon beradi.
Vazifa 2. Platforma xizmatlari o'rtasida yuqori yuk va juda intensiv ma'lumotlar almashinuvini ta'minlash zarurati: Birgina loyihani ishga tushirish bosqichida soniyasiga 600 ga yaqin operatsiya bajariladi. Bizning platformamizga chakana savdo nuqtalari ulanganligi sababli bu qiymat 5000 ops/sek gacha oshishini kutamiz.
Ushbu muammo Kafka klasterini joylashtirish va platformaning mikroservislari o'rtasidagi sinxron shovqindan deyarli butunlay voz kechish orqali hal qilindi. Bu tizim talablarini juda ehtiyotkorlik bilan tahlil qilishni talab qiladi, chunki barcha operatsiyalar asenkron bo'lishi mumkin emas. Shu bilan birga, biz nafaqat broker orqali voqealarni uzatamiz, balki xabarda barcha kerakli biznes ma'lumotlarini ham uzatamiz. Shunday qilib, xabar hajmi bir necha yuz kilobaytga yetishi mumkin. Kafkadagi xabar hajmi chegarasi bizdan xabar hajmini aniq bashorat qilishni talab qiladi va agar kerak bo'lsa, biz ularni ajratamiz, ammo bo'linish mantiqiy, biznes operatsiyalari bilan bog'liq.
Masalan, biz mashinada kelgan tovarlarni qutilarga ajratamiz. Sinxron operatsiyalar uchun alohida mikroservislar ajratiladi va to'liq yuk sinovi o'tkaziladi. Kafkadan foydalanish bizga yana bir qiyinchilik tug'dirdi - Kafka integratsiyasini hisobga olgan holda xizmatimizning ishlashini sinab ko'rish bizning barcha birlik testlarimizni asinxron qiladi. Biz bu muammoni Embedded Kafka Broker yordamida o'z yordamchi usullarimizni yozish orqali hal qildik. Bu individual usullar uchun birlik testlarini yozish zaruratini bartaraf etmaydi, lekin biz Kafka yordamida murakkab holatlarni sinab ko'rishni afzal ko'ramiz.
Xizmatlar ishlashi yoki Kafka to'plami bilan ishlashda istisnolar yuzaga kelganda TraceId yo'qolmasligi uchun jurnallarni kuzatishga katta e'tibor berildi. Va agar birinchisida hech qanday maxsus muammolar bo'lmasa, ikkinchi holatda biz to'plam bilan kelgan barcha TraceId-larni jurnalga kiritishimiz va kuzatishni davom ettirish uchun birini tanlashimiz kerak. Keyin, asl TraceId bo'yicha qidiruvni amalga oshirayotganda, foydalanuvchi kuzatuv qaysi bilan davom etganini osongina bilib oladi.
Vazifa 3. Katta hajmdagi ma'lumotlarni saqlash zarurati: X1 ga faqat tamaki uchun yiliga 5 milliarddan ortiq yorliqlar keladi. Ular doimiy va tezkor kirishni talab qiladi. Umuman olganda, tizim ushbu etiketli tovarlarning harakatlanish tarixining 10 milliardga yaqin yozuvlarini qayta ishlashi kerak.
Uchinchi muammoni hal qilish uchun MongoDB NoSQL ma'lumotlar bazasi tanlandi. Biz 5 ta tugundan iborat parcha qurdik va har bir tugunda 3 ta serverdan iborat replika toʻplami mavjud. Bu klasterga yangi serverlarni qo'shib, tizimni gorizontal ravishda o'lchash imkonini beradi va uning xatolarga chidamliligini ta'minlaydi. Bu erda biz yana bir muammoga duch keldik - gorizontal ravishda kengaytiriladigan mikroservislardan foydalanishni hisobga olgan holda mongo klasterida tranzaksiyani ta'minlash. Masalan, bizning tizimimizning vazifalaridan biri mahsulotlarni bir xil etiketkalash kodlari bilan qayta sotishga urinishlarni aniqlashdir. Bu erda noto'g'ri skanerlash yoki kassirlarning noto'g'ri operatsiyalari bilan qoplamalar paydo bo'ladi. Biz shuni aniqladikki, bunday dublikatlar qayta ishlanayotgan bitta Kafka partiyasida ham, parallel ravishda qayta ishlanayotgan ikkita partiyada ham sodir bo'lishi mumkin. Shunday qilib, ma'lumotlar bazasini so'rash orqali dublikatlarni tekshirish hech narsa bermadi. Har bir mikroservis uchun biz ushbu xizmatning biznes mantig'i asosida muammoni alohida hal qildik. Masalan, cheklar uchun biz to'plamga chek qo'shdik va kiritishda dublikatlar paydo bo'lishi uchun alohida ishlov berishni qo'shdik.
Foydalanuvchilarning operatsiyalar tarixi bilan ishlashi eng muhim narsaga - biznes jarayonlarimizning ishlashiga hech qanday ta'sir qilmasligini ta'minlash uchun biz barcha tarixiy ma'lumotlarni alohida ma'lumotlar bazasi bilan alohida xizmatga ajratdik, u ham Kafka orqali ma'lumot oladi. . Shunday qilib, foydalanuvchilar davom etayotgan operatsiyalar uchun ma'lumotlarni qayta ishlaydigan xizmatlarga ta'sir qilmasdan, izolyatsiya qilingan xizmat bilan ishlaydi.
4-topshiriq: Navbatni qayta ishlash va nazorat qilish:
Tarqalgan tizimlarda ma'lumotlar bazalari, navbatlar va tashqi ma'lumotlar manbalarining mavjudligida muqarrar ravishda muammolar va xatolar yuzaga keladi. Markus misolida bunday xatolarning manbai tashqi tizimlar bilan integratsiyadir. Ba'zi belgilangan vaqt tugashi bilan noto'g'ri javoblar uchun takroriy so'rovlarga ruxsat beradigan, lekin ayni paytda asosiy navbatda muvaffaqiyatli so'rovlarni qayta ishlashni to'xtatmaydigan yechim topish kerak edi. Shu maqsadda "mavzuga asoslangan qayta urinish" kontseptsiyasi tanlandi. Har bir asosiy mavzu uchun xato xabarlar yuboriladigan bir yoki bir nechta takroriy mavzular yaratiladi va shu bilan birga asosiy mavzudagi xabarlarni qayta ishlashdagi kechikishlar bartaraf etiladi. O'zaro ta'sir sxemasi -
Bunday sxemani amalga oshirish uchun bizga quyidagilar kerak edi: ushbu yechimni Spring bilan birlashtirish va kodning takrorlanishiga yo'l qo'ymaslik. Internetda kezish paytida biz Spring BeanPostProccessor asosidagi shunga o'xshash yechimga duch keldik, ammo bu bizga keraksiz darajada noqulay tuyuldi. Bizning jamoamiz iste'molchilarni yaratish uchun bahor tsikliga integratsiyalashishga va qo'shimcha ravishda iste'molchilarni qayta ko'rishga qo'shishga imkon beruvchi oddiyroq yechim ishlab chiqdi. Biz Spring jamoasiga yechimimiz prototipini taklif qildik, buni ko'rishingiz mumkin . Qayta urinish iste'molchilari soni va har bir iste'molchi uchun urinishlar soni biznes jarayonining ehtiyojlariga qarab parametrlar orqali sozlanadi va hamma narsa ishlashi uchun org.springframework.kafka.annotation.KafkaListener izohini qo'shish qoladi. , bu barcha Bahor ishlab chiquvchilari uchun tanish.
Agar barcha qayta urinishlardan keyin xabarni qayta ishlash imkoni bo'lmasa, u Spring DeadLetterPublishingRecoverer yordamida DLT (o'lik xat mavzusi) ga o'tadi. Qo'llab-quvvatlash so'roviga binoan biz ushbu funksiyani kengaytirdik va DLT, stackTrace, traceId va ular haqidagi boshqa foydali ma'lumotlarni o'z ichiga olgan xabarlarni ko'rish imkonini beruvchi alohida xizmatni yaratdik. Bundan tashqari, barcha DLT mavzulariga monitoring va ogohlantirishlar qo'shildi va endi, aslida, DLT mavzusidagi xabarning paydo bo'lishi nuqsonni tahlil qilish va tuzatish uchun sababdir. Bu juda qulay - mavzu nomi bilan biz muammo jarayonning qaysi bosqichida paydo bo'lganini darhol tushunamiz, bu uning asosiy sababini izlashni sezilarli darajada tezlashtiradi.
Yaqinda biz xabarlarni sabablarini bartaraf etgandan so'ng (masalan, tashqi tizimning funksionalligini tiklash) va, albatta, tahlil qilish uchun tegishli nuqsonni aniqlagandan so'ng, bizning yordamimiz yordamida xabarlarni qayta yuborish imkonini beruvchi interfeysni joriy qildik. Bu erda bizning shaxsiy mavzularimiz foydali bo'ladi: uzoq ishlov berish zanjirini qayta ishga tushirmaslik uchun uni kerakli bosqichdan qayta boshlashingiz mumkin.
Platformaning ishlashi
Platforma allaqachon samarali ishlamoqda, biz har kuni etkazib berish va jo'natishlarni amalga oshiramiz, yangi tarqatish markazlari va do'konlarni ulaymiz. Sinovning bir qismi sifatida tizim "Tamaki" va "Poyafzal" mahsulot guruhlari bilan ishlaydi.
Bizning butun jamoamiz uchuvchilarni o'tkazishda ishtirok etadi, paydo bo'lgan muammolarni tahlil qiladi va jurnallarni yaxshilashdan tortib jarayonlarni o'zgartirishgacha mahsulotimizni yaxshilash bo'yicha takliflar beradi.
Xatolarimizni takrorlamaslik uchun sinov davomida aniqlangan barcha holatlar avtomatlashtirilgan testlarda aks ettirilgan. Ko'p sonli avtotestlar va birlik testlarining mavjudligi regressiya testini o'tkazish va tuzatishni bir necha soat ichida tom ma'noda o'rnatish imkonini beradi.
Endi biz platformamizni rivojlantirish va takomillashtirishda davom etamiz va doimo yangi muammolarga duch kelamiz. Agar sizni qiziqtiradigan bo'lsak, keyingi maqolalarda bizning echimlarimiz haqida gaplashamiz.
Manba: www.habr.com