2019-cu ildən Rusiyada məcburi etiketləmə haqqında qanun var. Qanun bütün mal qruplarına şamil edilmir və məhsul qrupları üçün məcburi markalanmanın qüvvəyə minmə tarixləri fərqlidir. İlk olaraq tütün, ayaqqabı və dərmanlar məcburi etiketlənməyə məruz qalacaq; digər məhsullar, məsələn, ətir, tekstil və süd məhsulları sonradan əlavə olunacaq. Bu qanunvericilik yeniliyi məhsulun istehsaldan son istehlakçıya qədər bütün həyat zəncirini, prosesin bütün iştirakçılarına: həm dövlətin özünə, həm də mal satan bütün təşkilatlara qədər izləməyə imkan verəcək yeni İT həllərin hazırlanmasına təkan verdi. məcburi etiketləmə.
X5-də etiketli malları izləyəcək və dövlət və təchizatçılarla məlumat mübadiləsi aparacaq sistem “Marcus” adlanır. Gəlin sizə onu necə və kimin hazırladığını, onun texnologiya yığınının nə olduğunu və niyə fəxr edəcəyimiz bir şey olduğunu izah edək.
Həqiqi Yüksək Yük
"Marcus" bir çox problemləri həll edir, əsas problem etiketlənmiş məhsulların hərəkətini izləmək üçün X5 məlumat sistemləri ilə etiketlənmiş məhsullar üçün dövlət məlumat sistemi (GIS MP) arasında inteqrasiya qarşılıqlı əlaqəsidir. Platforma həmçinin bizim tərəfimizdən alınan bütün etiketləmə kodlarını və bu kodların obyektlər arasında hərəkətinin bütün tarixini saxlayır və etiketlənmiş məhsulların yenidən qiymətləndirilməsini aradan qaldırmağa kömək edir. Etiketli malların ilk qruplarına daxil olan tütün məmulatları nümunəsindən istifadə edərək, sadəcə bir yük maşını siqaretin hər birinin özünəməxsus kodu olan təxminən 600 qutu var. Sistemimizin vəzifəsi hər bir belə paketin anbarlar və mağazalar arasında hərəkətinin qanuniliyini izləmək və yoxlamaq və nəticədə onların son alıcıya satışının məqbulluğunu yoxlamaqdır. Və biz saatda təxminən 000 nağd əməliyyatı qeyd edirik və hər bir belə paketin mağazaya necə daxil olduğunu da qeyd etməliyik. Beləliklə, obyektlər arasındakı bütün hərəkətləri nəzərə alaraq, biz ildə on milyardlarla rekord gözləyirik.
Komanda M
Marcus-un X5 daxilində bir layihə hesab edilməsinə baxmayaraq, məhsul yanaşmasından istifadə etməklə həyata keçirilir. Komanda Scrum əsasında işləyir. Layihə ötən ilin yayında başlayıb, lakin ilk nəticələr yalnız oktyabrda əldə edilib - öz komandamız tam yığılıb, sistem arxitekturası hazırlanıb və avadanlıq alınıb. İndi komandada 16 nəfər var, onlardan altısı backend və frontend inkişafında, üçü isə sistem analizində iştirak edir. Daha altı nəfər əl ilə, yükləmə, avtomatlaşdırılmış sınaq və məhsulun texniki xidmətində iştirak edir. Bundan əlavə, SRE mütəxəssisimiz var.
Komandamızda təkcə tərtibatçılar kod yazmır; demək olar ki, bütün uşaqlar avtotestləri necə proqramlaşdırmağı və yazmağı, skriptləri və avtomatlaşdırma skriptlərini yükləməyi bilirlər. Biz buna xüsusi diqqət yetiririk, çünki hətta məhsul dəstəyi yüksək səviyyədə avtomatlaşdırma tələb edir. Biz həmişə əvvəllər proqramlaşdırmayan həmkarlarımıza məsləhət və kömək etməyə çalışırıq və onlara üzərində işləmək üçün kiçik tapşırıqlar veririk.
Koronavirus pandemiyası ilə əlaqədar biz bütün komandanı uzaqdan işə keçirdik; inkişafın idarə edilməsi üçün bütün vasitələrin mövcudluğu, Jira və GitLab-da qurulmuş iş axını bu mərhələdən asanlıqla keçməyə imkan verdi. Uzaqdan keçirilən aylar göstərdi ki, nəticədə komandanın məhsuldarlığı pisləşmir, çoxları üçün işdə rahatlıq artdı, çatışmayan yeganə şey canlı ünsiyyət idi.
Uzaqdan komanda görüşü
Uzaqdan iş zamanı görüşlər
Həllin texnologiya yığını
X5 üçün standart repozitoriya və CI/CD aləti GitLab-dır. Biz onu kodun saxlanması, davamlı sınaq və sınaq və istehsal serverləri üçün yerləşdirmə üçün istifadə edirik. Ən azı 2 həmkarın tərtibatçı tərəfindən koda edilən dəyişiklikləri təsdiqləməsi lazım olduqda, kodun nəzərdən keçirilməsi təcrübəsindən də istifadə edirik. Statik kod analizatorları SonarQube və JaCoCo kodumuzu təmiz saxlamağa və vahid test əhatəsinin tələb olunan səviyyəsini təmin etməyə kömək edir. Koda edilən bütün dəyişikliklər bu yoxlamalardan keçməlidir. Əl ilə işləyən bütün test skriptləri sonradan avtomatlaşdırılır.
"Marcus" tərəfindən biznes proseslərinin uğurla həyata keçirilməsi üçün biz hər biri haqqında bir sıra texnoloji problemləri həll etməli olduq.
Tapşırıq 1. Sistemin üfüqi miqyaslılığına ehtiyac
Bu problemi həll etmək üçün arxitekturaya mikroservis yanaşmasını seçdik. Eyni zamanda, xidmətlərin məsuliyyət sahələrini dərk etmək çox vacib idi. Biz proseslərin xüsusiyyətlərini nəzərə alaraq onları biznes əməliyyatlarına bölməyə çalışdıq. Məsələn, anbarda qəbul çox tez-tez deyil, çox geniş miqyaslı əməliyyatdır, bu müddət ərzində dövlət tənzimləyicisindən qəbul edilən malların vahidləri haqqında məlumat almaq lazımdır, onların sayı bir çatdırılmada 600000-ə çatır. , bu məhsulun anbara qəbul edilməsinin məqbul olduğunu yoxlayın və anbarın avtomatlaşdırılması sistemi üçün bütün lazımi məlumatları qaytarın. Lakin anbarlardan göndərmə daha çox intensivliyə malikdir, lakin eyni zamanda kiçik həcmli məlumatlarla işləyir.
Biz bütün xidmətləri vətəndaşsızlıq əsasında həyata keçiririk və hətta Kafkanın öz mövzuları adlandırdığımız mövzulardan istifadə edərək daxili əməliyyatları mərhələlərə bölməyə çalışırıq. Bu, mikroservis özünə mesaj göndərdiyi zaman daha çox resurs tələb edən əməliyyatlar üzrə yükü balanslaşdırmağa imkan verir və məhsulun texniki xidmətini asanlaşdırır, lakin daha sonra bu barədə daha çox məlumat verir.
Xarici sistemlərlə qarşılıqlı əlaqə üçün modulları ayrıca xidmətlərə ayırmaq qərarına gəldik. Bu, xarici sistemlərin API-lərinin tez-tez dəyişdirilməsi problemini biznes funksionallığı ilə xidmətlərə praktiki olaraq təsir etmədən həll etməyə imkan verdi.
Bütün mikroservislər OpenShift klasterində yerləşdirilib ki, bu da həm hər bir mikroxidmətin miqyasının artırılması problemini həll edir, həm də üçüncü tərəfin Xidmət Kəşf alətlərindən istifadə etməməyə imkan verir.
Tapşırıq 2. Platforma xidmətləri arasında yüksək yük və çox intensiv məlumat mübadiləsini saxlamaq ehtiyacı: Təkcə layihənin işə salınması mərhələsində saniyədə 600-ə yaxın əməliyyat yerinə yetirilir. Pərakəndə satış məntəqələri platformamıza qoşulduqca bu dəyərin 5000 əməliyyat/san-a qədər artacağını gözləyirik.
Bu problem Kafka klasterinin yerləşdirilməsi və platformanın mikroservisləri arasında sinxron qarşılıqlı əlaqədən demək olar ki, tamamilə imtina etməklə həll edildi. Bu, sistem tələblərinin çox diqqətlə təhlilini tələb edir, çünki bütün əməliyyatlar asinxron ola bilməz. Eyni zamanda, biz yalnız broker vasitəsilə hadisələri ötürmürük, həm də mesajda bütün tələb olunan biznes məlumatlarını ötürürük. Beləliklə, mesajın ölçüsü bir neçə yüz kilobayta çata bilər. Kafkadakı mesaj ölçüsü limiti bizdən mesaj ölçüsünü dəqiq proqnozlaşdırmağı tələb edir və lazım gələrsə, biz onları bölürük, lakin bölgü məntiqlidir, biznes əməliyyatları ilə bağlıdır.
Məsələn, maşınla gələn malları qutulara bölürük. Sinxron əməliyyatlar üçün ayrıca mikroxidmətlər ayrılır və hərtərəfli yük testi aparılır. Kafkadan istifadə bizi başqa bir problemlə qarşı-qarşıya qoydu - Kafka inteqrasiyasını nəzərə alaraq xidmətimizin işini yoxlamaq bütün vahid testlərimizi asinxron edir. Biz Embedded Kafka Broker istifadə edərək öz faydalı metodlarımızı yazaraq bu problemi həll etdik. Bu, fərdi metodlar üçün vahid testlər yazmaq ehtiyacını aradan qaldırmır, lakin biz Kafkadan istifadə edərək mürəkkəb halları sınaqdan keçirməyə üstünlük veririk.
Xidmətlərin istismarı zamanı və ya Kafka toplusu ilə işləyərkən istisnalar baş verdikdə onların TraceId-lərinin itirilməməsi üçün qeydlərin izlənməsinə çox diqqət yetirildi. Birincisi ilə bağlı heç bir xüsusi problem yox idisə, ikinci halda biz dəstənin gətirdiyi bütün TraceId-ləri daxil etməyə və izləməyə davam etmək üçün birini seçməyə məcbur oluruq. Sonra orijinal TraceId ilə axtarış apararkən istifadəçi izləmənin hansı ilə davam etdiyini asanlıqla öyrənəcək.
Tapşırıq 3. Böyük miqdarda məlumatların saxlanmasına ehtiyac: Təkcə tütün üçün hər il 1 milyarddan çox etiket X5-ə gəlir. Onlar daimi və sürətli giriş tələb edir. Ümumilikdə, sistem bu etiketlənmiş malların hərəkət tarixinin təxminən 10 milyard qeydini emal etməlidir.
Üçüncü problemi həll etmək üçün MongoDB NoSQL verilənlər bazası seçildi. Biz 5 qovşaqdan ibarət bir parça qurduq və hər bir qovşaqda 3 serverdən ibarət Replika Dəsti var. Bu, klasterə yeni serverlər əlavə edərək sistemi üfüqi olaraq miqyaslandırmağa və onun nasazlıqlara dözümlülüyünü təmin etməyə imkan verir. Burada başqa bir problemlə qarşılaşdıq - üfüqi olaraq miqyaslana bilən mikroservislərin istifadəsini nəzərə alaraq monqo klasterində əməliyyatların təmin edilməsi. Məsələn, sistemimizin vəzifələrindən biri eyni etiketləmə kodları ilə məhsulların yenidən satılması cəhdlərini müəyyən etməkdir. Burada səhv taramalar və ya kassirlərin səhv əməliyyatları ilə üst-üstə düşmələr görünür. Biz aşkar etdik ki, bu cür dublikatlar həm emal olunan bir Kafka partiyasında, həm də paralel olaraq işlənən iki partiyada baş verə bilər. Beləliklə, verilənlər bazasını sorğulamaqla dublikatları yoxlamaq heç nə vermədi. Hər bir mikroservis üçün biz bu xidmətin biznes məntiqinə əsaslanaraq problemi ayrıca həll etdik. Məsələn, çeklər üçün biz partiyanın içərisinə çek əlavə etdik və daxil edərkən dublikatların görünüşü üçün ayrıca emal etdik.
İstifadəçilərin əməliyyatlar tarixi ilə işləməsinin heç bir şəkildə ən vacib şeyə - biznes proseslərimizin fəaliyyətinə təsir etməməsini təmin etmək üçün biz bütün tarixi məlumatları ayrıca məlumat bazası olan ayrıca xidmətə ayırdıq, o da Kafka vasitəsilə məlumat alır. . Beləliklə, istifadəçilər davam edən əməliyyatlar üçün məlumatları emal edən xidmətlərə təsir etmədən təcrid olunmuş xidmətlə işləyirlər.
Tapşırıq 4: Növbənin yenidən işlənməsi və monitorinqi:
Paylanmış sistemlərdə verilənlər bazası, növbələr və xarici məlumat mənbələrinin mövcudluğunda istər-istəməz problemlər və səhvlər yaranır. Markus vəziyyətində belə səhvlərin mənbəyi xarici sistemlərlə inteqrasiyadır. Müəyyən edilmiş bir fasilə ilə səhv cavablar üçün təkrar sorğulara imkan verən, lakin eyni zamanda əsas növbədə uğurlu sorğuların işlənməsini dayandırmayan həll yolu tapmaq lazım idi. Bu məqsədlə “mövzuya əsaslanan təkrar cəhd” konsepsiyası seçilmişdir. Hər bir əsas mövzu üçün səhv mesajların göndərildiyi bir və ya bir neçə təkrar sınama mövzusu yaradılır və eyni zamanda əsas mövzudan mesajların işlənməsində gecikmə aradan qaldırılır. Qarşılıqlı əlaqə sxemi -
Belə bir sxemi həyata keçirmək üçün bizə aşağıdakılar lazım idi: bu həlli Spring ilə inteqrasiya etmək və kodun təkrarlanmasının qarşısını almaq. İnternetdə gəzərkən, Spring BeanPostProccessor-a əsaslanan oxşar həll yolu ilə qarşılaşdıq, lakin bu, bizə lazımsız dərəcədə çətin göründü. Komandamız istehlakçılar yaratmaq üçün Bahar dövrünə inteqrasiya etməyə və əlavə olaraq Yenidən Sınaq İstehlakçılarını əlavə etməyə imkan verən daha sadə bir həll hazırladı. Bahar komandasına həllimizin prototipini təklif etdik, bunu görə bilərsiniz . Yenidən Sınaq İstehlakçılarının sayı və hər bir istehlakçı üçün cəhdlərin sayı biznes prosesinin ehtiyaclarından asılı olaraq parametrlər vasitəsilə konfiqurasiya edilir və hər şeyin işləməsi üçün org.springframework.kafka.annotation.KafkaListener annotasiyasını əlavə etmək qalır. , bütün Bahar tərtibatçılarına tanışdır.
Mesaj bütün təkrar cəhdlərdən sonra emal edilə bilmədisə, Spring DeadLetterPublishingRecoverer istifadə edərək DLT-yə (ölü məktub mövzusu) gedir. Dəstəyin xahişi ilə biz bu funksionallığı genişləndirdik və DLT, stackTrace, traceId-ə daxil olan mesajlara və onlar haqqında digər faydalı məlumatlara baxmaq imkanı verən ayrıca xidmət yaratdıq. Bundan əlavə, bütün DLT mövzularına monitorinq və xəbərdarlıqlar əlavə edildi və indi əslində DLT mövzusunda mesajın görünməsi bir qüsuru təhlil etmək və düzəltmək üçün bir səbəbdir. Bu, çox rahatdır - mövzunun adı ilə biz dərhal problemin prosesin hansı mərhələsində yarandığını anlayırıq ki, bu da onun əsas səbəbinin axtarışını əhəmiyyətli dərəcədə sürətləndirir.
Bu yaxınlarda biz mesajların səbəblərini aradan qaldırdıqdan (məsələn, xarici sistemin funksionallığını bərpa etdikdən) və əlbəttə ki, təhlil üçün müvafiq qüsuru təyin etdikdən sonra dəstəyimizdən istifadə edərək yenidən göndərməyə imkan verən bir interfeys tətbiq etdik. Məhz burada bizim öz mövzularımız faydalı olur: uzun bir emal zəncirini yenidən başlatmamaq üçün onu istədiyiniz addımdan yenidən başlada bilərsiniz.
Platformanın işləməsi
Platforma artıq məhsuldar fəaliyyətdədir, biz hər gün tədarüklər və daşımalar həyata keçirir, yeni paylama mərkəzləri və mağazaları birləşdiririk. Pilot proqram çərçivəsində sistem “Tütün” və “Ayaqqabı” məhsul qrupları ilə işləyir.
Bütün komandamız pilotların aparılmasında iştirak edir, ortaya çıxan problemləri təhlil edir və qeydləri təkmilləşdirməkdən tutmuş prosesləri dəyişdirməyə qədər məhsulumuzu təkmilləşdirmək üçün təkliflər verir.
Səhvlərimizin təkrarlanmaması üçün pilot zamanı aşkar edilən bütün hallar avtomatlaşdırılmış sınaqlarda öz əksini tapıb. Çoxlu sayda avtotestlərin və vahid testlərinin olması reqressiya testini keçirməyə və bir neçə saat ərzində sözün həqiqi mənasında düzəliş quraşdırmağa imkan verir.
İndi biz platformamızı inkişaf etdirməyə və təkmilləşdirməyə davam edirik və daim yeni problemlərlə üzləşirik. Əgər maraqlanırsınızsa, aşağıdakı məqalələrdə həll yollarımız haqqında danışacağıq.
Mənbə: www.habr.com