Alates 2019. aastast kehtib Venemaal kohustusliku märgistamise seadus. See seadus ei laiene kõikidele kaubagruppidele ning kohustusliku märgistamise rakendamise tähtajad varieeruvad kaupade kaupa. Esimeste seas kuuluvad kohustuslikku märgistamist tubakas, jalatsid ja ravimid, hiljem lisanduvad ka teised tooted, näiteks parfüümid, tekstiil ja piimatooted. See seadusandlik uuendus on andnud olulise tõuke uute IT-lahenduste väljatöötamiseks, mis võimaldavad jälgida toote eluahelat alates tootmisest kuni lõppkasutaja ostuni, kaasates kõiki protsessi osalisi: nii riigi kui ka kõiki organisatsioone, mis müüvad kohustusliku märgistusega tooteid.
H5-s on süsteem, mis jälgib märgistatud tooteid ja vahetab andmeid riigi ja tarnijatega, saanud nimeks "Markus". Tutvustame järjestikku, kuidas ja kes seda arendas, milline on tema tehnoloogiline virn ning miks meil on põhjust uhkustada.
Tõeline HighLoad
„Markus“ lahendab mitmeid ülesandeid, mille peamine on integratsioonitegevus X5 teabe sistemitega ja riikliku märgistatud toodete teabe süsteemiga (GIS MP), et jälgida märgistatud toodete liiklust. Platvorm salvestab kõik meie kätte saabunud märgistuskoodid ja kogu nende liikluse ajaloos objekte, aidates kõrvaldada märgistatud toodete vale jaotust. Näiteks tubakatoodete puhul, mis kuulusid esimestesse märgistatud kaupade gruppidesse, sisaldab ainult üks sigareti veok umbes 600 000 pakki, millest igaühel on oma ainulaadne kood. Meie süsteemi ülesanne on jälgida ja kontrollida iga sellise paki liikumise seaduslikkust vahehoidlate ja poodide vahel ning lõpuks kontrollida nende müümise sobivust lõpptarbijale. Me fikseerime umbes 125 000 kassatehingut tunnis ning peame ka registreerima, kuidas iga selline pakk poodi jõudis. Seetõttu ootame kõikide objektide vahelise liikumise arvelt kümneid miljardeid salvestusi aastas.
Meeskond M
Kuigi "Markus" on raames X5 projekt, viiakse see ellu toote lähenemisviisiga. Meeskond töötab Scrum'i järgi. Projekti alustamine toimus eelmise aasta suvel, kuid esimesed tulemused tulid alles oktoobris - koguti täielikult oma meeskond, arendati süsteemi arhitektuur ja osteti seadmed. Praegu on meeskonnas 16 inimest, kellest kuus tegelevad backend ja frontend arendusega, kolm süsteemi analüüsiga. Käsitsi, koormus-, automatiseeritud testimise ja toote toetamisega tegelevad veel kuus inimest. Lisaks on meil SRE-spetsialist.
Kood meie meeskonnas kirjutavad mitte ainult arendajad, vaid praktiliselt kõik poisid oskavad programmeerida ja kirjutavad automaatkatsetusi, koormus-skripte ja automatiseerimisskripte. Me pöörame sellele erilist tähelepanu, kuna isegi toote toetamine vajab kõrget automatiseerimise taset. Kolleege, kes varem ei programmeerinud, püüame alati aidata ja juhendada, anda neile töösse mõned väiksemad ülesanded.
Seoses koronaviiruse pandeemiaga siirdus kogu meie meeskond kaugtööle. Kõik tööriistad arenduse juhtimiseks, töövoog Jira ja GitLabis võimaldasid meil seda etappi kergesti läbida. Kaugtöös veedetud kuud näitasid, et meeskonna tootlikkus ei kannatanud selle tõttu. Paljude jaoks kasvas töö mugavus, ainus asi, mis jäi puudu, oli otsene suhtlemine.
Meeskonna koosolek enne kaugtööd
Koosolekud kaugtöö ajal
Lahenduse tehnoloogia virn
X5 standardne repositoorium ja CI/CD tööriist on GitLab. Kasutame seda koodi ladustamiseks, pidevaks testimiseks ja mustrite väljapanekuks testimis- ja tootmisserverites. Samuti rakendame praktikat koodiarvustuse osas, kus vähemalt kaks kolleegi peavad kinnitama arendaja koodimuudatused. Koodi staatilised analüsaatorid SonarQube ja JaCoCo aitavad meil hoida koodi puhta ning tagada vajalikku taset unit-testide katvuses. Kõik koodimuudatused peavad kindlasti läbi minema nende kontrollide. Kõik käsitsi jooksutatud teststsenaariumid automatiseeritakse hiljem.
Edukas, et tulemusteks, et "Markust" äritegevuse protsessid õnnestuks, pidi meil lahendama mitmeid tehnoloogilisi probleeme, millest räägime järgnevalt.
Ülesanne 1. Süsteemi horisontaalne skaleeritavus
Selle ülesande lahendamiseks valisime mikroteenuste lähenemise arhitektuurile. Oluline oli mõista teenuste vastutusalasid. Püüdsime jagada need äritegevuse operatsioonide põhjal, arvestades protsesside spetsiifikat. Näiteks kaupade vastuvõtt laos – see on haruldane, kuid mahukas operatsioon, mille käigus tuleb kiiresti saada riiklikult reguleerijalt teavet vastuvõetavate kaubakoguste kohta, mis ühe saadetise puhul ulatuvad kuni 600000, kontrollida kaupade vastuvõtmise võimalikkust laos ja edastada kogu vajalik teave laoautomaatika süsteemile. Seevastu lao väljaanded on intensiivsemad, kuid käsitlevad väiksemaid andmekoguseid.
Meie kõik teenused toimivad stateless põhimõttel ning isegi siseoperatsioonid jagame sammudeks, kasutades meie enda poolt nimetatud self-täidiseid Kafka. See, kui mikroteenus saadab sõnumi iseendale, võimaldab tasakaalustada koormust ressursinõudlikumate operatsioonide osas ning lihtsustab toote hooldust, kuid sellest räägime hiljem.
Otsustasime eraldi teenustesse jagada moodulid, mis suhtlevad väliste süsteemidega. See lahendas probleemi tihedalt muutuva välise süsteemi API-dega, praktiliselt mõjutamata äritegevuse funktsioone.
Kõik mikroteenused paigaldatakse OpenShifti klastrisse, mis lahendab nii iga mikroteenuse skaleerimise probleemi kui võimaldab meil mitte kasutada väliseid Service Discovery tööriistu.
Ülesanne 2. Vajadus toetada suurt koormust ja väga intensiivset andmevahetust platvormi teenuste vahel: ainult projekti käivitamise faasis toimub keskmiselt 600 operatsiooni sekundis. Ootame, et see arv tõuseb 5000 op/sec-ni, kui meie platvormi liidetakse kaubandusobjekte.
Selle probleemi lahendamiseks kasutati Kafka klastrite käivitamist ja peaaegu täielikku loobumist sünkr.MSG suheldes platvormi mikroteenustega. See nõuab süsteemi nõuete väga põhjalikku analüüsi, kuna mitte kõik toimingud ei saa olla asünkroonsed. Samuti edastame me sündmusi mitte ainult vahendajate kaudu, vaid edastame sõnumis kogu vajaliku äriinfo. Seega võib sõnumi suurus ulatuda mitmesaja kilobaidi suuruseni. Kafka sõnumite mahupiirang nõuab meilt täpset sõnumite suuruse prognoosimist ja vajadusel jagame neid, kuid see jagamine on loogiline, seostatuna äritegevustega.
Näiteks jagame auto abil saabunud kauba kastideks. Sünkrontoimingute jaoks eraldatakse eraldi mikroteenused ja viiakse läbi põhjalik koormustestimine. Kafka kasutamine esitas meile uue väljakutse — meie teenuse töö kontrollimine Kafka integreerimise arvestamisel muudab kõik meie üksustestid asünkroonseteks. Selle ülesande lahendamiseks kirjutasime oma utiliidi meetodid, kasutades Embedded Kafka Brokerit. See ei tühista vajadust kirjutada üksusteste eraldi meetodite jaoks, kuid keerulisi olukordi eelistame testida Kafka abil.
Me pöörasime väga palju tähelepanu logide jälgimisele, et nende TraceId ei kaoks, kui teenustes tekivad erandid või töötatakse Kafka batchiga. Ja kui esimeses küsimuses probleeme ei olnud, siis teisel juhul olime sunnitud logima kõik TraceId, millega batch tuli, ja valima ühe jätkuva jälgimise jaoks. Sel juhul leiab kasutaja algse TraceId järgi otsides kergesti, millise jälgimisega jätkati.
Ülesanne 3. Suure hulga andmete säilitamise vajadus: üle 1 miljardi märgistuse aastas, mis on seotud vaid tubakaga, jõuab X5. Nendele on vajalik pidev ja kiire ligipääs. Kokku peab süsteem töötlema umbes 10 miljardit märgistega toodete andmeid.
Kolmanda ülesande lahendamiseks valiti NoSQL andmebaas MongoDB. Meil on loodud 5 sõlme shard ja igas sõlmes Replica Set 3 serveriga. See võimaldab süsteemi horisontaalselt skaleerida, lisades uus server klasterisse ja tagada selle talitlushäireteta töö. Siin puutusime kokku teise probleemiga — tehingute tagamise korraldamine mongo klasteris, arvestades horisontaalselt skaleeritavate mikroteenuste kasutamist. Näiteks on meie süsteemi üks ülesandeid tuvastada katseid sama koodiga kaupade edasimüügiks. Siin tekivad probleemid vale skaneerimise või vale kassapidamise toimingutega. Oleme avastanud, et sellised dubleeringud võivad tekkida nii ühe töötleva Kafka batch'i sisse kui ka kahe samaaegselt töötleva batch'i jooksul. Seetõttu ei andnud dupleerimise kontrollimine andmebaasi päringute kaudu tulemusi. Iga mikroteenuse puhul lahendasime probleemi eraldi, lähtudes selle teenuse äriloogikast. Näiteks lisasime tšekkide jaoks kontrolli batch'i sees ja eraldi töötlemise dubleeringute tuvastamiseks sisestamise ajal.
Kuna kasutajate tehinguajalugu ei tohi mõjutada meie äri protsesside toimimist, oleme kõik ajaloolised andmed eraldanud eraldi teenusesse koos eraldi andmebaasiga, mis saab teavet ka läbi Kafka. Nii saavad kasutajad töötada isoleeritud teenusega, ilma et see mõjutaks teenuseid, mis töötlevad andmeid praeguste tehingute kohta.
Ülesanne 4. Korduv töötlemine ja jälgimine:
Jaotatud süsteemides tekivad paratamatult probleemid ja vigade tõttu 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õimaldaks vigastele vastustele teha kordusettepanekuid kindla ootetähtaega, kuid samal ajal ei katkestaks põhijärjekorras edukaid ettepanekuid. Selleks valiti nii öelda "teemapõhine kordamine". Iga põhiteema jaoks luuakse üks või mitu kordusteemat, kuhu suunatakse vigaste sõnumite teated, erandina edasilükatud sõnumite töötlemise põhiteemast. Koostöö schema —
Selle skeemi elluviimiseks vajasime järgmist — integreerida see lahendus Springiga ja vältida koodi dubleerimist. Veebis sattusime sarnasele lahendusele, mis põhines Spring BeanPostProcessor'il, kuid see näis meile liiga koormav. Meie meeskond töötas välja lihtsama lahenduse, mis võimaldab integreeruda Springi loomise tsüklisse ja lisada täiendavaid Retry consumer'eid. Meie lahenduse prototüübi esitasime Springi meeskonnale, seda saab vaadata . Retry consumer'ite arv ja iga consumeri katsete arv seadistatakse parameetrite kaudu vastavalt äri protsessi vajadustele, ning et kõik tööle hakkaks, on vajalik vaid lisada tuntud kõigile Springi arendajatele annotatsioon org.springframework.kafka.annotation.KafkaListener.
Kui sõnumit ei õnnestu kõigi retry katsete järel töödelda, jõuab see DLT (dead letter topic) kaudu Spring DeadLetterPublishingRecoverer'isse. Toetuse nõudmisel oleme selle funktsionaalsust laiendanud ja loonud eraldi teenuse, mis võimaldab vaadata DLT'sse jõudnud sõnumeid, stackTrace'i, traceId-d ja muud kasulikku teavet nende kohta. Lisaks on lisatud jälgimise ja hoiatamise süsteemid kõigi DLT teemade jaoks, mistõttu sõnumi ilmumine DLT teemale on nüüdseks põhjuseks lähemaks uurimiseks ja defekti registreerimiseks. See on väga mugav — teema nime järgi mõistame kohe, millises protsessi etapis probleem tekkis, mis kiirendab oluliselt juurte põhjuste leidmist.
Hiljuti rakendasime liidese, mis võimaldab meie toe abil sõnumeid uuesti saata pärast nende põhjuste kõrvaldamist (näiteks välise süsteemi toimimise taastamine) ning loomulikult vastava defekti registreerimist analüüsi jaoks. Siin tuli kasuks meie self-teemad, et mitte käivitada pikka töötlemisahelat uuesti, vaid alustada seda vajalikult sammult.
Platvormi käitamine
Platvorm on juba tootmiseks valmiduses, iga päev viime läbi tarnet ja lahtisi, ühendame uusi jaotuskeskusi ja poode. Pilootprojekti raames töötab süsteem kaubagruppidega „Tubakas” ja „Jalad.”
Kogu meie meeskond osaleb pilootide läbiviimisel, analüüsib tekkinud probleeme ja teeb ettepanekuid meie toote täiustamiseks alates logide parandamisest kuni protsesside muutmiseni.
Kuna me ei soovi oma vigu korrata, kajastuvad kõik pilooti käigus leitud juhtumid automatiseeritud testides. Suure testide ja unit-testide arvu olemasolu võimaldab meil läbi viia regressiooniteste ja rakendada hotfixe vaid mõne tunni jooksul.
Praegu jätkame oma platvormi arendamist ja täiendamist ning puutume pidevalt kokku uute väljakutsetega. Kui teid huvitab, räägime meie lahendustest järgmistes artiklites.
Allikas: habr.com
