Od leta 2019 ima Rusija zakon o obveznem označevanju. Zakon ne velja za vse skupine blaga, datumi uveljavitve obveznega označevanja za skupine izdelkov pa so različni. Najprej bodo obvezno označevanje tobaka, obutve in zdravil, kasneje pa bodo dodani še drugi izdelki, na primer parfumi, tekstil in mleko. Ta zakonodajna novost je spodbudila razvoj novih informacijskih rešitev, ki bodo omogočale sledenje celotni življenjski verigi izdelka od proizvodnje do nakupa s strani končnega potrošnika, do vseh udeležencev v procesu: tako države same kot vseh organizacij, ki prodajajo blago z obvezno označevanje.
V X5 se sistem, ki bo sledil označenemu blagu in izmenjeval podatke z državo in dobavitelji, imenuje "Marcus". Povejmo vam po vrsti, kako in kdo ga je razvil, kakšen je njegov tehnološki sklop in zakaj imamo na kaj biti ponosni.
Real HighLoad
»Marcus« rešuje veliko težav, glavna je integracijska interakcija med informacijskimi sistemi X5 in državnim informacijskim sistemom za označene izdelke (GIS MP) za sledenje gibanja označenih izdelkov. Platforma shranjuje tudi vse kode za označevanje, ki smo jih prejeli, in celotno zgodovino gibanja teh kod po predmetih ter pomaga odpraviti ponovno razvrščanje označenih izdelkov. Na primeru tobačnih izdelkov, ki so bili uvrščeni v prve skupine označenega blaga, samo en tovornjak cigaret vsebuje približno 600 zavojev, od katerih ima vsak svojo kodo. In naloga našega sistema je slediti in preverjati zakonitost gibanja vsakega takega paketa med skladišči in trgovinami ter na koncu preveriti dopustnost njihove prodaje končnemu kupcu. In zabeležimo približno 000 gotovinskih transakcij na uro, zabeležiti pa moramo tudi, kako je vsak tak paket prišel v trgovino. Tako ob upoštevanju vseh premikov med objekti pričakujemo na desetine milijard zapisov letno.
Ekipa M
Kljub temu, da Marcus velja za projekt v okviru X5, se izvaja s produktnim pristopom. Ekipa deluje po Scrumu. Projekt se je začel lansko poletje, prvi rezultati pa so prišli šele oktobra – v celoti smo sestavili lastno ekipo, razvili sistemsko arhitekturo in nabavili opremo. Zdaj ima ekipa 16 ljudi, od katerih jih je šest vključenih v backend in frontend razvoj, trije pa so vključeni v sistemsko analizo. Še šest ljudi sodeluje pri ročnem, obremenitvenem, avtomatiziranem testiranju in vzdrževanju izdelkov. Poleg tega imamo specialista SRE.
V naši ekipi ne pišejo kode samo razvijalci; skoraj vsi fantje znajo programirati in pisati samodejne teste, nalagati skripte in skripte za avtomatizacijo. Temu posvečamo posebno pozornost, saj tudi podpora produktom zahteva visoko stopnjo avtomatizacije. Kolegom, ki še niso programirali, vedno skušamo svetovati in jim pomagati ter jim dati nekaj manjših nalog za delo.
Zaradi pandemije koronavirusa smo celotno ekipo prenesli na delo na daljavo, razpoložljivost vseh orodij za upravljanje razvoja, vgrajen delovni tok v Jiri in GitLabu pa je omogočil enostavno prehod te stopnje. Meseci, preživeti na daljavo, so pokazali, da produktivnost ekipe zaradi tega ni trpela, marsikomu se je povečalo udobje pri delu, manjkala je le komunikacija v živo.
Sestanek ekipe na daljavo
Srečanja med delom na daljavo
Tehnološki sklop rešitve
Standardno skladišče in orodje CI/CD za X5 je GitLab. Uporabljamo ga za shranjevanje kode, stalno testiranje in uvajanje v testne in produkcijske strežnike. Uporabljamo tudi prakso pregleda kode, ko morata vsaj 2 sodelavca odobriti spremembe kode, ki jih naredi razvijalec. Statična analizatorja kode SonarQube in JaCoCo nam pomagata ohranjati našo kodo čisto in zagotavljati zahtevano raven pokritosti testa enote. Vse spremembe kode morajo prestati ta preverjanja. Vsi testni skripti, ki se izvajajo ročno, so naknadno avtomatizirani.
Za uspešno izvedbo poslovnih procesov podjetja Marcus smo morali rešiti številne tehnološke probleme, vsakega po vrsti.
Naloga 1. Potreba po horizontalni razširljivosti sistema
Za rešitev tega problema smo izbrali mikrostoritveni pristop k arhitekturi. Ob tem je bilo zelo pomembno razumeti področja odgovornosti služb. Poskušali smo jih razdeliti na poslovne dejavnosti, pri čemer smo upoštevali specifiko procesov. Na primer, prevzem v skladišču ni zelo pogosta, a zelo obsežna operacija, med katero je treba od državnega regulatorja hitro pridobiti podatke o enotah blaga, ki se sprejemajo, katerih število v eni dostavi doseže 600000. , preverite dopustnost prevzema tega izdelka v skladišče in vrnite vse potrebne podatke za sistem avtomatizacije skladišča. Toda pošiljanje iz skladišč ima veliko večjo intenzivnost, a hkrati deluje z majhnimi količinami podatkov.
Vse storitve izvajamo brez stanja in celo poskušamo notranje operacije razdeliti na korake, pri čemer uporabljamo tako imenovane Kafkine samoteme. Takrat mikrostoritev sama sebi pošlje sporočilo, ki vam omogoča uravnoteženje obremenitve operacij, ki zahtevajo več virov, in poenostavi vzdrževanje izdelka, a o tem kasneje.
Odločili smo se, da module za interakcijo z zunanjimi sistemi ločimo v ločene storitve. To je omogočilo rešitev problema pogosto spreminjajočih se API-jev zunanjih sistemov, skoraj brez vpliva na storitve s poslovno funkcionalnostjo.
Vse mikrostoritve so razporejene v gruči OpenShift, kar rešuje problem skaliranja posamezne mikrostoritve in nam omogoča, da ne uporabljamo orodij za odkrivanje storitev tretjih oseb.
Naloga 2. Potreba po vzdrževanju visoke obremenitve in zelo intenzivne izmenjave podatkov med storitvami platforme: Samo v fazi zagona projekta se izvede približno 600 operacij na sekundo. Pričakujemo, da se bo ta vrednost povečala na 5000 ops/s, ko se maloprodajna mesta povežejo z našo platformo.
Ta problem je bil rešen z uvedbo gruče Kafka in skoraj popolno opustitvijo sinhrone interakcije med mikrostoritvami platforme. To zahteva zelo natančno analizo sistemskih zahtev, saj vse operacije ne morejo biti asinhrone. Hkrati ne prenašamo samo dogajanja preko posrednika, temveč posredujemo vse zahtevane poslovne informacije v sporočilu. Tako lahko velikost sporočila doseže nekaj sto kilobajtov. Omejitev velikosti sporočil v Kafki zahteva, da natančno predvidimo velikost sporočil in jih po potrebi razdelimo, vendar je delitev logična, povezana s poslovanjem.
Na primer, blago, ki prispe z avtomobilom, razdelimo v škatle. Za sinhrono delovanje so dodeljene ločene mikrostoritve in izvedeno je temeljito testiranje obremenitve. Uporaba Kafke nam je predstavljala še en izziv – testiranje delovanja naše storitve ob upoštevanju Kafka integracije naredi vse naše enotne teste asinhrone. To težavo smo rešili tako, da smo s pomočjo Embedded Kafka Broker napisali lastne metode pripomočkov. To ne odpravlja potrebe po pisanju enotnih testov za posamezne metode, ampak raje testiramo kompleksne primere s Kafko.
Veliko pozornosti smo namenili sledenju dnevnikov, da se njihov TraceId ne bi izgubil, ko pride do izjem med delovanjem storitev ali pri delu s paketom Kafka. In če s prvim ni bilo posebnih težav, smo v drugem primeru prisiljeni zabeležiti vse TraceId-je, s katerimi je prišla serija, in izbrati enega za nadaljevanje sledenja. Nato bo uporabnik pri iskanju po izvirnem TraceId-u enostavno ugotovil, s katerim se je sledenje nadaljevalo.
Naloga 3. Potreba po shranjevanju velike količine podatkov: Več kot 1 milijarda etiket na leto samo za tobak pride v X5. Potrebujejo stalen in hiter dostop. Skupaj mora sistem obdelati približno 10 milijard zapisov zgodovine gibanja tega označenega blaga.
Za rešitev tretjega problema je bila izbrana baza podatkov NoSQL MongoDB. Zgradili smo delček iz 5 vozlišč in vsako vozlišče ima nabor replik 3 strežnikov. To vam omogoča vodoravno skaliranje sistema, dodajanje novih strežnikov v gručo in zagotavljanje njegove odpornosti na napake. Tu smo naleteli na še eno težavo - zagotavljanje transakcijskosti v gruči mongo z upoštevanjem uporabe horizontalno razširljivih mikrostoritev. Ena od nalog našega sistema je na primer prepoznavanje poskusov ponovne prodaje izdelkov z enakimi kodami za označevanje. Tukaj se pojavijo prekrivanja z napačnimi skeniranji ali napačnimi operacijami blagajnikov. Ugotovili smo, da se takšni dvojniki lahko pojavijo tako znotraj enega Kafkinega paketa, ki se obdeluje, kot znotraj dveh paketov, ki se obdelujeta vzporedno. Tako preverjanje dvojnikov s poizvedovanjem po bazi ni dalo ničesar. Za vsako mikrostoritev smo problem reševali posebej glede na poslovno logiko te storitve. Na primer, za preglede smo dodali preverjanje znotraj serije in ločeno obdelavo za pojav dvojnikov pri vstavljanju.
Da delo uporabnikov z zgodovino poslovanja nikakor ne vpliva na najpomembnejše - na delovanje naših poslovnih procesov, smo vse zgodovinske podatke ločili v ločeno storitev z ločeno bazo podatkov, ki prav tako prejema informacije preko Kafke. . Na ta način uporabniki delajo z izolirano storitvijo, ne da bi to vplivalo na storitve, ki obdelujejo podatke za tekoče operacije.
Naloga 4: Ponovna obdelava čakalne vrste in spremljanje:
V porazdeljenih sistemih se težave in napake neizogibno pojavijo pri razpoložljivosti baz podatkov, čakalnih vrst in zunanjih virov podatkov. V primeru Marcusa je vir tovrstnih napak integracija z zunanjimi sistemi. Treba je bilo najti rešitev, ki bi omogočala ponavljajoče se zahteve za napačne odgovore z določeno časovno omejitvijo, hkrati pa ne bi zaustavila obdelave uspešnih zahtev v glavni čakalni vrsti. V ta namen je bil izbran tako imenovani koncept »ponovnega poskusa na podlagi teme«. Za vsako glavno temo se ustvari ena ali več tem za ponovni poskus, na katere se pošiljajo napačna sporočila, hkrati pa se odpravi zamuda pri obdelavi sporočil iz glavne teme. Shema interakcije -
Za izvedbo takšne sheme smo potrebovali naslednje: to rešitev integrirati s Springom in se izogniti podvajanju kode. Med brskanjem po spletu smo naleteli na podobno rešitev, ki temelji na Spring BeanPostProccessorju, a se nam je zdela po nepotrebnem okorna. Naša ekipa je naredila enostavnejšo rešitev, ki nam omogoča integracijo v spomladanski cikel za ustvarjanje porabnikov in dodatno dodajanje Ponovnih porabnikov. Pomladni ekipi smo ponudili prototip naše rešitve, lahko si ga ogledate . Število Retry Consumers in število poskusov za posameznega potrošnika se konfigurira preko parametrov, odvisno od potreb poslovnega procesa, in da vse deluje, ostane le še dodajanje opombe org.springframework.kafka.annotation.KafkaListener , ki ga poznajo vsi razvijalci programa Spring.
Če sporočila ni bilo mogoče obdelati po vseh poskusih ponovnega poskusa, gre v DLT (temo mrtvega pisma) z uporabo Spring DeadLetterPublishingRecoverer. Na zahtevo podpore smo to funkcionalnost razširili in ustvarili ločeno storitev, ki vam omogoča ogled sporočil, vključenih v DLT, stackTrace, traceId in druge koristne informacije o njih. Poleg tega so bili spremljanje in opozorila dodani vsem temam DLT in zdaj je dejansko pojav sporočila v temi DLT razlog za analizo in odpravo napake. To je zelo priročno - po imenu teme takoj razumemo, na kateri stopnji procesa je nastala težava, kar bistveno pospeši iskanje njenega temeljnega vzroka.
Pred kratkim smo uvedli vmesnik, ki nam omogoča ponovno pošiljanje sporočil z našo podporo po odpravi vzrokov zanje (na primer ponovna vzpostavitev funkcionalnosti zunanjega sistema) in seveda ugotovitvi ustrezne napake za analizo. Tu pridejo prav naše teme o sebi: da ne bi znova zagnali dolge procesne verige, jo lahko znova zaženete iz želenega koraka.
Delovanje platforme
Platforma že deluje produktivno, vsak dan izvajamo dostave in odpreme, povezujemo nove distribucijske centre in trgovine. V okviru pilota sistem deluje s skupinama izdelkov »Tobak« in »Čevlji«.
Naša celotna ekipa sodeluje pri izvajanju pilotov, analizira nastajajoče probleme in daje predloge za izboljšave našega produkta, od izboljšav dnevnikov do spreminjanja procesov.
Da ne bi ponavljali naših napak, se vsi primeri, odkriti med pilotom, odražajo v avtomatiziranih testih. Prisotnost velikega števila samodejnih testov in testov enote vam omogoča, da izvedete regresijsko testiranje in namestite hitri popravek dobesedno v nekaj urah.
Zdaj še naprej razvijamo in izboljšujemo našo platformo ter se nenehno soočamo z novimi izzivi. Če vas zanima, bomo o naših rešitvah govorili v naslednjih člankih.
Vir: www.habr.com