Sedert 2019 het Rusland 'n wet oor verpligte etikettering. Die wet is nie van toepassing op alle groepe goedere nie, en die datums vir die inwerkingtreding van verpligte etikettering vir produkgroepe verskil. Tabak, skoene en medisyne sal die eerstes wees wat onderhewig is aan verpligte etikettering; ander produkte sal later bygevoeg word, byvoorbeeld parfuum, tekstiele en melk. Hierdie wetgewende innovasie het gelei tot die ontwikkeling van nuwe IT-oplossings wat dit moontlik sal maak om die hele lewensketting van 'n produk van produksie tot aankoop deur die eindverbruiker na te spoor aan alle deelnemers aan die proses: beide die staat self en alle organisasies wat goedere verkoop met verpligte etikettering.
In X5 word die stelsel wat gemerkte goedere sal opspoor en data met die staat en verskaffers sal uitruil, "Marcus" genoem. Kom ons vertel jou in volgorde hoe en wie dit ontwikkel het, wat sy tegnologiestapel is, en hoekom ons iets het om op trots te wees.
Regte hoë las
“Marcus” los baie probleme op, die belangrikste een is die integrasie-interaksie tussen X5-inligtingstelsels en die staatsinligtingstelsel vir gemerkte produkte (GIS MP) om die beweging van gemerkte produkte op te spoor. Die platform stoor ook alle etiketteringkodes wat deur ons ontvang is en die hele geskiedenis van die beweging van hierdie kodes oor voorwerpe, en help om hergradering van gemerkte produkte uit te skakel. Deur die voorbeeld van tabakprodukte te gebruik, wat by die eerste groepe gemerkte goedere ingesluit is, bevat net een bakkievrag sigarette ongeveer 600 000 pakkies, wat elkeen sy eie unieke kode het. En die taak van ons stelsel is om die wettigheid van die bewegings van elke so 'n pak tussen pakhuise en winkels op te spoor en te verifieer, en uiteindelik die toelaatbaarheid van hul verkoop aan die eindkoper te verifieer. En ons teken ongeveer 125 000 kontanttransaksies per uur aan, en ons moet ook aanteken hoe elke so 'n pakkie in die winkel beland het. Dus, met inagneming van al die bewegings tussen voorwerpe, verwag ons tien miljarde rekords per jaar.
Span M
Ten spyte van die feit dat Marcus as 'n projek binne X5 beskou word, word dit geïmplementeer deur 'n produkbenadering te gebruik. Die span werk volgens Scrum. Die projek het verlede somer begin, maar die eerste resultate het eers in Oktober gekom – ons eie span is volledig saamgestel, die stelselargitektuur is ontwikkel en toerusting is aangekoop. Nou het die span 16 mense, van wie ses betrokke is by backend- en frontend-ontwikkeling, van wie drie by stelselontleding betrokke is. Nog ses mense is betrokke by handleiding, vrag, outomatiese toetsing en produkinstandhouding. Daarbenewens het ons 'n SRE-spesialis.
Nie net ontwikkelaars skryf kode in ons span nie; byna al die ouens weet hoe om outotoetse te programmeer en te skryf, skrifte en outomatiseringsskrifte te laai. Ons gee spesiale aandag hieraan, aangesien selfs produkondersteuning 'n hoë vlak van outomatisering vereis. Ons probeer altyd om kollegas wat nog nie voorheen geprogrammeer het, raad te gee en te help nie, en gee vir hulle 'n paar klein take om aan te werk.
As gevolg van die koronaviruspandemie het ons die hele span na afgeleë werk oorgeplaas; die beskikbaarheid van alle hulpmiddels vir ontwikkelingsbestuur, die ingeboude werkvloei in Jira en GitLab het dit moontlik gemaak om hierdie stadium maklik te slaag. Die maande wat op afstand deurgebring is, het getoon dat die span se produktiwiteit nie daaronder ly nie; vir baie het die gemak by die werk toegeneem, die enigste ding wat ontbreek was regstreekse kommunikasie.
Afgeleë spanvergadering
Vergaderings tydens afstandwerk
Tegnologie stapel van die oplossing
Die standaardbewaarplek en CI/CD-instrument vir X5 is GitLab. Ons gebruik dit vir kodeberging, deurlopende toetsing en ontplooiing na toets- en produksiebedieners. Ons gebruik ook die praktyk van kodehersiening, wanneer ten minste 2 kollegas veranderinge wat deur die ontwikkelaar aan die kode gemaak is, moet goedkeur. Statiese kode-ontleders SonarQube en JaCoCo help ons om ons kode skoon te hou en verseker die vereiste vlak van eenheidstoetsdekking. Alle veranderinge aan die kode moet deur hierdie kontroles gaan. Alle toetsskrifte wat met die hand uitgevoer word, word daarna geoutomatiseer.
Vir die suksesvolle implementering van besigheidsprosesse deur "Marcus", moes ons 'n aantal tegnologiese probleme oplos, omtrent elkeen in volgorde.
Taak 1. Die behoefte aan horisontale skaalbaarheid van die stelsel
Om hierdie probleem op te los, het ons 'n mikrodiensbenadering tot argitektuur gekies. Terselfdertyd was dit baie belangrik om die verantwoordelikheidsareas van die dienste te verstaan. Ons het probeer om hulle in sakebedrywighede te verdeel, met inagneming van die besonderhede van die prosesse. Byvoorbeeld, aanvaarding by 'n pakhuis is nie 'n baie gereelde, maar baie grootskaalse operasie, waartydens dit nodig is om vinnig inligting van die staatsreguleerder te verkry oor die eenhede van goedere wat aanvaar word, waarvan die aantal in een aflewering 600000 bereik. , kontroleer die toelaatbaarheid om hierdie produk in die pakhuis te aanvaar en stuur alle nodige inligting vir die pakhuisoutomatiseringstelsel terug. Maar versending vanaf pakhuise het 'n baie groter intensiteit, maar werk terselfdertyd met klein volumes data.
Ons implementeer alle dienste op 'n staatlose basis en probeer selfs interne bedrywighede in stappe verdeel, deur gebruik te maak van wat ons Kafka-selfonderwerpe noem. Dit is wanneer 'n mikrodiens 'n boodskap aan homself stuur, wat jou toelaat om die las op meer hulpbron-intensiewe bedrywighede te balanseer en produkinstandhouding vergemaklik, maar later meer daaroor.
Ons het besluit om modules vir interaksie met eksterne stelsels in aparte dienste te skei. Dit het dit moontlik gemaak om die probleem van gereeld veranderende API's van eksterne stelsels op te los, met feitlik geen impak op dienste met besigheidsfunksionaliteit nie.
Alle mikrodienste word in 'n OpenShift-groepering ontplooi, wat beide die probleem van die skaal van elke mikrodiens oplos en ons toelaat om nie derdeparty-diensontdekking-nutsgoed te gebruik nie.
Taak 2. Die behoefte om 'n hoë las en baie intensiewe data-uitruiling tussen platformdienste te handhaaf: Gedurende die projekbekendstellingsfase alleen word ongeveer 600 bewerkings per sekonde uitgevoer. Ons verwag dat hierdie waarde tot 5000 XNUMX ops/sek sal toeneem namate kleinhandelafsetpunte aan ons platform koppel.
Hierdie probleem is opgelos deur 'n Kafka-groepering te ontplooi en sinchrone interaksie tussen die platform se mikrodienste feitlik heeltemal te laat vaar. Dit vereis 'n baie noukeurige ontleding van die stelselvereistes, aangesien nie alle bewerkings asynchronies kan wees nie. Terselfdertyd stuur ons nie net gebeure deur die makelaar nie, maar stuur ook al die vereiste besigheidsinligting in die boodskap. Die boodskapgrootte kan dus 'n paar honderd kilogrepe bereik. Die boodskapgroottelimiet in Kafka vereis dat ons die boodskapgrootte akkuraat voorspel, en indien nodig, verdeel ons dit, maar die verdeling is logies, verwant aan sakebedrywighede.
Ons verdeel byvoorbeeld goedere wat in 'n motor aankom in bokse. Vir sinchroniese bewerkings word aparte mikrodienste toegewys en deeglike lastoetsing word uitgevoer. Die gebruik van Kafka het ons nog 'n uitdaging gebied - om die werking van ons diens te toets met inagneming van die Kafka-integrasie maak al ons eenheidstoetse asynchronies. Ons het hierdie probleem opgelos deur ons eie nutsmetodes te skryf met behulp van Embedded Kafka Broker. Dit skakel nie die behoefte uit om eenheidstoetse vir individuele metodes te skryf nie, maar ons verkies om komplekse gevalle met Kafka te toets.
Baie aandag is geskenk aan die opsporing van logs sodat hul TraceId nie verlore sou gaan wanneer uitsonderings voorkom tydens die bedryf van dienste of wanneer daar met Kafka bondel gewerk word nie. En as daar geen spesiale probleme met die eerste een was nie, dan word ons in die tweede geval gedwing om al die TraceId's waarmee die bondel gekom het, aan te teken en een te kies om voort te gaan met opsporing. Dan, wanneer hy deur die oorspronklike TraceId soek, sal die gebruiker maklik uitvind waarmee die opsporing voortgegaan het.
Taak 3. Die behoefte om 'n groot hoeveelheid data te stoor: Meer as 1 miljard etikette per jaar vir tabak alleen kom na X5. Hulle benodig konstante en vinnige toegang. In totaal moet die stelsel sowat 10 miljard rekords van die bewegingsgeskiedenis van hierdie gemerkte goedere verwerk.
Om die derde probleem op te los, is die NoSQL-databasis MongoDB gekies. Ons het 'n skerf van 5 nodusse gebou en elke nodus het 'n Replika Stel van 3 bedieners. Dit laat jou toe om die stelsel horisontaal te skaal, nuwe bedieners by die groep te voeg en die fouttoleransie daarvan te verseker. Hier het ons nog 'n probleem teëgekom - om transaksionaliteit in die mongo-groepering te verseker, met inagneming van die gebruik van horisontaal skaalbare mikrodienste. Byvoorbeeld, een van die take van ons stelsel is om pogings te identifiseer om produkte met dieselfde etiketteringkodes te herverkoop. Hier verskyn oorleggings met foutiewe skanderings of foutiewe bewerkings deur kassiere. Ons het gevind dat sulke duplikate beide kan voorkom binne een Kafka bondel wat verwerk word, en binne twee bondels wat parallel verwerk word. Dus, om vir duplikate na te gaan deur die databasis navraag te doen, het niks opgelewer nie. Vir elke mikrodiens het ons die probleem afsonderlik opgelos op grond van die besigheidslogika van hierdie diens. Byvoorbeeld, vir tjeks het ons 'n tjek in die bondel bygevoeg en aparte verwerking vir die voorkoms van duplikate wanneer dit ingevoeg word.
Om te verseker dat gebruikers se werk met die geskiedenis van bedrywighede geensins die belangrikste ding – die funksionering van ons besigheidsprosesse – raak nie, het ons alle historiese data in 'n aparte diens geskei met 'n aparte databasis, wat ook inligting deur Kafka ontvang. . Op hierdie manier werk gebruikers met 'n geïsoleerde diens sonder om die dienste wat data vir deurlopende bedrywighede verwerk, te beïnvloed.
Taak 4: Waglys herverwerking en monitering:
In verspreide stelsels ontstaan probleme en foute onvermydelik in die beskikbaarheid van databasisse, rye en eksterne databronne. In die geval van Marcus is die bron van sulke foute integrasie met eksterne stelsels. Dit was nodig om 'n oplossing te vind wat herhaalde versoeke vir foutiewe antwoorde met 'n sekere tydsverloop sou toelaat, maar terselfdertyd nie ophou om suksesvolle versoeke in die hoofry te verwerk nie. Vir hierdie doel is die sogenaamde "onderwerpgebaseerde herprobeer"-konsep gekies. Vir elke hoofonderwerp word een of meer herprobeer-onderwerpe geskep waarna foutiewe boodskappe gestuur word en terselfdertyd word die vertraging in die verwerking van boodskappe van die hoofonderwerp uitgeskakel. Interaksie skema -
Om so 'n skema te implementeer, het ons die volgende nodig gehad: om hierdie oplossing met Spring te integreer en kodeduplisering te vermy. Terwyl ons op die web geblaai het, het ons op 'n soortgelyke oplossing afgekom wat gebaseer is op Spring BeanPostProccessor, maar dit het vir ons onnodig omslagtig gelyk. Ons span het 'n eenvoudiger oplossing gemaak wat ons in staat stel om by die Lente-siklus te integreer vir die skep van verbruikers en addisioneel herprobeer verbruikers by te voeg. Ons het 'n prototipe van ons oplossing aan die Spring-span aangebied, jy kan dit sien . Die aantal Herprobeer-verbruikers en die aantal pogings vir elke verbruiker word deur parameters gekonfigureer, afhangende van die behoeftes van die besigheidsproses, en vir alles om te werk, is al wat oorbly om die annotasie by te voeg org.springframework.kafka.annotation.KafkaListener , wat aan alle Spring-ontwikkelaars bekend is.
As die boodskap nie verwerk kon word na alle herproberingspogings nie, gaan dit na DLT (dooie letteronderwerp) met Spring DeadLetterPublishingRecoverer. Op versoek van ondersteuning het ons hierdie funksionaliteit uitgebrei en 'n aparte diens geskep wat jou toelaat om boodskappe te sien wat in DLT, stackTrace, traceId en ander nuttige inligting daaroor ingesluit is. Daarbenewens is monitering en waarskuwings by alle DLT-onderwerpe gevoeg, en nou is die verskyning van 'n boodskap in 'n DLT-onderwerp 'n rede om 'n defek te ontleed en reg te stel. Dit is baie gerieflik - met die naam van die onderwerp verstaan ons dadelik in watter stap van die proses die probleem ontstaan het, wat die soektog na die oorsaak daarvan aansienlik versnel.
Onlangs het ons 'n koppelvlak geïmplementeer wat ons in staat stel om boodskappe weer te stuur deur ons ondersteuning te gebruik nadat die oorsake daarvan uitgeskakel is (byvoorbeeld die herstel van die funksionaliteit van die eksterne stelsel) en natuurlik die ooreenstemmende defek vir analise vasgestel het. Dit is hier waar ons self-onderwerpe handig te pas kom: om nie 'n lang verwerkingsketting te herbegin nie, kan jy dit vanaf die verlangde stap herbegin.
Platform werking
Die platform is reeds in produktiewe werking, elke dag voer ons aflewerings en verskepings uit, verbind nuwe verspreidingsentrums en winkels. As deel van die loodswerk werk die stelsel met die produkgroepe "Tabak" en "Skoene".
Ons hele span neem deel aan die uitvoer van vlieëniers, ontleed opkomende probleme en maak voorstelle vir die verbetering van ons produk, van die verbetering van logs tot die verandering van prosesse.
Om nie ons foute te herhaal nie, word alle gevalle wat tydens die vlieënier gevind word, in outomatiese toetse weerspieël. Die teenwoordigheid van 'n groot aantal outotoetse en eenheidstoetse laat jou toe om regressietoetse uit te voer en 'n hotfix letterlik binne 'n paar uur te installeer.
Nou gaan ons voort om ons platform te ontwikkel en te verbeter, en staan voortdurend nuwe uitdagings in die gesig. As u belangstel, sal ons in die volgende artikels oor ons oplossings praat.
Bron: will.com