„Gangandi í skónum mínum“ - bíddu, eru þeir merktir?

Frá árinu 2019 hafa Rússland haft lög um skyldumerkingar. Lögin gilda ekki um alla vöruflokka og gildistökudagsetningar skyldumerkinga vöruflokka eru mismunandi. Tóbak, skór og lyf verða fyrst merkingarskyldar, aðrar vörur bætast við síðar, til dæmis ilmvatn, vefnaðarvörur og mjólk. Þessi nýbreytni í löggjöf varð tilefni til þróunar nýrra upplýsingatæknilausna sem gera það mögulegt að fylgjast með allri lífskeðju vöru frá framleiðslu til kaups hjá endanlegum neytendum, til allra þátttakenda í ferlinu: bæði ríkið sjálft og allar stofnanir sem selja vörur með lögboðin merking.

Í X5 er kerfið sem mun rekja merktar vörur og skiptast á gögnum við ríki og birgja kallað „Marcus“. Við skulum segja þér í röð hvernig og hver þróaði það, hver tæknistafla hans er og hvers vegna við höfum eitthvað til að vera stolt af.

Alvöru HighLoad

„Marcus“ leysir mörg vandamál, það helsta er samþættingarsamspil X5 upplýsingakerfa og ríkisupplýsingakerfis fyrir merktar vörur (GIS MP) til að fylgjast með flutningi merktra vara. Vettvangurinn geymir einnig alla merkingarkóða sem okkur berast og alla sögu flutnings þessara kóða yfir hluti og hjálpar til við að koma í veg fyrir endurflokkun á merktum vörum. Með því að nota dæmið um tóbaksvörur, sem voru innifalin í fyrstu flokkunum af merktum vörum, inniheldur aðeins einn vörubíll af sígarettum um 600 pakkningar, sem hver um sig hefur sinn einstaka kóða. Og verkefni kerfisins okkar er að fylgjast með og sannreyna lögmæti hreyfinga hvers slíks pakka á milli vöruhúsa og verslana og að lokum sannreyna hvort sala þeirra sé leyfileg til lokakaupanda. Og við skráum um 000 staðgreiðslufærslur á klukkustund og við þurfum líka að skrá hvernig hver slíkur pakki kom inn í verslunina. Þannig, að teknu tilliti til allra hreyfinga á milli hluta, eigum við von á tugmilljarða færslum á ári.

Lið M

Þrátt fyrir að Marcus teljist vera verkefni innan X5 er verið að innleiða það með vörunálgun. Liðið vinnur samkvæmt Scrum. Verkefnið hófst síðasta sumar, en fyrstu niðurstöður komu fyrst í október - okkar eigin teymi var fullbúið, kerfisarkitektúrinn þróaður og búnaður keyptur. Nú eru 16 manns í teymið, þar af sex sem taka þátt í bakenda- og framendaþróun, þar af þrír sem taka þátt í kerfisgreiningu. Sex fleiri taka þátt í handbók, hleðslu, sjálfvirkum prófunum og vöruviðhaldi. Auk þess erum við með SRE sérfræðing.

Ekki aðeins verktaki skrifa kóða í teymið okkar; næstum allir krakkar vita hvernig á að forrita og skrifa sjálfvirkar prófanir, hlaða forskriftir og sjálfvirkniforskriftir. Við gefum þessu sérstaka athygli, þar sem jafnvel vörustuðningur krefst mikillar sjálfvirkni. Við reynum alltaf að ráðleggja og aðstoða samstarfsmenn sem hafa ekki forritað áður og gefa þeim smá verkefni til að vinna í.

Vegna kórónuveirufaraldursins fluttum við allt teymið yfir í fjarvinnu; framboð á öllum verkfærum fyrir þróunarstjórnun, innbyggða vinnuflæðið í Jira og GitLab gerði það mögulegt að komast auðveldlega yfir þetta stig. Mánuðirnir sem eyddir voru í fjarska sýndu að framleiðni teymisins varð ekki fyrir því; fyrir marga jókst þægindin í vinnunni, það eina sem vantaði voru samskipti í beinni.

Fjarteymisfundur

Fundir við fjarvinnu

Tæknistafla lausnarinnar

Staðlaða geymslan og CI/CD tólið fyrir X5 er GitLab. Við notum það til að geyma kóða, stöðugar prófanir og dreifingu til að prófa og framleiða netþjóna. Við notum líka aðferðina við endurskoðun kóðans, þegar að minnsta kosti 2 samstarfsmenn þurfa að samþykkja breytingar sem framkvæmdaraðili gerir á kóðanum. Static kóða greiningartæki SonarQube og JaCoCo hjálpa okkur að halda kóðanum okkar hreinum og tryggja tilskilið stig einingarprófunar. Allar breytingar á kóðanum verða að fara í gegnum þessar athuganir. Allar prófunarforskriftir sem keyrðar eru handvirkt eru síðan sjálfvirkar.

Til að „Marcus“ gæti innleitt viðskiptaferla farsællega þurftum við að leysa fjölda tæknilegra vandamála, um hvert í röð.

Verkefni 1. Þörfin fyrir láréttan sveigjanleika kerfisins

Til að leysa þetta vandamál völdum við örþjónustuaðferð við arkitektúr. Jafnframt var mjög mikilvægt að átta sig á ábyrgðarsviðum þjónustunnar. Við reyndum að skipta þeim í viðskiptarekstur með hliðsjón af sérkennum ferlanna. Til dæmis er móttaka í vöruhúsi ekki mjög tíð, heldur mjög stór aðgerð, þar sem nauðsynlegt er að fá fljótt frá eftirlitsstofnun ríkisins upplýsingar um þær einingar sem verið er að taka við, en fjöldi þeirra í einni afhendingu nær 600000 , athugaðu hvort það sé leyfilegt að samþykkja þessa vöru inn á vöruhúsið og skilaðu öllum nauðsynlegum upplýsingum fyrir sjálfvirkni vöruhússkerfisins. En sending frá vöruhúsum hefur mun meiri styrkleika, en starfar á sama tíma með litlu magni af gögnum.

Við innleiðum alla þjónustu á ríkisfangslausum grunni og reynum jafnvel að skipta innri starfsemi í þrep með því að nota það sem við köllum Kafka sjálfsefni. Þetta er þegar örþjónusta sendir sjálfri sér skilaboð sem gerir þér kleift að jafna álagið á auðlindafrekari rekstur og einfaldar vöruviðhald, en meira um það síðar.

Við ákváðum að aðgreina einingar fyrir samskipti við ytri kerfi í aðskildar þjónustur. Þetta gerði það mögulegt að leysa vandamálið við að breyta oft API utanaðkomandi kerfa, með nánast engin áhrif á þjónustu með viðskiptavirkni.

Allar örþjónustur eru notaðar í OpenShift klasa, sem leysir bæði vandamálið við að stækka hverja örþjónustu og gerir okkur kleift að nota ekki þjónustuuppgötvunarverkfæri þriðja aðila.

Verkefni 2. Þörfin á að viðhalda miklu álagi og mjög ákafurum gagnaskiptum milli pallþjónustu: Á meðan á ræsingu verkefnisins stendur eru framkvæmdar um 600 aðgerðir á sekúndu. Við gerum ráð fyrir að þetta gildi aukist í 5000 ops/sek eftir því sem verslanir tengjast vettvangi okkar.

Þetta vandamál var leyst með því að dreifa Kafka þyrpingum og hætta nánast alveg við samstillt samspil milli örþjónustu vettvangsins. Þetta krefst mjög nákvæmrar greiningar á kerfiskröfum, þar sem ekki geta allar aðgerðir verið ósamstilltar. Á sama tíma sendum við ekki aðeins atburði í gegnum miðlarann, heldur sendum við einnig allar nauðsynlegar viðskiptaupplýsingar í skilaboðunum. Þannig getur stærð skilaboðanna orðið nokkur hundruð kílóbæt. Stærðartakmörk skilaboða í Kafka krefjast þess að við spáum nákvæmlega fyrir um stærð skilaboða og ef nauðsyn krefur skiptum við þeim, en skiptingin er rökrétt, tengd viðskiptarekstri.
Til dæmis skiptum við vöru sem kemur í bíl í kassa. Fyrir samstilltar aðgerðir er aðskildum örþjónustu úthlutað og ítarlegar álagsprófanir framkvæmdar. Að nota Kafka gaf okkur aðra áskorun - að prófa rekstur þjónustu okkar með hliðsjón af Kafka samþættingunni gerir öll einingaprófin okkar ósamstillt. Við leystum þetta vandamál með því að skrifa okkar eigin gagnsemisaðferðir með því að nota Embedded Kafka Broker. Þetta útilokar ekki þörfina á að skrifa einingapróf fyrir einstakar aðferðir, en við viljum frekar prófa flókin tilvik með Kafka.

Mikil áhersla var lögð á að rekja annála svo að TraceId þeirra myndi ekki glatast þegar undantekningar eiga sér stað við rekstur þjónustu eða þegar unnið er með Kafka lotu. Og ef það voru engin sérstök vandamál með það fyrsta, þá neyðumst við í öðru tilvikinu til að skrá öll TraceIds sem lotan kom með og velja einn til að halda áfram að rekja. Síðan, þegar leitað er með upprunalegu TraceId, mun notandinn auðveldlega komast að því með hvaða hætti rakningin hélt áfram.

Verkefni 3. Þörfin á að geyma mikið magn af gögnum: Meira en 1 milljarður merkimiða á ári fyrir tóbak eingöngu kemur til X5. Þeir krefjast stöðugs og skjóts aðgangs. Alls þarf kerfið að vinna úr um 10 milljörðum skráa yfir ferðasögu þessara merktu vara.

Til að leysa þriðja vandamálið var NoSQL gagnagrunnurinn MongoDB valinn. Við höfum smíðað brot af 5 hnútum og hver hnút er með eftirmyndarsett af 3 netþjónum. Þetta gerir þér kleift að skala kerfið lárétt, bæta nýjum netþjónum við þyrpinguna og tryggja bilanaþol þess. Hér lentum við í öðru vandamáli - að tryggja viðskiptamöguleika í mongóklasanum, að teknu tilliti til notkunar á láréttum skalanlegum örþjónustum. Til dæmis er eitt af verkefnum kerfisins okkar að bera kennsl á tilraunir til að endurselja vörur með sömu merkingarkóðum. Hér birtast yfirlög með röngum skönnunum eða röngum aðgerðum gjaldkera. Við komumst að því að slíkar afritanir geta átt sér stað bæði innan einnar Kafka lotu sem verið er að vinna úr og innan tveggja lota sem eru unnar samhliða. Þannig að athuga með tvítekningar með því að spyrjast fyrir um gagnagrunninn gaf ekki neitt. Fyrir hverja örþjónustu leystum við vandamálið sérstaklega út frá viðskiptarökfræði þessarar þjónustu. Til dæmis, fyrir ávísanir, bættum við við ávísun inni í lotu og aðskildum vinnslu fyrir útlit afrita við innsetningu.

Til að tryggja að vinna notenda með rekstrarsögu hafi ekki á nokkurn hátt áhrif á það mikilvægasta - virkni viðskiptaferla okkar, höfum við aðskilið öll söguleg gögn í sérstaka þjónustu með sérstökum gagnagrunni sem tekur einnig við upplýsingum í gegnum Kafka . Þannig vinna notendur með einangraða þjónustu án þess að hafa áhrif á þá þjónustu sem vinnur úr gögnum fyrir áframhaldandi rekstur.

Verkefni 4: Endurvinnsla og eftirlit með biðröð:

Í dreifðum kerfum koma óhjákvæmilega upp vandamál og villur í framboði gagnagrunna, biðraða og ytri gagnagjafa. Í tilfelli Marcus er uppspretta slíkra villna samþætting við ytri kerfi. Nauðsynlegt var að finna lausn sem myndi leyfa endurteknar beiðnir um rangar svörun með einhverjum tilteknum tímamörkum, en á sama tíma ekki hætta að vinna úr heppnuðum beiðnum í aðalröðinni. Í þessu skyni var svokallað „topic based retry“ hugtakið valið. Fyrir hvert aðalviðfangsefni eru búnir til eitt eða fleiri endurreynsluefni sem villuskilaboð eru send til og um leið er eytt seinkun á afgreiðslu skilaboða frá aðalefninu. Samskiptaáætlun -

Til að innleiða slíkt kerfi þurftum við eftirfarandi: að samþætta þessa lausn við Spring og forðast tvíverknað kóða. Þegar við vöktum um vefinn rákumst við á svipaða lausn byggða á Spring BeanPostProccessor, en hún þótti okkur óþarflega fyrirferðarmikil. Teymið okkar hefur búið til einfaldari lausn sem gerir okkur kleift að samþætta í vorferlinu til að búa til neytendur og bæta að auki við Reyndu neytendur aftur. Við buðum Spring-liðinu frumgerð af lausninni okkar, þú getur séð það hér. Fjöldi neytenda sem reyndu aftur og fjöldi tilrauna fyrir hvern neytanda er stilltur í gegnum færibreytur, allt eftir þörfum viðskiptaferlisins, og til að allt virki er allt sem eftir er að bæta við athugasemdinni org.springframework.kafka.annotation.KafkaListener , sem allir Spring forritarar þekkja.

Ef ekki tókst að vinna skilaboðin eftir allar tilraunir aftur, fara þau í DLT (dead letter topic) með Spring DeadLetterPublishingRecoverer. Að beiðni um stuðning útvíkkuðum við þessa virkni og bjuggum til sérstaka þjónustu sem gerir þér kleift að skoða skilaboð sem eru í DLT, stackTrace, traceId og öðrum gagnlegum upplýsingum um þau. Auk þess var vöktun og viðvörun bætt við öll DLT efni, og nú er í raun birting skilaboða í DLT efni ástæða til að greina og laga galla. Þetta er mjög þægilegt - með nafni efnisins skiljum við strax á hvaða stigi ferlisins vandamálið kom upp, sem flýtir verulega fyrir leitinni að rótarorsökinni.

Nú síðast höfum við innleitt viðmót sem gerir okkur kleift að senda skilaboð aftur með stuðningi okkar eftir að hafa útrýmt orsökum þeirra (til dæmis endurheimt virkni ytra kerfisins) og að sjálfsögðu komið á samsvarandi galla til greiningar. Þetta er þar sem sjálfsefni okkar koma sér vel: til að endurræsa ekki langa vinnslukeðju geturðu endurræst hana frá æskilegu skrefi.

Rekstur palla

Pallurinn er nú þegar í afkastamiklum rekstri, á hverjum degi framkvæmum við afgreiðslur og sendingar, tengjum nýjar dreifingarmiðstöðvar og verslanir. Sem hluti af tilraunaverkefninu vinnur kerfið með vöruflokkunum „Tóbak“ og „Skór“.

Allt teymið okkar tekur þátt í að framkvæma tilraunir, greinir vandamál sem koma upp og kemur með tillögur til að bæta vöruna okkar, allt frá því að bæta annála til að breyta ferlum.

Til þess að endurtaka ekki mistök okkar endurspeglast öll tilvik sem finnast meðan á fluginu stóð í sjálfvirkum prófunum. Tilvist fjölda sjálfvirkra prófana og einingaprófa gerir þér kleift að framkvæma aðhvarfspróf og setja upp flýtileiðréttingu bókstaflega innan nokkurra klukkustunda.

Nú höldum við áfram að þróa og bæta vettvang okkar og stöndum stöðugt frammi fyrir nýjum áskorunum. Ef þú hefur áhuga munum við tala um lausnir okkar í eftirfarandi greinum.

Heimild: www.habr.com