Od roku 2019 má Rusko zákon o povinnom označovaní. Zákon sa nevzťahuje na všetky skupiny tovaru a dátumy nadobudnutia účinnosti povinného označovania pre skupiny výrobkov sú rôzne. Ako prvý bude povinné označovanie tabak, obuv a lieky, neskôr pribudnú ďalšie produkty, napríklad parfumy, textil či mlieko. Táto legislatívna inovácia podnietila vývoj nových IT riešení, ktoré umožnia sledovať celý životný reťazec produktu od výroby až po nákup konečným spotrebiteľom, a to všetkým účastníkom procesu: ako samotnému štátu, tak aj všetkým organizáciám predávajúcim tovar. povinné označovanie.
V X5 sa systém, ktorý bude sledovať označený tovar a vymieňať si údaje so štátom a dodávateľmi, nazýva „Marcus“. Povedzme si v poradí, ako a kto ho vyvinul, aký je jeho technologický balík a prečo máme byť na čo hrdí.
Skutočné vysoké zaťaženie
„Marcus“ rieši mnoho problémov, hlavným je integračná interakcia medzi informačnými systémami X5 a štátnym informačným systémom pre označované výrobky (GIS MP) na sledovanie pohybu označovaných výrobkov. Platforma tiež uchováva všetky nami prijaté kódy označovania a celú históriu pohybu týchto kódov medzi objektmi a pomáha eliminovať prehodnocovanie označených produktov. Na príklade tabakových výrobkov, ktoré boli zaradené do prvých skupín označovaného tovaru, len jeden kamión cigariet obsahuje asi 600 000 balení, z ktorých každé má svoj jedinečný kód. A úlohou nášho systému je sledovať a overovať zákonnosť pohybov každého takéhoto balenia medzi skladmi a predajňami a v konečnom dôsledku overiť prípustnosť ich predaja konečnému kupujúcemu. A evidujeme asi 125 000 hotovostných transakcií za hodinu a musíme zaznamenať aj to, ako sa každé takéto balenie dostalo do obchodu. S prihliadnutím na všetky pohyby medzi objektmi teda očakávame desiatky miliárd záznamov ročne.
Tím M
Napriek tomu, že Marcus je v rámci X5 považovaný za projekt, implementuje sa produktovým prístupom. Tím funguje podľa Scrumu. Projekt sa začal v lete minulého roka, no prvé výsledky sa dostavili až v októbri – náš vlastný tím bol kompletne zostavený, bola vyvinutá architektúra systému a zakúpené vybavenie. Teraz má tím 16 ľudí, z ktorých šesť sa podieľa na vývoji backendu a frontendu, z ktorých traja sú zapojení do systémovej analýzy. Šesť ďalších ľudí sa podieľa na manuálnom, zaťažovacom, automatizovanom testovaní a údržbe produktov. Okrem toho máme špecialistu na SRE.
Nielen vývojári píšu kód v našom tíme; takmer všetci chlapci vedia, ako programovať a písať autotesty, načítavať skripty a automatizačné skripty. Tomu venujeme osobitnú pozornosť, pretože aj podpora produktov si vyžaduje vysoký stupeň automatizácie. Kolegom, ktorí ešte neprogramovali, sa snažíme vždy poradiť a pomôcť a zadáme im nejaké drobné úlohy, na ktorých môžu pracovať.
Kvôli pandémii koronavírusu sme celý tím presunuli na prácu na diaľku, dostupnosť všetkých nástrojov na riadenie vývoja, vybudovaný workflow v Jira a GitLab umožnili jednoducho prejsť touto fázou. Mesiace strávené na diaľku ukázali, že produktivita tímu tým neutrpela, pre mnohých sa zvýšil komfort pri práci, jediné, čo chýbalo, bola živá komunikácia.
Stretnutie tímu na diaľku
Stretnutia počas práce na diaľku
Technologický zásobník riešenia
Štandardným úložiskom a nástrojom CI/CD pre X5 je GitLab. Používame ho na ukladanie kódu, nepretržité testovanie a nasadzovanie na testovacie a produkčné servery. Využívame aj prax code review, kedy minimálne 2 kolegovia potrebujú schváliť zmeny vykonané vývojárom v kóde. Analyzátory statického kódu SonarQube a JaCoCo nám pomáhajú udržiavať náš kód čistý a zabezpečujú požadovanú úroveň pokrytia testom jednotiek. Všetky zmeny v kóde musia prejsť týmito kontrolami. Všetky testovacie skripty, ktoré sa spúšťajú manuálne, sú následne automatizované.
Pre úspešnú implementáciu obchodných procesov „Marcusom“ sme museli vyriešiť množstvo technologických problémov, približne každý v poradí.
Úloha 1. Potreba horizontálnej škálovateľnosti systému
Na vyriešenie tohto problému sme zvolili mikroservisný prístup k architektúre. Zároveň bolo veľmi dôležité pochopiť oblasti zodpovednosti služieb. Snažili sme sa ich rozdeliť do obchodných operácií s prihliadnutím na špecifiká procesov. Napríklad preberanie na sklade nie je veľmi častou, ale veľmi rozsiahlou operáciou, pri ktorej je potrebné rýchlo získať od štátneho regulátora informácie o preberaných jednotkách tovaru, ktorých počet v jednej dodávke dosahuje 600000 XNUMX kusov. , skontrolujte prípustnosť prijatia tohto produktu na sklad a vráťte všetky potrebné informácie pre systém skladovej automatizácie. No expedícia zo skladov má oveľa väčšiu intenzitu, no zároveň operuje s malými objemami dát.
Všetky služby implementujeme na bezstavovom základe a dokonca sa snažíme rozdeliť interné operácie do krokov pomocou toho, čo nazývame Kafkove self-témy. To je, keď mikroslužba odošle správu sama sebe, čo vám umožní vyvážiť zaťaženie operácií náročnejších na zdroje a zjednoduší údržbu produktu, ale o tom neskôr.
Rozhodli sme sa rozdeliť moduly pre interakciu s externými systémami do samostatných služieb. To umožnilo vyriešiť problém často sa meniacich API externých systémov, prakticky bez dopadu na služby s biznis funkcionalitou.
Všetky mikroslužby sú nasadené v klastri OpenShift, čo rieši problém škálovania každej mikroslužby a zároveň nám umožňuje nepoužívať nástroje na vyhľadávanie služieb tretích strán.
Úloha 2. Potreba udržiavať vysoké zaťaženie a veľmi intenzívnu výmenu dát medzi službami platformy: Len počas fázy spustenia projektu sa vykoná približne 600 operácií za sekundu. Očakávame, že po pripojení maloobchodných predajní k našej platforme sa táto hodnota zvýši na 5000 XNUMX ops/s.
Tento problém bol vyriešený nasadením klastra Kafka a takmer úplným opustením synchrónnej interakcie medzi mikroslužbami platformy. Vyžaduje si to veľmi starostlivú analýzu systémových požiadaviek, pretože nie všetky operácie môžu byť asynchrónne. Zároveň cez brokera prenášame nielen udalosti, ale prenášame aj všetky požadované obchodné informácie v správe. Veľkosť správy tak môže dosiahnuť niekoľko stoviek kilobajtov. Limit veľkosti správy v Kafke vyžaduje, aby sme presne predpovedali veľkosť správy a v prípade potreby ich rozdelíme, no rozdelenie je logické, súvisí s obchodnými operáciami.
Napríklad tovar, ktorý príde autom, delíme do krabíc. Pre synchrónne operácie sa prideľujú samostatné mikroslužby a vykonáva sa dôkladné testovanie záťaže. Používanie Kafky nás postavilo pred ďalšiu výzvu – testovanie prevádzky našej služby s prihliadnutím na integráciu Kafka robí všetky naše testy jednotiek asynchrónne. Tento problém sme vyriešili napísaním vlastných obslužných metód pomocou Embedded Kafka Broker. Neodpadá tým nutnosť písať unit testy pre jednotlivé metódy, ale radšej testujeme zložité prípady pomocou Kafku.
Veľká pozornosť bola venovaná trasovacím protokolom, aby sa ich TraceId nestratilo pri výskyte výnimiek počas prevádzky služieb alebo pri práci s dávkou Kafka. A ak sa nevyskytli žiadne špeciálne problémy s prvým, potom v druhom prípade sme nútení zaprotokolovať všetky TraceId, s ktorými bola dávka dodaná, a vybrať jeden na pokračovanie v sledovaní. Potom pri vyhľadávaní podľa pôvodného TraceId používateľ ľahko zistí, s ktorým trasovaním pokračovalo.
Úloha 3. Potreba uchovávať veľké množstvo dát: Viac ako 1 miliarda štítkov ročne len pre tabak prichádza na X5. Vyžadujú stály a rýchly prístup. Celkovo musí systém spracovať asi 10 miliárd záznamov o histórii pohybu tohto označeného tovaru.
Na vyriešenie tretieho problému bola zvolená NoSQL databáza MongoDB. Vytvorili sme fragment 5 uzlov a každý uzol má replikovú sadu 3 serverov. To vám umožňuje horizontálne škálovať systém, pridávať nové servery do klastra a zabezpečiť jeho odolnosť voči chybám. Tu sme narazili na ďalší problém – zabezpečenie transakcií v mongo klastri s prihliadnutím na využitie horizontálne škálovateľných mikroslužieb. Jednou z úloh nášho systému je napríklad identifikovať pokusy o opätovný predaj produktov s rovnakými označovacími kódmi. Tu sa objavujú prekrytia s chybnými skenmi alebo chybnými operáciami pokladníkov. Zistili sme, že takéto duplikáty sa môžu vyskytnúť tak v rámci jednej spracovávanej Kafkovej šarže, ako aj v rámci dvoch šarží spracovávaných paralelne. Kontrola duplikátov dotazovaním v databáze teda nič nedala. Pre každú mikroslužbu sme problém riešili samostatne na základe obchodnej logiky tejto služby. Napríklad pre kontroly sme pridali kontrolu v dávke a samostatné spracovanie vzhľadu duplikátov pri vkladaní.
Aby sme zabezpečili, že práca používateľov s históriou operácií nijako neovplyvní to najdôležitejšie – fungovanie našich obchodných procesov, všetky historické dáta sme oddelili do samostatnej služby so samostatnou databázou, ktorá získava informácie aj cez Kafka . Používatelia tak pracujú s izolovanou službou bez ovplyvnenia služieb, ktoré spracúvajú údaje pre prebiehajúce operácie.
Úloha 4: Prepracovanie a monitorovanie frontu:
V distribuovaných systémoch nevyhnutne vznikajú problémy a chyby v dostupnosti databáz, frontov a externých zdrojov údajov. V prípade Marcusa je zdrojom takýchto chýb integrácia s externými systémami. Bolo potrebné nájsť riešenie, ktoré by umožnilo opakované požiadavky na chybné odpovede s určitým stanoveným časovým limitom, no zároveň neprestalo spracovávať úspešné požiadavky v hlavnej fronte. Na tento účel bol zvolený takzvaný koncept „topic based retry“. Pre každú hlavnú tému je vytvorená jedna alebo viac tém opakovania, do ktorých sa odosielajú chybné správy a zároveň je eliminované oneskorenie spracovania správ z hlavnej témy. Schéma interakcie -
Na implementáciu takejto schémy sme potrebovali nasledovné: integrovať toto riešenie so Spring a vyhnúť sa duplicite kódu. Pri surfovaní na webe sme narazili na podobné riešenie založené na Spring BeanPostProccessor, no zdalo sa nám zbytočne ťažkopádne. Náš tím vytvoril jednoduchšie riešenie, ktoré nám umožňuje integrovať sa do jarného cyklu vytvárania spotrebiteľov a dodatočne pridať spotrebiteľov Opakovať. Spring teamu sme ponúkli prototyp nášho riešenia, môžete si ho pozrieť . Počet Spotrebiteľov opakovania a počet pokusov pre každého spotrebiteľa sa konfiguruje prostredníctvom parametrov v závislosti od potrieb obchodného procesu a aby všetko fungovalo, zostáva už len pridať anotáciu org.springframework.kafka.annotation.KafkaListener , ktorý poznajú všetci vývojári Spring.
Ak správu nebolo možné spracovať ani po všetkých pokusoch o opätovný pokus, prejde do DLT (téma mŕtveho listu) pomocou nástroja Spring DeadLetterPublishingRecoverer. Na žiadosť podpory sme túto funkcionalitu rozšírili a vytvorili samostatnú službu, ktorá vám umožňuje prezerať správy zahrnuté v DLT, stackTrace, traceId a ďalšie užitočné informácie o nich. Okrem toho bolo do všetkých tém DLT pridané monitorovanie a upozornenia a v skutočnosti je výskyt správy v téme DLT dôvodom na analýzu a opravu chyby. To je veľmi výhodné - podľa názvu témy okamžite pochopíme, v ktorom kroku procesu problém vznikol, čo výrazne urýchľuje hľadanie jeho hlavnej príčiny.
Najnovšie sme implementovali rozhranie, ktoré nám umožňuje znova posielať správy pomocou našej podpory po odstránení ich príčin (napríklad obnovenie funkčnosti externého systému) a samozrejme zistení zodpovedajúceho defektu na analýzu. Tu sa hodia naše vlastné témy: aby ste nereštartovali dlhý reťazec spracovania, môžete ho reštartovať od požadovaného kroku.
Prevádzka platformy
Platforma je už v produktívnej prevádzke, každý deň realizujeme dodávky a expedície, pripájame nové distribučné centrá a predajne. V rámci pilotnej prevádzky systém pracuje so skupinami produktov „Tabak“ a „Obuv“.
Celý náš tím sa podieľa na vykonávaní pilotných projektov, analyzuje vznikajúce problémy a predkladá návrhy na zlepšenie nášho produktu, od zlepšenia protokolov až po zmenu procesov.
Aby sa neopakovali naše chyby, všetky prípady zistené počas pilotného projektu sa premietajú do automatizovaných testov. Prítomnosť veľkého počtu autotestov a jednotkových testov vám umožňuje vykonať regresné testovanie a nainštalovať hotfix doslova v priebehu niekoľkých hodín.
Teraz pokračujeme vo vývoji a zlepšovaní našej platformy a neustále čelíme novým výzvam. Ak máte záujem, o našich riešeniach si povieme v nasledujúcich článkoch.
Zdroj: hab.com