Od roku 2019 má Rusko zákon o povinném označování. Zákon se nevztahuje na všechny skupiny zboží a data nabytí účinnosti povinného označování pro skupiny výrobků se liší. Jako první bude povinné označování tabák, obuv a léky, později přibudou další produkty, například parfémy, textilie, mléko. Tato legislativní inovace podnítila vývoj nových IT řešení, která umožní sledovat celý životní řetězec produktu od výroby až po nákup konečným spotřebitelem, a to všem účastníkům procesu: jak samotnému státu, tak všem organizacím prodávajícím zboží. povinné značení.
V X5 se systém, který bude sledovat označené zboží a vyměňovat data se státem a dodavateli, nazývá „Marcus“. Řekněme vám postupně, jak a kdo jej vyvinul, jaké jsou jeho technologie a proč máme být na co hrdí.
Skutečné vysoké zatížení
„Marcus“ řeší mnoho problémů, tím hlavním je integrační interakce mezi informačními systémy X5 a státním informačním systémem pro označované výrobky (GIS MP) pro sledování pohybu značených výrobků. Platforma také ukládá všechny kódy označování, které jsme obdrželi, a celou historii pohybu těchto kódů mezi objekty a pomáhá eliminovat přetřídění označených produktů. Na příkladu tabákových výrobků, které byly zařazeny do prvních skupin značeného zboží, obsahuje jen jeden kamion cigaret asi 600 000 krabiček, z nichž každé má svůj unikátní kód. A úkolem našeho systému je sledovat a ověřovat zákonnost pohybů každého takového balení mezi sklady a prodejnami a v konečném důsledku ověřit přípustnost jejich prodeje koncovému kupujícímu. A evidujeme asi 125 000 hotovostních transakcí za hodinu a musíme také zaznamenat, jak se každý takový balíček dostal do obchodu. S přihlédnutím ke všem pohybům mezi objekty tedy očekáváme desítky miliard záznamů ročně.
Tým M
Navzdory skutečnosti, že Marcus je považován za projekt v rámci X5, je implementován pomocí produktového přístupu. Tým funguje podle Scrumu. Projekt začal loni v létě, ale první výsledky se dostavily až v říjnu – náš vlastní tým byl kompletně sestaven, byla vyvinuta architektura systému a zakoupeno vybavení. Nyní má tým 16 lidí, z nichž šest se podílí na vývoji backendu a frontendu, z nichž tři se podílejí na analýze systému. Šest dalších lidí se podílí na manuálním, zátěžovém, automatizovaném testování a údržbě produktů. Navíc máme specialistu na SRE.
Nejen vývojáři píší kód v našem týmu; téměř všichni kluci vědí, jak programovat a psát autotesty, načítat skripty a automatizační skripty. Tomu věnujeme zvláštní pozornost, protože i podpora produktů vyžaduje vysokou úroveň automatizace. Kolegům, kteří ještě neprogramovali, se vždy snažíme poradit a pomoci a zadáme jim nějaké drobné úkoly, na kterých zapracují.
Kvůli pandemii koronaviru jsme celý tým převedli na práci na dálku, dostupnost všech nástrojů pro správu vývoje, vybudovaný workflow v Jira a GitLab umožnily snadno projít touto fází. Měsíce strávené na dálku ukázaly, že produktivita týmu tím neutrpěla, pro mnohé se zvýšil komfort při práci, jediné, co chybělo, byla živá komunikace.
Vzdálená schůzka týmu
Schůzky při práci na dálku
Technologický zásobník řešení
Standardním repozitářem a nástrojem CI/CD pro X5 je GitLab. Používáme jej pro ukládání kódu, průběžné testování a nasazení na testovací a produkční servery. Používáme také praxi code review, kdy alespoň 2 kolegové potřebují schválit změny provedené vývojářem v kódu. Analyzátory statického kódu SonarQube a JaCoCo nám pomáhají udržovat náš kód čistý a zajišťují požadovanou úroveň pokrytí testem jednotek. Všechny změny kódu musí projít těmito kontrolami. Všechny testovací skripty, které jsou spouštěny ručně, jsou následně automatizovány.
Pro úspěšnou implementaci obchodních procesů „Marcusem“ jsme museli vyřešit řadu technologických problémů, asi každý v pořadí.
Úkol 1. Potřeba horizontální škálovatelnosti systému
K vyřešení tohoto problému jsme zvolili mikroservisní přístup k architektuře. Zároveň bylo velmi důležité pochopit oblasti odpovědnosti služeb. Snažili jsme se je rozdělit do obchodních operací s přihlédnutím ke specifikům procesů. Například přejímka na sklad je nepříliš častá, ale velmi rozsáhlá operace, při které je nutné rychle získat od státního regulátora informace o přejímaných jednotkách zboží, jejichž počet v jedné dodávce dosahuje 600000 XNUMX , zkontrolujte přípustnost přijetí tohoto produktu na sklad a vraťte všechny potřebné informace pro systém automatizace skladu. Expedice ze skladů má ale mnohem větší intenzitu, ale zároveň operuje s malými objemy dat.
Všechny služby implementujeme na bezstavovém základě a dokonce se snažíme rozdělit interní operace do kroků pomocí toho, čemu říkáme Kafkova sebetémata. To je, když mikroslužba odešle zprávu sama sobě, což vám umožní vyvážit zátěž operací náročnějších na zdroje a zjednoduší údržbu produktu, ale o tom později.
Rozhodli jsme se rozdělit moduly pro interakci s externími systémy do samostatných služeb. To umožnilo vyřešit problém s často se měnícími API externích systémů, prakticky bez dopadu na služby s business funkcionalitou.
Všechny mikroslužby jsou nasazeny v clusteru OpenShift, který řeší jak problém škálování každé mikroslužby, tak nám umožňuje nepoužívat nástroje pro zjišťování služeb třetích stran.
Úkol 2. Potřeba udržovat vysokou zátěž a velmi intenzivní výměnu dat mezi službami platformy: Jen během fáze spuštění projektu je provedeno asi 600 operací za sekundu. Očekáváme, že se tato hodnota zvýší na 5000 XNUMX ops/s, jakmile se maloobchodní prodejny připojí k naší platformě.
Tento problém byl vyřešen nasazením clusteru Kafka a téměř úplným opuštěním synchronní interakce mezi mikroslužbami platformy. To vyžaduje velmi pečlivou analýzu systémových požadavků, protože ne všechny operace mohou být asynchronní. Prostřednictvím brokera přitom nejen přenášíme události, ale také předáváme všechny požadované obchodní informace ve zprávě. Velikost zprávy tak může dosáhnout několika stovek kilobajtů. Limit velikosti zprávy v Kafce vyžaduje přesnou předpověď velikosti zprávy a v případě potřeby je rozdělíme, ale rozdělení je logické, souvisí s obchodními operacemi.
Například zboží, které přijede autem, rozdělujeme do krabic. Pro synchronní operace jsou přiděleny samostatné mikroslužby a je provedeno důkladné zátěžové testování. Použití Kafky nás postavilo před další výzvu – testování provozu naší služby s přihlédnutím k integraci Kafka dělá všechny naše testy jednotek asynchronní. Tento problém jsme vyřešili napsáním vlastních obslužných metod pomocí Embedded Kafka Broker. Neodpadá tím nutnost psát unit testy pro jednotlivé metody, ale raději testujeme složité případy pomocí Kafky.
Velká pozornost byla věnována trasovacím logům, aby nedošlo ke ztrátě jejich TraceId při výskytu výjimek při provozu služeb nebo při práci s dávkou Kafka. A pokud u prvního nenastaly žádné zvláštní problémy, pak ve druhém případě jsme nuceni zaznamenat všechna TraceId, se kterými byla dávka dodána, a vybrat jedno pro pokračování ve sledování. Při vyhledávání podle původního TraceId pak uživatel snadno zjistí, se kterým trasování pokračovalo.
Úkol 3. Potřeba ukládat velké množství dat: Více než 1 miliarda etiket ročně jen pro tabák přichází na X5. Vyžadují stálý a rychlý přístup. Celkem musí systém zpracovat asi 10 miliard záznamů o historii pohybu tohoto označeného zboží.
Pro řešení třetího problému byla zvolena NoSQL databáze MongoDB. Vytvořili jsme fragment 5 uzlů a každý uzel má sadu replik 3 serverů. To vám umožňuje horizontálně škálovat systém, přidávat do clusteru nové servery a zajistit jeho odolnost proti chybám. Zde jsme narazili na další problém – zajištění transakcionality v mongo clusteru s přihlédnutím k využití horizontálně škálovatelných mikroslužeb. Jedním z úkolů našeho systému je například identifikovat pokusy o další prodej produktů se stejnými kódy značení. Zde se objevují překryvy s chybnými skeny nebo chybnými operacemi pokladníků. Zjistili jsme, že k takovým duplicitám může dojít jak v rámci jedné zpracovávané Kafkovy šarže, tak v rámci dvou šarží zpracovávaných paralelně. Kontrola duplikátů dotazem na databázi tedy nic nedala. Pro každou mikroslužbu jsme problém vyřešili samostatně na základě obchodní logiky této služby. Například u kontrol jsme přidali kontrolu uvnitř dávky a samostatné zpracování pro výskyt duplikátů při vkládání.
Aby práce uživatelů s historií provozu nijak neovlivnila to nejdůležitější – fungování našich obchodních procesů, oddělili jsme všechna historická data do samostatné služby se samostatnou databází, která také přijímá informace prostřednictvím Kafky . Uživatelé tak pracují s izolovanou službou, aniž by to ovlivnilo služby, které zpracovávají data pro probíhající operace.
Úkol 4: Přepracování a monitorování fronty:
V distribuovaných systémech nevyhnutelně vznikají problémy a chyby v dostupnosti databází, front a externích zdrojů dat. V případě Marcuse je zdrojem takových chyb integrace s externími systémy. Bylo potřeba najít řešení, které umožní opakované požadavky na chybné odpovědi s nějakým zadaným timeoutem, ale zároveň nepřestane zpracovávat úspěšné požadavky v hlavní frontě. Pro tento účel byl zvolen koncept tzv. „topic based retry“. Pro každé hlavní téma je vytvořeno jedno nebo více témat opakování, do kterých se odesílají chybové zprávy a zároveň odpadá prodleva při zpracování zpráv z hlavního tématu. Schéma interakce -
K implementaci takového schématu jsme potřebovali následující: integrovat toto řešení se Spring a vyhnout se duplicitě kódu. Při brouzdání po webu jsme narazili na podobné řešení založené na Spring BeanPostProccessor, ale přišlo nám zbytečně těžkopádné. Náš tým vytvořil jednodušší řešení, které nám umožňuje začlenit se do jarního cyklu vytváření spotřebitelů a dodatečně přidat nové spotřebitele. Spring teamu jsme nabídli prototyp našeho řešení, můžete se na něj podívat . Počet spotřebitelů Retry a počet pokusů pro každého spotřebitele se konfigurují pomocí parametrů v závislosti na potřebách obchodního procesu, a aby vše fungovalo, zbývá pouze přidat anotaci org.springframework.kafka.annotation.KafkaListener , který znají všichni vývojáři Spring.
Pokud zprávu nebylo možné zpracovat ani po všech pokusech o opakování, přejde do DLT (téma mrtvého dopisu) pomocí Spring DeadLetterPublishingRecoverer. Na žádost podpory jsme tuto funkcionalitu rozšířili a vytvořili samostatnou službu, která umožňuje prohlížet zprávy obsažené v DLT, stackTrace, traceId a další užitečné informace o nich. Kromě toho bylo do všech témat DLT přidáno monitorování a výstrahy a nyní je výskyt zprávy v tématu DLT důvodem k analýze a opravě závady. To je velmi výhodné - podle názvu tématu okamžitě pochopíme, v jakém kroku procesu problém vznikl, což výrazně urychluje hledání jeho hlavní příčiny.
Nejnověji jsme implementovali rozhraní, které nám umožňuje znovu zasílat zprávy pomocí naší podpory po odstranění jejich příčin (například obnovení funkčnosti externího systému) a samozřejmě zjištění příslušné závady pro analýzu. Zde se hodí naše vlastní témata: aby nedošlo k restartování dlouhého zpracovatelského řetězce, můžete jej restartovat od požadovaného kroku.
Provoz platformy
Platforma je již v produktivním provozu, každý den realizujeme dodávky a expedice, připojujeme nová distribuční centra a prodejny. V rámci pilotního provozu systém pracuje se skupinami produktů „Tabák“ a „Obuv“.
Celý náš tým se podílí na provádění pilotních projektů, analyzuje vznikající problémy a předkládá návrhy na zlepšení našeho produktu, od vylepšení protokolů až po změny procesů.
Aby se naše chyby neopakovaly, všechny případy zjištěné během pilotního provozu se promítají do automatizovaných testů. Přítomnost velkého množství autotestů a jednotkových testů vám umožňuje provádět regresní testování a nainstalovat opravu hotfix doslova během několika hodin.
Nyní pokračujeme ve vývoji a zlepšování naší platformy a neustále čelíme novým výzvám. V případě zájmu si o našich řešeních povíme v následujících článcích.
Zdroj: www.habr.com