Që nga viti 2019, Rusia ka një ligj për etiketimin e detyrueshëm. Ligji nuk zbatohet për të gjitha grupet e mallrave dhe datat e hyrjes në fuqi të etiketimit të detyrueshëm për grupet e produkteve janë të ndryshme. Duhani, këpucët dhe ilaçet do të jenë të parat që do t'i nënshtrohen etiketimit të detyrueshëm; produkte të tjera do të shtohen më vonë, për shembull, parfumi, tekstilet dhe qumështi. Kjo risi legjislative nxiti zhvillimin e zgjidhjeve të reja të TI-së që do të bëjnë të mundur gjurmimin e të gjithë zinxhirit jetësor të një produkti nga prodhimi tek blerja nga konsumatori përfundimtar, për të gjithë pjesëmarrësit në proces: si vetë shteti ashtu edhe të gjitha organizatat që shesin mallra me etiketimi i detyrueshëm.
Në X5, sistemi që do të gjurmojë mallrat e etiketuara dhe do të shkëmbejë të dhëna me shtetin dhe furnitorët quhet "Marcus". Le t'ju tregojmë me radhë se si dhe kush e ka zhvilluar atë, cili është grupi i teknologjisë së tij dhe pse kemi diçka për të cilën të krenohemi.
Ngarkesa e vërtetë e lartë
"Marcus" zgjidh shumë probleme, kryesore është ndërveprimi i integruar midis sistemeve të informacionit X5 dhe sistemit të informacionit shtetëror për produktet e etiketuara (GIS MP) për të gjurmuar lëvizjen e produkteve të etiketuara. Platforma ruan gjithashtu të gjitha kodet e etiketimit të marra nga ne dhe të gjithë historinë e lëvizjes së këtyre kodeve nëpër objekte dhe ndihmon në eliminimin e rigradimit të produkteve të etiketuara. Duke përdorur shembullin e produkteve të duhanit, të cilat përfshiheshin në grupet e para të mallrave të etiketuara, vetëm një kamion me cigare përmban rreth 600 pako, secila prej të cilave ka kodin e vet unik. Dhe detyra e sistemit tonë është të gjurmojë dhe verifikojë ligjshmërinë e lëvizjeve të secilës paketë të tillë midis depove dhe dyqaneve, dhe në fund të verifikojë pranueshmërinë e shitjes së tyre tek blerësi përfundimtar. Dhe ne regjistrojmë rreth 000 transaksione cash në orë, dhe gjithashtu duhet të regjistrojmë se si çdo paketë e tillë hyri në dyqan. Kështu, duke marrë parasysh të gjitha lëvizjet midis objekteve, ne presim dhjetëra miliarda rekorde në vit.
Skuadra M
Pavarësisht se Marcus konsiderohet një projekt brenda X5, ai po zbatohet duke përdorur një qasje produkti. Ekipi punon sipas Scrum. Projekti filloi verën e kaluar, por rezultatet e para erdhën vetëm në tetor - ekipi ynë u mblodh plotësisht, u zhvillua arkitektura e sistemit dhe u blenë pajisjet. Tani ekipi ka 16 persona, gjashtë prej të cilëve janë të përfshirë në zhvillimin e backend dhe frontend, tre prej të cilëve janë të përfshirë në analizën e sistemit. Gjashtë persona të tjerë janë të përfshirë në testimin manual, ngarkimin, automatikisht dhe mirëmbajtjen e produktit. Përveç kësaj, ne kemi një specialist të SRE.
Jo vetëm zhvilluesit shkruajnë kodin në ekipin tonë; pothuajse të gjithë djemtë dinë të programojnë dhe të shkruajnë autoteste, të ngarkojnë skriptet dhe skriptet e automatizimit. Ne i kushtojmë vëmendje të veçantë kësaj, pasi edhe mbështetja e produktit kërkon një nivel të lartë automatizimi. Ne gjithmonë përpiqemi të këshillojmë dhe ndihmojmë kolegët që nuk kanë programuar më parë dhe u japim atyre disa detyra të vogla për të punuar.
Për shkak të pandemisë së koronavirusit, ne transferuam të gjithë ekipin në punë në distancë; disponueshmëria e të gjitha mjeteve për menaxhimin e zhvillimit, fluksi i ndërtuar i punës në Jira dhe GitLab bëri të mundur kalimin e lehtë të kësaj faze. Muajt e kaluar në distancë treguan se produktiviteti i ekipit nuk vuajti si rezultat; për shumë njerëz, komoditeti në punë u rrit, e vetmja gjë që mungonte ishte komunikimi i drejtpërdrejtë.
Takimi i ekipit në distancë
Takimet gjatë punës në distancë
Stafi teknologjik i zgjidhjes
Depoja standarde dhe mjeti CI/CD për X5 është GitLab. Ne e përdorim atë për ruajtjen e kodit, testimin e vazhdueshëm dhe vendosjen në serverët e testimit dhe prodhimit. Ne përdorim gjithashtu praktikën e rishikimit të kodit, kur të paktën 2 kolegë duhet të miratojnë ndryshimet e bëra nga zhvilluesi në kod. Analizuesit e kodit statik SonarQube dhe JaCoCo na ndihmojnë të mbajmë kodin tonë të pastër dhe të sigurojmë nivelin e kërkuar të mbulimit të testit të njësisë. Të gjitha ndryshimet në kod duhet të kalojnë nëpër këto kontrolle. Të gjitha skriptet e testimit që ekzekutohen manualisht janë më pas të automatizuara.
Për zbatimin me sukses të proceseve të biznesit nga “Marcus”, na u desh të zgjidhnim një sërë problemesh teknologjike, për secilën sipas radhës.
Detyra 1. Nevoja për shkallëzim horizontal të sistemit
Për të zgjidhur këtë problem, ne zgjodhëm një qasje mikroservice për arkitekturën. Në të njëjtën kohë, ishte shumë e rëndësishme të kuptoheshin fushat e përgjegjësisë së shërbimeve. Ne u përpoqëm t'i ndajmë ato në operacione biznesi, duke marrë parasysh specifikat e proceseve. Për shembull, pranimi në një depo nuk është një operacion shumë i shpeshtë, por në shkallë shumë të gjerë, gjatë të cilit është e nevojshme të merren shpejt nga rregullatori shtetëror informacione për njësitë e mallrave që pranohen, numri i të cilave në një dërgesë arrin në 600000. , kontrolloni pranueshmërinë e pranimit të këtij produkti në magazinë dhe ktheni të gjitha informacionet e nevojshme për sistemin e automatizimit të magazinës. Por dërgesa nga magazinat ka një intensitet shumë më të madh, por në të njëjtën kohë funksionon me vëllime të vogla të dhënash.
Ne i zbatojmë të gjitha shërbimet mbi baza pa shtetësi dhe madje përpiqemi t'i ndajmë operacionet e brendshme në hapa, duke përdorur ato që ne i quajmë vetë-tema të Kafkës. Kjo është kur një mikroshërbim i dërgon vetes një mesazh, i cili ju lejon të balanconi ngarkesën në operacionet me më shumë burime intensive dhe thjeshton mirëmbajtjen e produktit, por më shumë për këtë më vonë.
Ne vendosëm të ndajmë modulet për ndërveprim me sistemet e jashtme në shërbime të veçanta. Kjo bëri të mundur zgjidhjen e problemit të ndryshimit të shpeshtë të API-ve të sistemeve të jashtme, praktikisht pa asnjë ndikim në shërbimet me funksionalitetin e biznesit.
Të gjitha mikroshërbimet vendosen në një grupim OpenShift, i cili zgjidh si problemin e shkallëzimit të çdo mikroshërbimi, ashtu edhe na lejon të mos përdorim mjetet e zbulimit të shërbimit të palëve të treta.
Detyra 2. Nevoja për të mbajtur një ngarkesë të lartë dhe shkëmbim shumë intensiv të të dhënave midis shërbimeve të platformës: Vetëm gjatë fazës së nisjes së projektit kryhen rreth 600 operacione në sekondë. Ne presim që kjo vlerë të rritet në 5000 ops/sek ndërsa pikat e shitjes me pakicë lidhen me platformën tonë.
Ky problem u zgjidh duke vendosur një grup Kafka dhe duke braktisur pothuajse plotësisht ndërveprimin sinkron midis mikroshërbimeve të platformës. Kjo kërkon një analizë shumë të kujdesshme të kërkesave të sistemit, pasi jo të gjitha operacionet mund të jenë asinkrone. Në të njëjtën kohë, ne jo vetëm që transmetojmë ngjarje përmes ndërmjetësit, por gjithashtu transmetojmë të gjithë informacionin e kërkuar të biznesit në mesazh. Kështu, madhësia e mesazhit mund të arrijë disa qindra kilobajt. Kufiri i madhësisë së mesazhit në Kafka kërkon që ne të parashikojmë saktë madhësinë e mesazhit dhe nëse është e nevojshme, i ndajmë ato, por ndarja është logjike, e lidhur me operacionet e biznesit.
Për shembull, ne i ndajmë mallrat që mbërrijnë në një makinë në kuti. Për operacionet sinkrone, ndahen mikroshërbime të veçanta dhe kryhet testimi i plotë i ngarkesës. Përdorimi i Kafkës na paraqiti me një sfidë tjetër - testimi i funksionimit të shërbimit tonë duke marrë parasysh integrimin e Kafkës i bën të gjitha testet e njësive tona asinkrone. Ne e zgjidhëm këtë problem duke shkruar metodat tona të shërbimeve duke përdorur Embedded Kafka Broker. Kjo nuk eliminon nevojën për të shkruar teste njësi për metoda individuale, por ne preferojmë të testojmë raste komplekse duke përdorur Kafka.
Vëmendje e madhe iu kushtua gjurmimit të regjistrave në mënyrë që TraceId-i i tyre të mos humbiste kur ndodhin përjashtime gjatë funksionimit të shërbimeve ose kur punoni me grupin Kafka. Dhe nëse nuk kishte probleme të veçanta me të parën, atëherë në rastin e dytë ne jemi të detyruar të regjistrojmë të gjitha TraceIds me të cilat erdhi grupi dhe të zgjedhim një për të vazhduar gjurmimin. Më pas, kur kërkon nga TraceId origjinal, përdoruesi do të zbulojë lehtësisht se me cilin gjurmim ka vazhduar.
Detyra 3. Nevoja për të ruajtur një sasi të madhe të dhënash: Më shumë se 1 miliard etiketa në vit vetëm për duhanin vijnë në X5. Ata kërkojnë qasje të vazhdueshme dhe të shpejtë. Në total, sistemi duhet të përpunojë rreth 10 miliardë regjistrime të historisë së lëvizjes së këtyre mallrave të etiketuara.
Për të zgjidhur problemin e tretë, u zgjodh baza e të dhënave NoSQL MongoDB. Ne kemi ndërtuar një copëz prej 5 nyjesh dhe secila nyje ka një Replica Set prej 3 serverësh. Kjo ju lejon të shkallëzoni sistemin horizontalisht, duke shtuar serverë të rinj në grup dhe të siguroni tolerancën e tij ndaj gabimeve. Këtu kemi hasur një problem tjetër - sigurimin e transaksioneve në grupin mongo, duke marrë parasysh përdorimin e mikroshërbimeve të shkallëzueshme horizontalisht. Për shembull, një nga detyrat e sistemit tonë është të identifikojë përpjekjet për të rishitur produkte me të njëjtat kode etiketimi. Këtu, mbivendosjet shfaqen me skanime të gabuara ose operacione të gabuara nga arkëtarët. Ne zbuluam se dublikata të tilla mund të ndodhin si brenda një grupi Kafka që përpunohet, ashtu edhe brenda dy grupeve që përpunohen paralelisht. Kështu, kontrollimi për dublikata duke pyetur në bazën e të dhënave nuk dha asgjë. Për çdo mikroshërbim problemin e kemi zgjidhur veçmas në bazë të logjikës së biznesit të këtij shërbimi. Për shembull, për kontrollet, kemi shtuar një kontroll brenda grupit dhe përpunim të veçantë për shfaqjen e dublikatave gjatë futjes.
Për të siguruar që puna e përdoruesve me historinë e operacioneve të mos ndikojë në asnjë mënyrë gjënë më të rëndësishme - funksionimin e proceseve tona të biznesit, ne kemi ndarë të gjitha të dhënat historike në një shërbim të veçantë me një bazë të dhënash të veçantë, i cili gjithashtu merr informacion përmes Kafkës. . Në këtë mënyrë, përdoruesit punojnë me një shërbim të izoluar pa ndikuar në shërbimet që përpunojnë të dhënat për operacionet e vazhdueshme.
Detyra 4: Ripërpunimi dhe monitorimi i radhës:
Në sistemet e shpërndara, problemet dhe gabimet lindin në mënyrë të pashmangshme në disponueshmërinë e bazave të të dhënave, radhëve dhe burimeve të jashtme të të dhënave. Në rastin e Marcus, burimi i gabimeve të tilla është integrimi me sistemet e jashtme. Ishte e nevojshme të gjendej një zgjidhje që do të lejonte kërkesa të përsëritura për përgjigje të gabuara me një kohë të caktuar, por në të njëjtën kohë të mos ndalonte përpunimin e kërkesave të suksesshme në radhën kryesore. Për këtë qëllim, u zgjodh koncepti i ashtuquajtur "riprovim i bazuar në temë". Për secilën temë kryesore, krijohen një ose më shumë tema të riprovës, të cilave u dërgohen mesazhe të gabuara dhe në të njëjtën kohë eliminohet vonesa në përpunimin e mesazheve nga tema kryesore. Skema e ndërveprimit -
Për të zbatuar një skemë të tillë, na nevojiteshin sa vijon: ta integronim këtë zgjidhje me Spring dhe të shmangnim dyfishimin e kodit. Gjatë shfletimit në internet, hasëm në një zgjidhje të ngjashme të bazuar në Spring BeanPostProccessor, por na u duk pa nevojë e rëndë. Ekipi ynë ka bërë një zgjidhje më të thjeshtë që na lejon të integrohemi në ciklin e pranverës për krijimin e konsumatorëve dhe të shtojmë gjithashtu Konsumatorët Riprovim. Ne ofruam një prototip të zgjidhjes sonë për ekipin e Pranverës, mund ta shihni . Numri i Konsumatorëve të Riprovimit dhe numri i përpjekjeve për çdo konsumator konfigurohen përmes parametrave, në varësi të nevojave të procesit të biznesit, dhe që gjithçka të funksionojë, mbetet vetëm shtimi i shënimit org.springframework.kafka.annotation.KafkaListener , e cila është e njohur për të gjithë zhvilluesit e Pranverës.
Nëse mesazhi nuk mund të përpunohej pas të gjitha përpjekjeve të riprovës, ai shkon te DLT (tema e shkronjës së vdekur) duke përdorur Spring DeadLetterPublishingRecoverer. Me kërkesë të mbështetjes, ne e zgjeruam këtë funksionalitet dhe krijuam një shërbim të veçantë që ju lejon të shikoni mesazhet e përfshira në DLT, stackTrace, traceId dhe informacione të tjera të dobishme rreth tyre. Për më tepër, monitorimi dhe alarmet u shtuan në të gjitha temat DLT, dhe tani, në fakt, shfaqja e një mesazhi në një temë DLT është një arsye për të analizuar dhe rregulluar një defekt. Kjo është shumë e përshtatshme - me emrin e temës, ne e kuptojmë menjëherë në cilin hap të procesit lindi problemi, i cili shpejton ndjeshëm kërkimin për shkakun e tij rrënjësor.
Kohët e fundit, ne kemi zbatuar një ndërfaqe që na lejon të ridërgojmë mesazhe duke përdorur mbështetjen tonë pasi të eliminojmë shkaqet e tyre (për shembull, të rivendosim funksionalitetin e sistemit të jashtëm) dhe, natyrisht, të vendosim defektin përkatës për analizë. Këtu janë të dobishme vetë-temat tona: për të mos rifilluar një zinxhir të gjatë përpunimi, mund ta rinisni atë nga hapi i dëshiruar.
Operacioni i platformës
Platforma është tashmë në funksionim produktiv, çdo ditë kryejmë dërgesa dhe dërgesa, lidhim qendra të reja shpërndarjeje dhe dyqane. Si pjesë e pilotimit, sistemi punon me grupet e produkteve “Duhani” dhe “Këpucët”.
I gjithë ekipi ynë merr pjesë në kryerjen e pilotimeve, analizon problemet e shfaqura dhe bën sugjerime për përmirësimin e produktit tonë, nga përmirësimi i regjistrave deri te proceset e ndryshimit.
Për të mos përsëritur gabimet tona, të gjitha rastet e gjetura gjatë pilotimit pasqyrohen në teste të automatizuara. Prania e një numri të madh të autotesteve dhe testeve të njësive ju lejon të kryeni testimin e regresionit dhe të instaloni një rregullim të drejtpërdrejtë fjalë për fjalë brenda disa orësh.
Tani ne vazhdojmë të zhvillojmë dhe përmirësojmë platformën tonë, dhe vazhdimisht përballemi me sfida të reja. Nëse jeni të interesuar, ne do të flasim për zgjidhjet tona në artikujt e mëposhtëm.
Burimi: www.habr.com