«Walking in my shoes» — oota, kas need on märgistatud?

Alates 2019. aastast kehtib Venemaal kohustusliku märgistamise seadus. Seadus ei kehti kõigi kaupade rühmade kohta ning kohustusliku märgistamise jõustumise tähtajad erinevatele kaugroupadele on erinevad. Esmalt kuuluvad kohustuslikule märgistamisele tubakas, jalatsid, ravimid, hiljem lisanduvad ka teised tooted, näiteks parfüümid, tekstiil ja piim. See seadusandlik uuendus on käivitanud uute IT-lahenduste väljatöötamise, mis võimaldavad jälgida kauba eluiga tootmisest kuni lõpptarbijani, kõikide protsessis osalejate jaoks: nii riik kui ka kõik organisatsioonid, kes müüvad kohustusliku märgistamisega kaupu.

X5-s sai süsteem, mis jälgib märgistatud kaupu ja vahetab andmeid riigi ja tarnijatega, nimeks "Markus". Räägime järjestikku, kuidas ja kes seda arendas, milline on tema tehnoloogia toetav struktuur ja miks meil on põhjust uhkust tunda.

Reaalne HighLoad

"Markus" lahendab mitmeid ülesandeid, peamine neist on integratsioonitegevus X5 teabelehtede ja riikliku märgistatud toodete teabe süsteemi (GIS MP) vahel, et jälgida märgistatud toodete liikumist. Lisaks salvestab platvorm kõik meile laekunud märgistuskoodid ja nende koodide liikumise ajalugu objekte pidi, aitab kõrvaldada märgistatud toodete valejaotuse. Näiteks tubakatoodete osas, mis kuulusid esimesse märgistatud kaupade rühma, sisaldab üks kaubik sigarette umbes 600 000 pakki, millest igaühel on oma ainulaadne kood. Ja meie süsteemi ülesanne on jälgida ja kontrollida iga sellise paki seaduslikkust liikumise osas ladude ja poodide vahel, ning lõpuks kontrollida, kas nende müük lõpptarbijale on lubatud. Kassatehingute puhul fikseerime umbes 125 000 tunni kohta ning tuleb veel fikseerida ka see, kuidas iga selline pakk poodi jõudis. Seega, arvestades kõiki objekte vahepealseid liikumisi, ootame aastas kümneid miljardeid kirjeid.

Meeskond M

Ehkki 'Markus' on projektina osa H5-st, viiakse seda ellu toote lähenemise abil. Meeskond töötab Scrum meetodil. Projekti algus oli eelmise aasta suvel, kuid esimesed tulemused ilmusid alles oktoobris – moodustati täielikult omakäeliselt meeskond, arendati välja süsteemi arhitektuur ja osteti seadmed. Praegu on meeskonnas 16 inimest, kellest kuus tegelevad backend ja frontend arendamisega, kolm süsteemianalüüsi ning veel kuus tegelevad käsitsi, koormus- ja automatiseeritud testimise ning toote toetamisega. Lisaks on meie seas SRE-spetsialist.

Meie meeskonnas kirjutavad koodi mitte ainult arendajad, vaid praktiliselt kõik kolleegid oskavad programmeerida ja kirjutavad automatiseerimisteste, koormusskeeme ja automatiseerimise skripte. Me pöörame sellele erilist tähelepanu, kuna isegi toote hooldus nõuab kõrget automatiseerimise taset. Kolleegidele, kes polnud varem programmeerinud, anname alati nõu ja abi, andes neile väiksemaid ülesandeid.

Koroonaviiruse pandeemia tõttu viisime kogu meeskonna üle kaugtööle, kõik arenduse juhtimiseks vajalikud tööriistad, töötav töövoog Jira-s ja GitLab-is, võimaldasid selle etapi kergesti läbida. Kaugtööl veedetud kuukajad näitasid, et meeskonna tootlikkus ei langenud, paljudele tõusis töö mugavus, ainus asi, mis puudu on, on elav suhtlemine.

Meeskonna koosolek enne kaugtööd

Koosolekud kaugtööl

Lahenduse tehnoloogia alus

H5 standardne hoidla ja CI/CD tööriist on GitLab. Kasutame seda koodi hoidmiseks, pidevaks testimiseks ja testimis- ja tootmiserveritesse paigutamiseks. Samuti praktiseerime koodi ülevaatust, kus vähemalt kaks kolleegi peavad arendaja koodimuudatused heaks kiitma. Statistilised koodi analüsaatorid SonarQube ja JaCoCo aitavad meil koodi puhtana hoida ja tagada nõutava taseme unit-testide katvust. Kõik koodimuudatused peavad kindlasti läbi käima nende kontrollide. Kõik käsitsi kontrollitud teststsenaariumid automatiseeritakse hiljem.

Eduka äriprotsessi täitmiseks 'Markus'iga pidime lahendama mitmeid tehnoloogilisi ülesandeid, millest räägime järjestikku.

Ülesanne 1. Süsteemi horisontaalse skaleeritavuse vajadus

Selle ülesande lahendamiseks valisime mikroteenuste arhitektuuri lähenemise. Selle juures oli väga tähtis mõista teenuste vastutuse valdkondi. Püüdsime neid jagada äritehingute järgi, arvestades protsesside spetsiifikat. Näiteks inventuuri vastuvõtt laos on haruldane, kuid mahukas operatsioon, mille käigus on oluline võimalikult kiiresti saada riiklikult reguleerivalt asutuselt teavet vastuvõetavate kaupade üksuste kohta, kus ühe saatmise kogus võib ulatuda kuni 600 000, kontrollida kauba vastuvõtmise lubatavust laos ning edastada kogu vajalik teave laotehnika süsteemile. Kuid lao väljastamine toimub palju suurema intensiivsuse juures, kuid sellega seondub väiksemate andmemahtude töötlemine.

Kõik teenused rakendame stateless põhimõttel ja püüame isegi sisemisi operatsioone jagada sammudeks, kasutades meie enda nimel self-teemasid Kafka. See on olukord, kus mikroteenus saadab sõnumi endale, mis aitab tasakaalustada koormust ressursside nõudlikumate operatsioonide puhul ja lihtsustab toote hooldust, kuid sellest räägime hiljem.

Otsustasime eraldada eraldi teenustesse moodulid, mis suhtlevad välistest süsteemidest. See võimaldas lahendada sageli muutuva välistesüsteemide API probleemi, praktiliselt mõjutamata ärifunktsionaalsusega teenuseid.

Kõik mikroteenused paigaldatakse OpenShifti klastrisse, mis lahendab iga mikroteenuse skaleerimise probleemi ning võimaldab meil mitte kasutada kolmandate osapoolte teenuste avastamise tööriistu.

Ülesanne 2. Vajadus hoida kõrget koormust ja väga intensiivset andmevahetust platvormi teenuste vahel: ainult projekti käivitamise faasis toimub umbes 600 operatsiooni sekundis. Ootame selle näitaja suurenemist kuni 5000 op/sec loomisel kaubandusobjektide meie platvormiga liitumise käigus.

Selle ülesande lahendamiseks rakendati Kafka klastrit ja peaaegu täielikult loobuti platformi mikroteenuste vahelisest sünkroonsest suhtlemisest. See nõuab süsteemi nõuete väga tähelepanelikku analüüsi, kuna mitte kõik toimingud ei saa olla asünkroonsed. Samuti ei edasta me lihtsalt sündmusi vahendaja kaudu, vaid edastame sõnumis kogu vajaliku äriteabe. Seetõttu võib sõnumi suurus ulatuda sadadesse kilobaitidesse. Kafka sõnumite mahupiirang nõuab meilt sõnumite suuruste täpset prognoosimist ja hädaolukordade korral jagame neid, kuigi jagamine on loogiline ning seotud äritegevustega.
Näiteks toote, mis on jõudnud autoga, jagame kastidesse. Sünkroonsete toimingute jaoks eraldatakse eraldi mikroteenused ja viiakse läbi põhjalik koormustestimine. Kafka kasutamine esitas meile uue väljakutse — meie teenuse töö kontrollimine koos Kafka integreerimisega muudab kõik meie unit-testid asünkroonseteks. Selle ülesande lahendamiseks kirjutasime enda abimeetodid Using Embedded Kafka Broker. See ei ocean't tühista vajadust kirjutada unit-teste eraldi meetodite jaoks, kuid keerulisi juhtumeid eelistame testida Kafka kasutamisel.

Keskendume logide jälgimisele, et nende TraceId ei kaoks teenuste töös tekkivate erandite või Kafka batch'i töötlemise käigus. Kui esimesega ei tekkinud erilisi probleeme, siis teise puhul peame logima kõik TraceId, millega batch saabus, ja valima ühe jätkamiseks jälgimisel. Nii suudab kasutaja algse TraceId järgi otsides kergesti leida, millega jälgimine jätkus.

Ülesanne 3. Vajadus salvestada suures koguses andmeid: üle 1 miljardi märgistuse aastas ainult tubaka kohta tuleb X5. Neid tuleb pidevalt ja kiiresti kätte saada. Kokku peab süsteem töötlema umbes 10 miljardit kirjet märgistega toodete andmete ajaloos.

Kolmanda ülesande lahendamiseks valiti NoSQL andmebaas MongoDB. Meie süsteem on üles ehitatud 5 nodi shardist ja igas nodis on Replica Set 3 serveriga. See võimaldab süsteemi horisontaalselt skaleerida, lisades uusi servereid konstruktsiooni ja tagada selle talitlushäire kindel. Siin seisisime silmitsi teise probleemiga – tehingute tagamise tagamise Mongo klastris, arvestades horisontaalselt skaleeritavate mikroteenuste kasutamist. Näiteks on üheks meie süsteemi ülesandeks tuvastada kauba korduvmüümise katseid sama märkekoodiga. Siit tekivad probleemid vale skaneerimise või vale kassaprotseduuri tõttu. Oleme avastanud, et sellised dubleerimised võivad tekkida nii ühe töötleva Kafka partii sees kui ka kahe paralleelselt töödeldava partii vahel. Seega ei andnud duplikaatide kontrollimine andmebaasi päringu kaudu mitte midagi. Iga mikroteenuse puhul lahendasime probleemi eraldi, lähtudes selle teenuse äri loogikast. Näiteks, tšekkide puhul lisasime kontrolli partii sees ja eraldi töötlemise duplikaatide ilmnemiseks sisestamisel.

Et kasutajate tegevus operatsioonide ajaloos ei mõjutaks meie äri protsesside põhilist toimimist, eraldasime kõik ajaloolised andmed eraldi teenuseks koos eraldi andmebaasiga, mis samuti saab teavet üle Kafka. Nii saavad kasutajad töötada eraldi teenusega, ilma et see mõjutaks teenuseid, mis töötlevad andmeid praeguste operatsioonide kohta.

Ülesanne 4. Järjestuste uuesti töötlemine ja jälgimine:

Jaotatud süsteemides tekivad vältimatult probleemid ja vigade esitamisega andmebaaside, järjekordade ja väliste andmeallikate kättesaadavuses. 'Markuse' puhul on selliste vigade allikaks integreerimine väliste süsteemidega. Oli vajalik leida lahendus, mis võimaldab vigu koguda ja saata re-definitsiooniga veinimajadele mõningase määratud ajaga, kuid ei takista edukaid päringute töötlemist peamises järjekorras. Selleks valiti nn kontseptsioon "teema põhineb uuesti proovima". Iga põhiteema jaoks luuakse üks või mitu retry teemat, kuhu suunatakse vigased sõnumid ja seeläbi välistatakse viivitus peamise teema sõnumite töötlemisel. Koostoime skeem -

Selle skeemi rakendamiseks vajasime järgmist - integreerida see lahendus Springiga ja vältida koodi dubleerimist. Internetis sattusime sarnasele lahendusele, mis põhines Spring BeanPostProcessoril, kuid see tundus meile ülemäära kohmakas. Meie meeskond leidis lihtsama lahenduse, mis võimaldab integreeruda Springi consumerite loomise tsüklisse ja lisada täiendavalt Retry consumer'eid. Meie lahenduse prototüübi pakkusime Springi meeskonnale, seda saab vaadata siit. Retry consumer'ite arv ja iga consumer'i katsete arv seadistatakse parameetrite kaudu vastavalt äriprotsessi vajadustele, ning et kõik töötaks, tuleb lihtsalt paigaldada kõigile Springi arendajatele tuttav annotatsioon org.springframework.kafka.annotation.KafkaListener.

Kui sõnumit ei õnnestunud kõikide retry katsete järel töödelda, jõuab see DLT-le (dead letter topic) Spring DeadLetterPublishingRecoverer'i abil. Tugiteenuse soovil laiendasime seda funktsionaalsust ja lõime eraldi teenuse, mis võimaldab vaadata DLT-sse sattunud sõnumeid, stackTrace'i, traceId-d ja muud kasulikku teavet. Lisaks lisatud monitooringud ja häiresüsteemid kõigile DLT teemadele, ning nüüd on DLT teema sõnumi ilmumine põhjus probleemi analüüsimiseks ja defekti avamiseks. See on väga mugav - teema nime järgi mõistame kohe, millises protsessi etapis probleem tekkis, mis kiirendab oluliselt juurepõhjuse otsimist.

Hiljuti rakendasime liidese, mis võimaldab meie toetuse kaudu sõnumeid uuesti saata pärast nende põhjuste kõrvaldamist (näiteks, välise süsteemi töövõime taastamine) ja muidugi avada vastav defekt analüüsiks. Siin tulid kasuks meie self-teemad, et mitte taaskäivitada pikka töötlemisahelat, saab seda taaskäivitada vajalikust sammust.

Platvormi ekspluateerimine

Platvorm on juba tootmiseksponeeritud, iga päev teeme tarnet ja laadimist, ühendame uusi jaotuskeskusi ja poode. Pilootprojektina töötab süsteem kaubagruppidega "Tubakas" ja "Jalatsid".

Kogu meie meeskond osaleb pilootide läbiviimisel, analüüsib tekkinud probleeme ja teeb ettepanekuid meie toote täiustamiseks, alates logide täiustamisest kuni protsesside muutmiseni.

Kuna vältida oma vigade kordamist, kajastuvad kõik pilootprojekti käigus leitud juhtumid automatiseeritud testides. Suure arvu automatiseeritud ja unit-testide olemasolu võimaldab läbi viia regressiooniteste ja rakendada hotfixe sisuliselt paari tunni jooksul.

Praegu jätkame oma platvormi arendamist ja täiustamist ning seisame pidevalt silmitsi uute väljakutsetega. Kui olete huvitatud, räägime meie lahendustest järgmistes artiklites.

Allikas: habr.com