Nuo 2019 metų Rusijoje galioja įstatymas dėl privalomo ženklinimo. Įstatymas netaikomas visoms prekių grupėms, skiriasi ir prekių grupių privalomo ženklinimo įsigaliojimo datos. Tabakas, batai, vaistai bus pirmiausiai privalomai ženklinami, vėliau bus įtraukti kiti produktai, pavyzdžiui, kvepalai, tekstilė, pienas. Ši teisėkūros naujovė paskatino kurti naujus IT sprendimus, kurie leis sekti visą produkto gyvavimo grandinę nuo pagaminimo iki galutinio vartotojo įsigijimo, visiems proceso dalyviams: tiek pačiai valstybei, tiek visoms organizacijoms, parduodančioms prekes. privalomas ženklinimas.
X5 sistemoje sistema, kuri stebės pažymėtas prekes ir keisis duomenimis su valstybe ir tiekėjais, vadinama „Marcus“. Iš eilės papasakosime, kaip ir kas jį sukūrė, koks yra jo technologijų paketas ir kodėl turime kuo didžiuotis.
Tikras aukštas krūvis
„Marcus“ sprendžia daugybę problemų, iš kurių pagrindinė – integracinė sąveika tarp X5 informacinių sistemų ir valstybinės ženklintų gaminių informacinės sistemos (GIS MP) ženklintų gaminių judėjimui sekti. Platforma taip pat saugo visus mūsų gautus ženklinimo kodus ir visą šių kodų judėjimo tarp objektų istoriją ir padeda pašalinti paženklintų produktų klasifikavimą. Remiantis tabako gaminių, kurie buvo įtraukti į pirmąsias ženklinamų prekių grupes, pavyzdžiu, vos viename sunkvežimių cigarečių krovinyje yra apie 600 000 pakelių, kurių kiekvienas turi savo unikalų kodą. O mūsų sistemos užduotis yra sekti ir patikrinti kiekvienos tokios pakuotės judėjimo tarp sandėlių ir parduotuvių teisėtumą ir galiausiai patikrinti jų pardavimo galutiniam pirkėjui priimtinumą. O per valandą fiksuojame apie 125 000 grynųjų pinigų operacijų, taip pat reikia fiksuoti, kaip kiekviena tokia pakuotė pateko į parduotuvę. Taigi, atsižvelgiant į visus judėjimus tarp objektų, tikimės dešimčių milijardų įrašų per metus.
Komanda M
Nepaisant to, kad Marcus laikomas X5 projektu, jis įgyvendinamas naudojant produkto metodą. Komanda dirba pagal Scrum. Projektas startavo praėjusią vasarą, tačiau pirmieji rezultatai pasirodė tik spalį – pilnai suburta mūsų pačių komanda, sukurta sistemos architektūra, nupirkta įranga. Dabar komandoje dirba 16 žmonių, iš kurių šeši užsiima backend ir frontend kūrimu, trys iš jų – sistemos analizėje. Dar šeši žmonės užsiima rankiniu, apkrovimu, automatizuotu testavimu ir gaminių priežiūra. Be to, turime SRE specialistą.
Mūsų komandoje kodą rašo ne tik kūrėjai, beveik visi vaikinai moka programuoti ir rašyti automatinius testus, įkelti scenarijus ir automatizavimo scenarijus. Tam skiriame ypatingą dėmesį, nes net produkto palaikymui reikalingas aukštas automatizavimo lygis. Visada stengiamės patarti ir padėti anksčiau neprogramavusiems kolegoms, duoti jiems keletą smulkių užduočių.
Dėl koronaviruso pandemijos visą komandą perkėlėme į nuotolinį darbą, visų plėtros valdymo įrankių prieinamumas, sukurta darbo eiga Jira ir GitLab leido lengvai pereiti šį etapą. Mėnesiai, praleisti nuotoliniu būdu, parodė, kad kolektyvo produktyvumas dėl to nenukentėjo, daugeliui išaugo komfortas darbe, trūko tik gyvo bendravimo.
Nuotolinis komandos susitikimas
Susitikimai nuotolinio darbo metu
Sprendimo technologijų krūva
Standartinė saugykla ir CI / CD įrankis, skirtas X5, yra GitLab. Naudojame kodo saugojimui, nuolatiniam testavimui ir diegimui bandymo ir gamybos serveriuose. Taip pat taikome kodo peržiūros praktiką, kai bent 2 kolegos turi patvirtinti kūrėjo padarytus kodo pakeitimus. Statiniai kodo analizatoriai „SonarQube“ ir „JaCoCo“ padeda mums išlaikyti mūsų kodą švarų ir užtikrinti reikiamą vieneto testavimo aprėptį. Visi kodo pakeitimai turi būti patikrinti. Visi rankiniu būdu vykdomi bandomieji scenarijai vėliau automatizuojami.
Kad „Marcus“ sėkmingai įgyvendintų verslo procesus, turėjome išspręsti nemažai technologinių problemų, maždaug kiekvieną iš eilės.
1 užduotis. Sistemos horizontalaus mastelio poreikis
Norėdami išspręsti šią problemą, pasirinkome mikro paslaugų požiūrį į architektūrą. Kartu buvo labai svarbu suprasti tarnybų atsakomybės sritis. Stengėmės jas suskirstyti į verslo operacijas, atsižvelgdami į procesų specifiką. Pavyzdžiui, priėmimas į sandėlį yra ne itin dažna, o labai didelės apimties operacija, kurios metu iš valstybės reguliuotojo reikia greitai gauti informaciją apie priimamus prekių vienetus, kurių skaičius viename pristatyme siekia 600000 tūkst. , patikrinkite šios prekės priėmimo į sandėlį leistinumą ir grąžinkite visą reikalingą informaciją sandėlio automatizavimo sistemai. Tačiau siuntimas iš sandėlių yra daug intensyvesnis, tačiau tuo pat metu veikia su mažais duomenų kiekiais.
Visas paslaugas įgyvendiname be pilietybės ir netgi stengiamės vidines operacijas suskirstyti į žingsnius, naudodamiesi vadinamosiomis Kafkos savitemomis. Tai yra tada, kai mikroservisas siunčia sau pranešimą, kuris leidžia subalansuoti daug išteklių reikalaujančių operacijų apkrovą ir supaprastina produkto priežiūrą, bet apie tai vėliau.
Sąveikos su išorinėmis sistemomis modulius nusprendėme atskirti į atskiras paslaugas. Tai leido išspręsti dažnai besikeičiančių išorinių sistemų API problemą, praktiškai nedarant įtakos paslaugoms su verslo funkcionalumu.
Visos mikropaslaugos yra įdiegtos „OpenShift“ klasteryje, kuris išsprendžia kiekvienos mikropaslaugos mastelio keitimo problemą ir leidžia nenaudoti trečiosios šalies paslaugų aptikimo įrankių.
2 užduotis. Poreikis išlaikyti didelę apkrovą ir labai intensyvų duomenų mainus tarp platformos paslaugų: Vien projekto paleidimo etape per sekundę atliekama apie 600 operacijų. Tikimės, kad ši vertė padidės iki 5000 XNUMX operacijų per sekundę, kai mažmeninės prekybos vietos prisijungs prie mūsų platformos.
Ši problema buvo išspręsta įdiegus Kafka klasterį ir beveik visiškai atsisakius sinchroninės sąveikos tarp platformos mikro paslaugų. Tam reikia labai kruopščiai išanalizuoti sistemos reikalavimus, nes ne visos operacijos gali būti asinchroninės. Tuo pačiu mes ne tik perduodame įvykius per brokerį, bet ir perduodame visą reikalingą verslo informaciją žinutėje. Taigi pranešimo dydis gali siekti kelis šimtus kilobaitų. Žinutės dydžio limitas Kafkoje reikalauja tiksliai nuspėti žinutės dydį, o prireikus juos padaliname, tačiau skirstymas logiškas, susijęs su verslo operacijomis.
Pavyzdžiui, automobiliu atkeliaujančias prekes skirstome į dėžes. Sinchroninėms operacijoms skiriamos atskiros mikropaslaugos ir atliekamas kruopštus apkrovos testavimas. Naudojant Kafka mums iškilo dar vienas iššūkis – tikrinant mūsų paslaugos veikimą, atsižvelgiant į Kafka integraciją, visi mūsų padalinių testai tampa asinchroniški. Šią problemą išsprendėme parašydami savo naudingumo metodus naudodami Embedded Kafka Broker. Tai nepanaikina poreikio rašyti atskirų metodų vienetinius testus, tačiau mes mieliau išbandome sudėtingus atvejus naudojant Kafka.
Daug dėmesio buvo skirta žurnalų sekimui, kad jų TraceId nebūtų prarastas, kai paslaugų veikimo metu arba dirbant su Kafka partija atsiranda išimčių. Ir jei su pirmuoju nebuvo jokių ypatingų problemų, tada antruoju atveju esame priversti registruoti visus „TraceId“, su kuriais buvo atnešta siunta, ir pasirinkti vieną, kad tęstume sekimą. Tada, ieškodamas pagal pradinį TraceId, vartotojas lengvai sužinos, su kuriuo sekimas buvo tęsiamas.
3 užduotis. Poreikis saugoti didelį duomenų kiekį: Daugiau nei 1 milijardas etikečių per metus vien tabakui patenka į X5. Jiems reikalinga nuolatinė ir greita prieiga. Iš viso sistema turi apdoroti apie 10 milijardų šių paženklintų prekių judėjimo istorijos įrašų.
Trečiajai problemai išspręsti buvo pasirinkta NoSQL duomenų bazė MongoDB. Sukūrėme 5 mazgų skeveldrą ir kiekvienas mazgas turi 3 serverių kopijų rinkinį. Tai leidžia nustatyti sistemos mastelį horizontaliai, į klasterį įtraukti naujų serverių ir užtikrinti jos atsparumą gedimams. Čia susidūrėme su kita problema – sandorių užtikrinimu mongo klasteryje, atsižvelgiant į horizontaliai keičiamų mikropaslaugų naudojimą. Pavyzdžiui, viena iš mūsų sistemos užduočių – identifikuoti bandymus perparduoti produktus su tais pačiais ženklinimo kodais. Čia pasirodo perdangos su klaidingais nuskaitymais arba klaidingomis kasininkų operacijomis. Mes nustatėme, kad tokie dublikatai gali atsirasti tiek vienoje Kafka partijoje, tiek dviejose lygiagrečiai apdorojamose partijose. Taigi patikrinimas, ar nėra dublikatų, užklausus duomenų bazėje, nieko nedavė. Kiekvienos mikropaslaugos problemą sprendėme atskirai, vadovaudamiesi šios paslaugos verslo logika. Pvz., čekiams pridėjome čekį paketo viduje ir atskirą apdorojimą, kad įterpiant būtų rodomi dublikatai.
Siekdami užtikrinti, kad vartotojų darbas su operacijų istorija jokiu būdu neįtakotų svarbiausio dalyko – mūsų verslo procesų funkcionavimo, visus istorinius duomenis išskyrėme į atskirą paslaugą su atskira duomenų baze, kuri informaciją taip pat gauna per Kafką. . Tokiu būdu vartotojai dirba su izoliuota paslauga, nepaveikdami paslaugų, kurios apdoroja vykdomų operacijų duomenis.
4 užduotis: eilės apdorojimas ir stebėjimas:
Paskirstytose sistemose neišvengiamai kyla problemų ir klaidų dėl duomenų bazių, eilių ir išorinių duomenų šaltinių prieinamumo. Marcuso atveju tokių klaidų šaltinis yra integracija su išorinėmis sistemomis. Reikėjo rasti sprendimą, kuris leistų pakartotinai prašyti klaidingų atsakymų su tam tikru nurodytu laiku, bet tuo pačiu nenustotų apdoroti sėkmingų užklausų pagrindinėje eilėje. Tam buvo pasirinkta vadinamoji „temos pakartojimo“ koncepcija. Kiekvienai pagrindinei temai sukuriama viena ar daugiau pakartotinių temų, į kurias siunčiami klaidingi pranešimai ir tuo pačiu pašalinamas pagrindinės temos pranešimų apdorojimo vėlavimas. Sąveikos schema -
Norint įgyvendinti tokią schemą, mums reikėjo šių dalykų: integruoti šį sprendimą su Spring ir išvengti kodo dubliavimo. Naršydami internete aptikome panašų „Spring BeanPostProccessor“ pagrindu sukurtą sprendimą, tačiau jis mums atrodė be reikalo sudėtingas. Mūsų komanda sukūrė paprastesnį sprendimą, leidžiantį integruotis į pavasario vartotojų kūrimo ciklą ir papildomai įtraukti Retry Consumers. Pavasario komandai pasiūlėme savo sprendimo prototipą, matote . Pakartotinių vartotojų skaičius ir kiekvieno vartotojo bandymų skaičius konfigūruojamas per parametrus, atsižvelgiant į verslo proceso poreikius, o kad viskas veiktų, belieka pridėti komentarą org.springframework.kafka.annotation.KafkaListener , kuris yra žinomas visiems pavasario kūrėjams.
Jei pranešimo nepavyko apdoroti po visų bandymų pakartotinai, jis perkeliamas į DLT (negyvos raidės temą) naudojant Spring DeadLetterPublishingRecoverer. Pagalbos prašymu išplėtėme šią funkciją ir sukūrėme atskirą paslaugą, kuri leidžia peržiūrėti į DLT, stackTrace, traceId įtrauktus pranešimus ir kitą naudingą informaciją apie juos. Be to, prie visų DLT temų buvo pridėtas stebėjimas ir įspėjimai, o dabar iš tikrųjų pranešimo atsiradimas DLT temoje yra priežastis analizuoti ir taisyti defektą. Tai labai patogu - pagal temos pavadinimą iš karto suprantame, kuriame proceso etape iškilo problema, o tai žymiai pagreitina pagrindinės priežasties paiešką.
Visai neseniai įdiegėme sąsają, kuri leidžia iš naujo siųsti pranešimus naudojantis mūsų palaikymu, pašalinus jų priežastis (pavyzdžiui, atkūrus išorinės sistemos funkcionalumą) ir, žinoma, nustačius atitinkamą defektą analizei. Čia praverčia mūsų savarankiškos temos: norėdami nepraleisti iš naujo ilgos apdorojimo grandinės, galite ją paleisti iš naujo nuo norimo veiksmo.
Platformos veikimas
Platforma jau veikia produktyviai, kiekvieną dieną atliekame pristatymus ir siuntas, prijungiame naujus paskirstymo centrus ir parduotuves. Kaip bandomojo projekto dalis, sistema veikia su produktų grupėmis „Tabakas“ ir „Batai“.
Visa mūsų komanda dalyvauja atliekant bandomuosius projektus, analizuoja kylančias problemas ir teikia pasiūlymus, kaip tobulinti mūsų produktą – nuo žurnalų tobulinimo iki procesų keitimo.
Kad mūsų klaidos nepasikartotų, visi piloto metu rasti atvejai atsispindi automatizuotuose testuose. Daugybė automatinių ir vienetų testų leidžia atlikti regresijos testus ir įdiegti karštąsias pataisas tiesiogine prasme per kelias valandas.
Dabar mes toliau plėtojame ir tobuliname savo platformą ir nuolat susiduriame su naujais iššūkiais. Jei jus domina, apie mūsų sprendimus papasakosime šiuose straipsniuose.
Šaltinis: www.habr.com