Alates 2019. aastast kehtib Venemaal kohustuslik märgistamise seadus. Seadus ei kehti kõikidele kaubagruppidele ning kaubagruppide kohustusliku märgistuse jõustumise kuupäevad on erinevad. Esimestena hakatakse kohustuslikku märgistama tubakas, jalanõud ja ravimid, hiljem lisanduvad muud tooted, näiteks parfüümid, tekstiilid ja piim. See seadusandlik uuendus ajendas välja töötama uusi IT-lahendusi, mis võimaldavad jälgida toote kogu eluahelat tootmisest ostuni lõpptarbijale ja kõikide protsessis osalejateni: nii riigile endale kui ka kõikidele kaupu müüvatele organisatsioonidele. kohustuslik märgistamine.
X5-s kannab süsteem, mis jälgib märgistatud kaupu ja vahetab andmeid riigi ja tarnijatega, nimega "Marcus". Räägime teile järjekorras, kuidas ja kes selle välja töötas, milline on selle tehnoloogiapakk ja miks meil on millegi üle uhkust tunda.
Tõeline HighLoad
“Marcus” lahendab palju probleeme, millest peamine on X5 infosüsteemide ja märgistatud toodete riigi infosüsteemi (GIS MP) vaheline interaktsioon märgistatud toodete liikumise jälgimiseks. Platvorm salvestab ka kõik meie poolt saadud märgistuskoodid ja kogu nende koodide objektide vahel liikumise ajaloo ning aitab vältida märgistatud toodete ümbersorteerimist. Tubakatoodete näitel, mis kuulusid esimestesse märgistatud kaupade gruppidesse, sisaldab vaid üks autotäis sigarette umbes 600 000 pakki, millest igaühel on oma kordumatu kood. Ja meie süsteemi ülesanne on jälgida ja kontrollida iga sellise paki liikumise seaduslikkust ladude ja kaupluste vahel ning lõpuks kontrollida nende müügi vastuvõetavust lõppostjale. Ja me salvestame umbes 125 000 sularahatehingut tunnis ja peame ka fikseerima, kuidas iga selline pakk poodi jõudis. Seega, võttes arvesse kõiki liikumisi objektide vahel, ootame aastas kümneid miljardeid rekordeid.
Meeskond M
Vaatamata asjaolule, et Marcust peetakse X5 raames projektiks, rakendatakse seda tootepõhise lähenemisviisi abil. Meeskond töötab Scrumi järgi. Projekt sai alguse eelmisel suvel, kuid esimesed tulemused tulid alles oktoobris - meie oma meeskond komplekteeriti täielikult, töötati välja süsteemi arhitektuur ja osteti seadmeid. Nüüd on meeskonnas 16 inimest, kellest kuus tegelevad backend ja frontend arendusega, kellest kolm tegelevad süsteemianalüüsiga. Veel kuus inimest on seotud käsitsi, laadimise, automatiseeritud testimise ja tootehooldusega. Lisaks on meil SRE spetsialist.
Meie meeskonnas ei kirjuta koodi mitte ainult arendajad; peaaegu kõik poisid teavad, kuidas programmeerida ja kirjutada automaatteste, laadida skripte ja automatiseerimisskripte. Pöörame sellele erilist tähelepanu, kuna isegi tootetugi nõuab kõrget automatiseeritust. Püüame alati nõustada ja aidata kolleege, kes pole varem programmeerinud, ning anda neile mõned väikesed ülesanded, millega tegeleda.
Seoses koroonaviiruse pandeemiaga viisime kogu meeskonna kaugtööle, arendusjuhtimise kõigi tööriistade kättesaadavus, Jira ja GitLabi sisseehitatud töövoog võimaldas sellest etapist hõlpsasti läbida. Kaugelt veedetud kuud näitasid, et meeskonna produktiivsus seetõttu ei kannatanud, paljude jaoks kasvas töömugavus, puudu oli vaid otsesuhtlusest.
Meeskonna kaugkoosolek
Koosolekud kaugtöö ajal
Lahenduse tehnoloogiapakk
X5 standardhoidla ja CI/CD tööriist on GitLab. Kasutame seda koodi salvestamiseks, pidevaks testimiseks ning juurutamiseks testimis- ja tootmisserverites. Kasutame ka koodi ülevaatuse praktikat, kui arendaja poolt koodis tehtud muudatused peavad heaks kiitma vähemalt 2 kolleegi. Staatilised koodianalüsaatorid SonarQube ja JaCoCo aitavad meil koodi puhtana hoida ja tagada vajalikul tasemel ühikutestide katvuse. Kõik koodi muudatused peavad läbima need kontrollid. Kõik käsitsi käivitatavad testskriptid automatiseeritakse hiljem.
Äriprotsesside edukaks juurutamiseks Marcuse poolt pidime lahendama terve rea tehnoloogilisi probleeme, millest igaüks on järjekorras.
Ülesanne 1. Süsteemi horisontaalse skaleeritavuse vajadus
Selle probleemi lahendamiseks valisime arhitektuurile mikroteenuste lähenemisviisi. Samas oli väga oluline mõista talituste vastutusvaldkondi. Püüdsime jagada need äritegevuseks, võttes arvesse protsesside spetsiifikat. Näiteks lattu vastuvõtmine ei ole väga sagedane, kuid väga mahukas toiming, mille käigus on vaja kiiresti saada riigiregulaatorilt info vastuvõetavate kaubaühikute kohta, mille arv ühes tarnes ulatub 600000 XNUMX-ni. , kontrollige selle toote lattu vastuvõtmise lubatavust ja tagastage kogu vajalik teave laoautomaatika süsteemi jaoks. Ladudest saadetise intensiivsus on aga palju suurem, kuid samal ajal toimib see väikese andmemahuga.
Rakendame kõiki teenuseid kodakondsuseta ja isegi püüame jagada sisetoimingud sammudeks, kasutades seda, mida nimetame Kafka eneseteemadeks. See on siis, kui mikroteenus saadab endale sõnumi, mis võimaldab tasakaalustada ressursimahukamate toimingute koormust ja lihtsustab toote hooldust, aga sellest hiljem.
Otsustasime eraldada välissüsteemidega suhtlemise moodulid eraldi teenusteks. See võimaldas lahendada väliste süsteemide sageli muutuvate API-de probleemi, mis praktiliselt ei mõjutanud ärifunktsioonidega teenuseid.
Kõik mikroteenused on juurutatud OpenShifti klastris, mis lahendab nii iga mikroteenuse skaleerimise probleemi kui ka võimaldab meil mitte kasutada kolmanda osapoole teenusetuvastuse tööriistu.
Ülesanne 2. Vajadus säilitada suur koormus ja väga intensiivne andmevahetus platvormiteenuste vahel: Ainuüksi projekti käivitamise etapis tehakse umbes 600 toimingut sekundis. Eeldame, et see väärtus tõuseb 5000 op.-ni sekundis, kui jaemüügipunktid ühenduvad meie platvormiga.
See probleem lahendati Kafka klastri kasutuselevõtuga ja peaaegu täielikult loobudes platvormi mikroteenuste vahelisest sünkroonsest suhtlusest. See nõuab süsteeminõuete väga hoolikat analüüsi, kuna kõik toimingud ei saa olla asünkroonsed. Samal ajal me mitte ainult ei edasta sündmusi maakleri kaudu, vaid edastame sõnumis ka kogu vajaliku äriteabe. Seega võib sõnumi suurus ulatuda mitmesaja kilobaidini. Sõnumi suuruse limiit Kafkas nõuab meilt sõnumi suuruse täpset ennustamist ja vajadusel jagame need ära, kuid jaotus on loogiline, äritegevusega seotud.
Näiteks jagame autoga saabuvad kaubad kastidesse. Sünkroonsete toimingute jaoks eraldatakse eraldi mikroteenused ja viiakse läbi põhjalik koormustestimine. Kafka kasutamine esitas meile veel ühe väljakutse – meie teenuse toimimise testimine, võttes arvesse Kafka integratsiooni, muudab kõik meie seadmetestid asünkroonseks. Lahendasime selle probleemi, kirjutades Embedded Kafka Brokeri abil oma utiliidi meetodid. See ei välista üksikute meetodite jaoks ühiktestide kirjutamise vajadust, kuid eelistame keerukaid juhtumeid testida Kafka abil.
Palju tähelepanu pöörati logide jälgimisele, et nende TraceId ei läheks kaduma, kui teenuste töö käigus või Kafka partiiga töötamisel tekivad erandid. Ja kui esimesega erilisi probleeme polnud, siis teisel juhul oleme sunnitud logima kõik partiiga kaasas olnud TraceId-id ja jälgimise jätkamiseks ühe valima. Seejärel saab kasutaja algse TraceId-i järgi otsides hõlpsasti teada, millega jälgimine jätkus.
Ülesanne 3. Vajadus salvestada suur hulk andmeid: Rohkem kui 1 miljard tubaka etiketti aastas tuleb X5-le. Need nõuavad pidevat ja kiiret juurdepääsu. Kokku peab süsteem töötlema umbes 10 miljardit kirjet nende märgistatud kaupade liikumisajaloo kohta.
Kolmanda probleemi lahendamiseks valiti NoSQL andmebaas MongoDB. Oleme loonud 5 sõlmest koosneva killu ja igal sõlmel on 3 serverist koosnev koopiakomplekt. See võimaldab teil süsteemi horisontaalselt skaleerida, lisada klastrisse uusi servereid ja tagada selle veataluvus. Siin puutusime kokku veel ühe probleemiga – tehingulisuse tagamine mongoklastris, võttes arvesse horisontaalselt skaleeritavate mikroteenuste kasutamist. Näiteks meie süsteemi üks ülesandeid on tuvastada katsed samade märgistuskoodidega tooteid edasi müüa. Siin ilmuvad ülekatted vigaste skannimiste või kassapidajate vigaste toimingutega. Leidsime, et sellised duplikaadid võivad esineda nii ühes töödeldavas Kafka partiis kui ka kahes paralleelselt töödeldavas partiis. Seega ei andnud duplikaatide kontrollimine andmebaasi päringute abil midagi. Iga mikroteenuse puhul lahendasime probleemi selle teenuse äriloogikast lähtuvalt eraldi. Näiteks tšekkide jaoks lisasime partiisisese kontrolli ja eraldi töötlemise duplikaatide väljanägemise jaoks sisestamisel.
Tagamaks, et kasutajate töö tegevusajalooga ei mõjutaks kuidagi kõige olulisemat – meie äriprotsesside toimimist, oleme kõik ajaloolised andmed eraldanud eraldi teenuseks, millel on eraldi andmebaas, mis saab infot ka läbi Kafka . Nii töötavad kasutajad isoleeritud teenusega, mõjutamata teenuseid, mis töötlevad andmeid käimasolevate toimingute jaoks.
Ülesanne 4: Järjekorra töötlemine ja jälgimine:
Hajutatud süsteemides tekivad paratamatult probleemid ja vead andmebaaside, järjekordade ja väliste andmeallikate kättesaadavuses. Marcuse puhul on selliste vigade allikaks integratsioon väliste süsteemidega. Vaja oli leida lahendus, mis võimaldaks korduvaid ekslike vastuste päringuid mingi määratud ajalõpuga, kuid samas ei peataks põhijärjekorras õnnestunud päringute töötlemist. Selleks valiti nn teemapõhine korduskatse kontseptsioon. Iga põhiteema jaoks luuakse üks või mitu uuesti proovimise teemat, kuhu saadetakse ekslikud teated ja samal ajal kaob põhiteema sõnumite töötlemise viivitus. Interaktsiooniskeem -
Sellise skeemi rakendamiseks oli meil vaja järgmist: integreerida see lahendus Springiga ja vältida koodi dubleerimist. Veebis surfates sattusime sarnasele Spring BeanPostProccessoril põhinevale lahendusele, kuid see tundus meile mõttetult tülikas. Meie meeskond on teinud lihtsama lahenduse, mis võimaldab integreeruda kevadisesse tarbijate loomise tsüklisse ja lisada täiendavalt Retry Consumers. Pakkusime Spring meeskonnale oma lahenduse prototüüpi, näete . Uuesti proovivate tarbijate arv ja iga tarbija katsete arv konfigureeritakse parameetrite kaudu, olenevalt äriprotsessi vajadustest ja et kõik toimiks, jääb üle vaid lisada märkus org.springframework.kafka.annotation.KafkaListener , mis on tuttav kõigile kevadistele arendajatele.
Kui sõnumit ei õnnestunud pärast kõiki korduskatseid töödelda, läheb see DLT-sse (surnud kirja teema), kasutades Spring DeadLetterPublishingRecovererit. Toe palvel laiendasime seda funktsiooni ja lõime eraldi teenuse, mis võimaldab vaadata DLT-s sisalduvaid sõnumeid, stackTrace'i, traceId ja muud kasulikku teavet nende kohta. Lisaks lisati kõikidele DLT teemadele monitooring ja märguanded ning nüüd on tegelikult DLT teemas teate ilmumine põhjus analüüsida ja viga parandada. See on väga mugav - teema nime järgi saame kohe aru, millises protsessi etapis probleem tekkis, mis kiirendab oluliselt selle algpõhjuse otsimist.
Viimati oleme juurutanud liidese, mis võimaldab pärast nende põhjuste kõrvaldamist (näiteks välissüsteemi funktsionaalsuse taastamist) ja loomulikult vastava vea tuvastamist analüüsimiseks meie toe abil sõnumeid uuesti saata. Siin tulevad appi meie eneseteemad: selleks, et pikka töötlemisahelat mitte taaskäivitada, saate selle uuesti alustada soovitud sammust.
Platvormi kasutamine
Platvorm on juba tootlikus töös, iga päev teostame tarneid ja vedu, ühendame uusi jaotuskeskusi ja kauplusi. Pilootprojekti raames töötab süsteem tooterühmadega "Tubakas" ja "Jalatsid".
Kogu meie meeskond osaleb pilootprojektide läbiviimises, analüüsib esilekerkivaid probleeme ja teeb ettepanekuid meie toote täiustamiseks alates logide täiustamisest kuni protsesside muutmiseni.
Et meie vigu mitte korrata, kajastuvad kõik piloodi käigus leitud juhtumid automatiseeritud testides. Suure hulga automaattestide ja ühikutestide olemasolu võimaldab teil mõne tunni jooksul läbi viia regressioonitestid ja installida kiirparanduse.
Nüüd jätkame oma platvormi arendamist ja täiustamist ning seisame pidevalt silmitsi uute väljakutsetega. Huvi korral räägime oma lahendustest järgmistes artiklites.
Allikas: www.habr.com