Ekde 2019, Rusio havas leĝon pri deviga etikedado. La leĝo ne validas por ĉiuj grupoj de varoj, kaj la datoj por la ekvalido de deviga etikedado por produktaj grupoj estas malsamaj. Tabako, ŝuoj kaj medikamentoj estos la unuaj submetitaj al deviga etikedado; aliaj produktoj estos aldonitaj poste, ekzemple, parfumo, teksaĵoj kaj lakto. Ĉi tiu leĝdona novigo instigis la disvolviĝon de novaj IT-solvoj, kiuj ebligos spuri la tutan vivĉenon de produkto de produktado ĝis aĉeto de la fina konsumanto, al ĉiuj partoprenantoj en la procezo: kaj la ŝtato mem kaj ĉiuj organizoj vendantaj varojn kun deviga etikedado.
En X5, la sistemo, kiu spuros etikeditajn varojn kaj interŝanĝos datumojn kun la ŝtato kaj provizantoj, nomiĝas "Marcus". Ni diru al vi en ordo kiel kaj kiu evoluigis ĝin, kio estas ĝia teknologia stako, kaj kial ni havas ion pri kio fieri.
Reala Alta Ŝarĝo
"Marcus" solvas multajn problemojn, la ĉefa estas la integriga interago inter X5-informsistemoj kaj la ŝtata informsistemo por etikeditaj produktoj (GIS MP) por spuri la movadon de etikeditaj produktoj. La platformo ankaŭ konservas ĉiujn etikedajn kodojn ricevitajn de ni kaj la tutan historion de la movado de ĉi tiuj kodoj tra objektoj, kaj helpas elimini re-gradadon de etikeditaj produktoj. Uzante la ekzemplon de tabakvaroj, kiuj estis inkluditaj en la unuaj grupoj de etikeditaj varoj, nur unu kamiono da cigaredoj enhavas ĉirkaŭ 600 pakojn, ĉiu el kiuj havas sian propran unikan kodon. Kaj la tasko de nia sistemo estas spuri kaj kontroli la laŭleĝecon de la movoj de ĉiu tia pakaĵo inter magazenoj kaj vendejoj, kaj finfine kontroli la akcepteblecon de ilia vendo al la fina aĉetanto. Kaj ni registras ĉirkaŭ 000 kontantajn transakciojn por horo, kaj ni ankaŭ devas registri kiel ĉiu tia pako eniris la vendejon. Tiel, konsiderante ĉiujn movojn inter objektoj, ni atendas dekojn da miliardoj da rekordoj jare.
Teamo M
Malgraŭ la fakto, ke Marcus estas konsiderata projekto ene de X5, ĝi estas efektivigita per produkta aliro. La teamo funkcias laŭ Scrum. La projekto komenciĝis lastan someron, sed la unuaj rezultoj venis nur en oktobro - nia propra teamo estis plene kunvenita, la sistema arkitekturo estis evoluigita kaj ekipaĵo estis aĉetita. Nun la teamo havas 16 homojn, ses el kiuj estas implikitaj en backend kaj fasado evoluado, tri el kiuj estas implikitaj en sistema analizo. Ses pliaj homoj okupiĝas pri manlibro, ŝarĝo, aŭtomatigita testado kaj prizorgado de produktoj. Krome, ni havas SRE-specialiston.
Ne nur programistoj skribas kodon en nia teamo; preskaŭ ĉiuj uloj scias kiel programi kaj skribi aŭtotestojn, ŝargi skriptojn kaj aŭtomatigajn skriptojn. Ni donas specialan atenton al ĉi tio, ĉar eĉ produkta subteno postulas altan nivelon de aŭtomatigo. Ni ĉiam provas konsili kaj helpi kolegojn, kiuj antaŭe ne programis, kaj doni al ili kelkajn malgrandajn taskojn por labori.
Pro la koronavirus-pandemio, ni translokigis la tutan teamon al fora laboro; la havebleco de ĉiuj iloj por disvolva administrado, la konstruita laborfluo en Jira kaj GitLab ebligis facile trapasi ĉi tiun etapon. La monatoj pasigitaj malproksime montris, ke la produktiveco de la teamo ne suferis kiel rezulto; por multaj, la komforto en la laboro pliiĝis, la nura afero mankis estis viva komunikado.
Fora teamkunveno
Renkontiĝoj dum fora laboro
Teknologia stako de la solvo
La norma deponejo kaj CI/KD-ilo por X5 estas GitLab. Ni uzas ĝin por koda stokado, kontinua testado kaj disvastigo por testaj kaj produktaj serviloj. Ni ankaŭ uzas la praktikon de koda revizio, kiam almenaŭ 2 kolegoj bezonas aprobi ŝanĝojn faritajn de la programisto al la kodo. Senmovaj kodaj analiziloj SonarQube kaj JaCoCo helpas nin konservi nian kodon pura kaj certigi la bezonatan nivelon de unutesta kovrado. Ĉiuj ŝanĝoj al la kodo devas trairi ĉi tiujn kontrolojn. Ĉiuj testaj skriptoj, kiuj estas rulitaj permane, estas poste aŭtomatigitaj.
Por la sukcesa efektivigo de komercaj procezoj de "Marcus", ni devis solvi kelkajn teknologiajn problemojn, pri ĉiu en ordo.
Tasko 1. La bezono de horizontala skaleblo de la sistemo
Por solvi ĉi tiun problemon, ni elektis mikroservan aliron al arkitekturo. Samtempe, estis tre grave kompreni la respondecajn kampojn de la servoj. Ni provis dividi ilin en komercajn operaciojn, konsiderante la specifaĵojn de la procezoj. Ekzemple, akcepto ĉe magazeno ne estas tre ofta, sed tre grandskala operacio, dum kiu necesas rapide akiri de la ŝtata reguligisto informojn pri la akceptataj varoj, kies nombro en unu livero atingas 600000 XNUMX. , kontrolu la akcepteblecon akcepti ĉi tiun produkton en la magazenon kaj redonu ĉiujn necesajn informojn por la magazena aŭtomatiga sistemo. Sed sendo de magazenoj havas multe pli grandan intensecon, sed samtempe funkcias kun malgrandaj volumoj de datumoj.
Ni efektivigas ĉiujn servojn sur sennacia bazo kaj eĉ provas dividi internajn operaciojn en paŝojn, uzante kion ni nomas Kafkaj mem-temoj. Ĉi tio okazas kiam mikroservo sendas mesaĝon al si mem, kio ebligas al vi ekvilibrigi la ŝarĝon pri pli intensivaj operacioj kaj simpligas produktan prizorgadon, sed pli pri tio poste.
Ni decidis apartigi modulojn por interago kun eksteraj sistemoj en apartajn servojn. Ĉi tio ebligis solvi la problemon de ofte ŝanĝiĝantaj API-oj de eksteraj sistemoj, preskaŭ sen efiko al servoj kun komerca funkcieco.
Ĉiuj mikroservoj estas deplojitaj en OpenShift-areto, kiu solvas ambaŭ la problemon de grimpi ĉiun mikroservon kaj ebligas al ni ne uzi triajn ilojn de Service Discovery.
Tasko 2. La bezono konservi altan ŝarĝon kaj tre intensan datuman interŝanĝon inter platformaj servoj: Nur dum la projekta lanĉfazo, proksimume 600 operacioj je sekundo estas faritaj. Ni atendas, ke ĉi tiu valoro pliiĝos al 5000 operacioj/sekundoj dum podetalaj butikoj konektas al nia platformo.
Ĉi tiu problemo estis solvita per deplojado de Kafka-grupo kaj preskaŭ tute forlasante sinkronan interagadon inter la mikroservoj de la platformo. Ĉi tio postulas tre zorgeman analizon de la sistemaj postuloj, ĉar ne ĉiuj operacioj povas esti nesinkronaj. Samtempe, ni ne nur transdonas eventojn per la makleristo, sed ankaŭ transdonas ĉiujn postulatajn komercajn informojn en la mesaĝo. Tiel, la mesaĝgrandeco povas atingi plurajn centojn da kilobajtoj. La mesaĝgranda limo en Kafka postulas, ke ni precize antaŭdiri la mesaĝgrandecon, kaj se necese, ni dividas ilin, sed la divido estas logika, rilata al komercaj operacioj.
Ekzemple, ni dividas varojn, kiuj alvenas en aŭtomobilo, en skatolojn. Por sinkronaj operacioj, apartaj mikroservoj estas asignitaj kaj ĝisfunda ŝarĝtestado estas farita. Uzado de Kafka prezentis al ni alian defion - provi la funkciadon de nia servo konsiderante la Kafka-integriĝon faras ĉiujn niajn unutestojn nesinkronajn. Ni solvis ĉi tiun problemon skribante niajn proprajn utilajn metodojn uzante Embedded Kafka Broker. Ĉi tio ne forigas la bezonon verki unutestojn por individuaj metodoj, sed ni preferas testi kompleksajn kazojn uzante Kafka.
Multe da atento estis pagita al spurado de protokoloj por ke ilia TraceId ne perdiĝus kiam okazas esceptoj dum funkciado de servoj aŭ dum laboro kun Kafka batch. Kaj se ne estis specialaj aferoj kun la unua, tiam en la dua kazo ni estas devigitaj ensaluti ĉiujn TraceIds, kun kiuj venis la aro, kaj elekti unu por daŭrigi spuradon. Tiam, serĉante per la originala TraceId, la uzanto facile ekscios, per kiu la spurado daŭris.
Tasko 3. La bezono stoki grandan kvanton da datumoj: Pli ol 1 miliardo da etikedoj jare nur por tabako venas al X5. Ili postulas konstantan kaj rapidan aliron. Entute, la sistemo devas prilabori ĉirkaŭ 10 miliardojn da registroj de la movada historio de ĉi tiuj etikeditaj varoj.
Por solvi la trian problemon, la NoSQL-datumbazo MongoDB estis elektita. Ni konstruis breĉeton de 5 nodoj kaj ĉiu nodo havas Replikan Aron de 3-serviloj. Ĉi tio ebligas al vi grimpi la sistemon horizontale, aldonante novajn servilojn al la areto, kaj certigi ĝian misfunkciadon. Ĉi tie ni renkontis alian problemon - certigi transakcon en la mongo-grupo, konsiderante la uzon de horizontale skaleblaj mikroservoj. Ekzemple, unu el la taskoj de nia sistemo estas identigi provojn revendi produktojn kun la samaj etikedkodoj. Ĉi tie aperas supermetaĵoj kun eraraj skanadoj aŭ eraraj operacioj de kasistoj. Ni trovis, ke tiaj duplikatoj povas okazi ambaŭ ene de unu Kafka aro estanta prilaborita, kaj ene de du aroj estanta procesitaj paralele. Tiel, kontroli duplikatojn per pridemandado de la datumbazo donis nenion. Por ĉiu mikroservo, ni solvis la problemon aparte surbaze de la komerca logiko de ĉi tiu servo. Ekzemple, por ĉekoj, ni aldonis ĉekon ene de aro kaj aparta prilaborado por la apero de duplikatoj dum enmetado.
Por certigi, ke la laboro de uzantoj kun la historio de operacioj neniel influas la plej gravan aferon - la funkciadon de niaj komercaj procezoj, ni apartigis ĉiujn historiajn datumojn en apartan servon kun aparta datumbazo, kiu ankaŭ ricevas informojn per Kafka. . Tiel, uzantoj laboras kun izolita servo sen tuŝi la servojn, kiuj prilaboras datumojn por daŭraj operacioj.
Tasko 4: Vico-reprocesado kaj monitorado:
En distribuitaj sistemoj, problemoj kaj eraroj neeviteble ekestas en la havebleco de datumbazoj, atendovicoj kaj eksteraj datenfontoj. En la kazo de Marcus, la fonto de tiaj eraroj estas integriĝo kun eksteraj sistemoj. Necesis trovi solvon, kiu ebligus ripetajn petojn por eraraj respondoj kun iu specifita tempodaŭro, sed samtempe ne ĉesu prilabori sukcesajn petojn en la ĉefa vico. Por tiu celo, la tielnomita "temo bazita reprovo" koncepto estis elektita. Por ĉiu ĉefa temo estas kreitaj unu aŭ pluraj reprovaj temoj, al kiuj estas sendataj eraraj mesaĝoj kaj samtempe la malfruo en prilaborado de mesaĝoj el la ĉefa temo estas forigita. Skemo de interagado -
Por efektivigi tian skemon, ni bezonis la jenon: integri ĉi tiun solvon kun Spring kaj eviti kodon duobligon. Navigante en la reto, ni trovis similan solvon bazitan sur Spring BeanPostProccessor, sed ĝi ŝajnis al ni nenecese maloportuna. Nia teamo faris pli simplan solvon, kiu permesas nin integri en la Printempan ciklon por krei konsumantojn kaj aldone aldoni Retry Consumers. Ni proponis prototipon de nia solvo al la Spring-teamo, vi povas vidi ĝin . La nombro da Retry Consumers kaj la nombro da provoj por ĉiu konsumanto estas agordita per parametroj, depende de la bezonoj de la komerca procezo, kaj por ke ĉio funkciu, restas nur aldoni la komentarion org.springframework.kafka.annotation.KafkaListener. , kiu estas konata al ĉiuj Spring-programistoj.
Se la mesaĝo ne povus esti prilaborita post ĉiuj reprovoj, ĝi iras al DLT (morta letera temo) uzante Spring DeadLetterPublishingRecoverer. Laŭ peto de subteno, ni vastigis ĉi tiun funkcion kaj kreis apartan servon, kiu ebligas al vi vidi mesaĝojn inkluzivitajn en DLT, stackTrace, traceId kaj aliajn utilajn informojn pri ili. Krome, monitorado kaj atentigoj estis aldonitaj al ĉiuj DLT-temoj, kaj nun, fakte, la apero de mesaĝo en DLT-temo estas kialo por analizi kaj ripari difekton. Ĉi tio estas tre oportuna - laŭ la nomo de la temo, ni tuj komprenas, je kiu paŝo de la procezo aperis la problemo, kio signife plirapidigas la serĉon de ĝia radika kaŭzo.
Plej lastatempe, ni efektivigis interfacon, kiu ebligas al ni resendi mesaĝojn uzante nian subtenon post forigi iliajn kaŭzojn (ekzemple, restarigi la funkciojn de la ekstera sistemo) kaj, kompreneble, establi la respondan difekton por analizo. Jen kie niaj mem-temoj utilas: por ne rekomenci longan prilaboran ĉenon, vi povas rekomenci ĝin de la dezirata paŝo.
Platforma Operacio
La platformo jam estas en produktema funkciado, ĉiutage ni faras liveraĵojn kaj sendojn, ligas novajn distribucentrojn kaj vendejojn. Kiel parto de la piloto, la sistemo funkcias kun la produktgrupoj "Tabako" kaj "Ŝuoj".
Nia tuta teamo partoprenas en farado de pilotoj, analizas emerĝajn problemojn kaj faras sugestojn por plibonigi nian produkton, de plibonigo de protokoloj ĝis ŝanĝado de procezoj.
Por ne ripeti niajn erarojn, ĉiuj kazoj trovitaj dum la piloto reflektiĝas en aŭtomatigitaj testoj. La ĉeesto de granda nombro da aŭtotestoj kaj unuotestoj ebligas al vi fari regrestestojn kaj instali varman riparo laŭvorte ene de kelkaj horoj.
Nun ni daŭre disvolvas kaj plibonigas nian platformon, kaj konstante alfrontas novajn defiojn. Se vi interesiĝas, ni parolos pri niaj solvoj en la sekvaj artikoloj.
fonto: www.habr.com