Sûnt 2019 hat Ruslân in wet oer ferplichte etikettering. De wet jildt net foar alle groepen fan guod, en de datums foar it yngean fan ferplichte etikettering foar produktgroepen binne oars. Tabak, skuon en medisinen sille de earste wêze dy't ferplichte etiketten ûnderwurpen wurde; oare produkten wurde letter tafoege, bygelyks parfum, tekstyl en molke. Dizze wetjouwende ynnovaasje soarge foar de ûntwikkeling fan nije IT-oplossingen dy't it mooglik meitsje om de heule libbensketen fan in produkt te folgjen fan produksje oant oankeap troch de einkonsumint, oan alle dielnimmers oan it proses: sawol de steat sels as alle organisaasjes dy't guod ferkeapje mei ferplichte labeling.
Yn X5, it systeem dat sil track label guod en útwikseling gegevens mei de steat en leveransiers hjit "Marcus". Litte wy jo yn oarder fertelle hoe en wa't it ûntwikkele hat, wat de technologystapel is, en wêrom wy wat hawwe om grutsk op te wêzen.
Echte HighLoad
"Marcus" lost in protte problemen op, de wichtichste is de yntegraasje-ynteraksje tusken X5-ynformaasjesystemen en it steatynformaasjesysteem foar labele produkten (GIS MP) om de beweging fan labele produkten te folgjen. It platfoarm bewarret ek alle troch ús ûntfongen etikettenkoades en de heule skiednis fan 'e beweging fan dizze koades oer objekten, en helpt it opnij klassen fan labele produkten te eliminearjen. Mei it foarbyld fan tabaksprodukten, dy't opnommen binne yn 'e earste groepen fan labele guod, befettet mar ien frachtwein sigaretten sa'n 600 pakjes, dy't elk in eigen unike koade hawwe. En de taak fan ús systeem is om de wettichheid fan 'e bewegingen fan elk sa'n pakket tusken pakhuzen en winkels te folgjen en te ferifiearjen, en úteinlik de akseptabiliteit fan har ferkeap oan' e einkeaper te kontrolearjen. En wy registrearje sawat 000 cashtransaksjes per oere, en wy moatte ek opnimme hoe't elk sa'n pak yn 'e winkel kaam. Sa, rekken hâldend mei alle bewegingen tusken objekten, wy ferwachtsje tsientallen miljarden records yn it jier.
Team M
Nettsjinsteande it feit dat Marcus wurdt beskôge as in projekt binnen X5, wurdt it ymplementearre mei in produktoanpak. It team wurket neffens Scrum. It projekt begon ferline simmer, mar de earste resultaten kamen pas yn oktober - ús eigen team wie folslein gearstald, de systeemarsjitektuer waard ûntwikkele en apparatuer waard oankocht. No hat it team 16 minsken, wêrfan seis belutsen binne by backend- en frontendûntwikkeling, wêrfan trije belutsen binne by systeemanalyse. Seis mear minsken binne belutsen by hantlieding, laden, automatisearre testen en produktûnderhâld. Dêrneist hawwe wy in SRE-spesjalist.
Net allinich ûntwikkelders skriuwe koade yn ús team; hast alle jonges witte hoe't se autotests programmearje en skriuwe, skripts laden en automatisearringsskripts. Wy betelje spesjaal omtinken foar dit, om't sels produktstipe in heech nivo fan automatisearring fereasket. Wy besykje altyd kollega's te advisearjen en te helpen dy't net earder programmearre hawwe, en jouwe se wat lytse taken om oan te wurkjen.
Fanwegen de pandemy fan coronavirus hawwe wy it heule team oerbrocht nei wurk op ôfstân; de beskikberens fan alle ark foar ûntwikkelingsbehear, de boude workflow yn Jira en GitLab makken it mooglik om dit stadium maklik troch te gean. De moannen dy't op ôfstân trochbrocht binne lieten sjen dat de produktiviteit fan it team net lije as gefolch; foar in protte gie it treast op it wurk ta, it iennichste wat mist wie live kommunikaasje.
Teamgearkomste op ôfstân
Gearkomsten tidens wurk op ôfstân
Technology stack fan de oplossing
It standert repository en CI / CD-ark foar X5 is GitLab. Wy brûke it foar koade opslach, trochgeande testen, en ynset foar test- en produksjeservers. Wy brûke ek de praktyk fan koade review, as op syn minst 2 kollega's moatte goedkarre feroarings makke troch de ûntwikkelder oan de koade. Statyske koade-analyzers SonarQube en JaCoCo helpe ús ús koade skjin te hâlden en it fereaske nivo fan ienheidstestdekking te garandearjen. Alle feroarings oan de koade moatte gean troch dizze kontrôles. Alle testskripts dy't mei de hân wurde útfierd wurde dêrnei automatisearre.
Foar de suksesfolle ymplemintaasje fan saaklike prosessen troch "Marcus" moasten wy in oantal technologyske problemen oplosse, oer elk yn oarder.
Taak 1. De needsaak foar horizontale scalability fan it systeem
Om dit probleem op te lossen, hawwe wy keazen foar in mikroservice-oanpak foar arsjitektuer. Tagelyk wie it tige wichtich om de ferantwurdlikensgebieten fan 'e tsjinsten te begripen. Wy besochten se te ferdielen yn saaklike operaasjes, rekken hâldend mei de spesifikaasjes fan 'e prosessen. Bygelyks, akseptaasje yn in pakhús is net in heul faak, mar heul grutskalige operaasje, wêryn't it needsaaklik is om fluch ynformaasje te krijen fan 'e steatsregulator oer de ienheden fan guod dy't wurde aksepteare, wêrfan it oantal yn ien levering 600000 berikt. , kontrolearje de akseptabiliteit fan it akseptearjen fan dit produkt yn it pakhús en bring alle nedige ynformaasje werom foar it automatisearringsysteem fan it pakhús. Mar ferstjoering fan pakhuzen hat in folle gruttere yntensiteit, mar wurket tagelyk mei lytse voluminten fan gegevens.
Wy implementearje alle tsjinsten op in steatleaze basis en besykje sels ynterne operaasjes te ferdielen yn stappen, mei help fan wat wy Kafka sels-ûnderwerpen neame. Dit is as in mikrotsjinst in berjocht nei himsels stjoert, wêrtroch jo de lading op mear boarne-yntinsive operaasjes kinne balansearje en produktûnderhâld ferienfâldigje, mar dêroer letter mear.
Wy besletten om modules te skieden foar ynteraksje mei eksterne systemen yn aparte tsjinsten. Dit makke it mooglik om it probleem op te lossen fan faak feroarjende API's fan eksterne systemen, mei praktysk gjin ynfloed op tsjinsten mei saaklike funksjonaliteit.
Alle mikrotsjinsten wurde ynset yn in OpenShift-kluster, dy't sawol it probleem oplost fan skaalfergrutting fan elke mikrotsjinst en lit ús net brûke fan tredden Service Discovery-ark.
Taak 2. De needsaak om in hege lading en tige yntinsive gegevensútwikseling tusken platfoarmtsjinsten te behâlden: Allinich yn 'e projektstartfaze wurde sawat 600 operaasjes per sekonde útfierd. Wy ferwachtsje dat dizze wearde sil tanimme nei 5000 ops / sek as detailhannels ferbine mei ús platfoarm.
Dit probleem waard oplost troch it ynsetten fan in Kafka-kluster en hast folslein it ferlitten fan syngroane ynteraksje tusken de mikrotsjinsten fan it platfoarm. Dit fereasket in heul soarchfâldige analyze fan 'e systeemeasken, om't net alle operaasjes asynchrone kinne wêze. Tagelyk stjoere wy net allinich eveneminten troch de makelder, mar stjoere ek alle fereaske saaklike ynformaasje oer yn it berjocht. Sa kin de berjochtgrutte inkele hûnderten kilobytes berikke. De limyt fan berjochtgrutte yn Kafka fereasket dat wy de berjochtgrutte sekuer foarsizze, en as it nedich is, ferdiele wy se, mar de ferdieling is logysk, relatearre oan saaklike operaasjes.
Wy ferdielen bygelyks guod dat yn in auto oankomt yn doazen. Foar syngroane operaasjes wurde aparte mikrotsjinsten tawiisd en yngeande ladingstests wurde útfierd. It brûken fan Kafka joech ús in oare útdaging - it testen fan 'e wurking fan ús tsjinst mei rekkening mei de Kafka-yntegraasje makket al ús ienheidstests asynchron. Wy hawwe dit probleem oplost troch ús eigen nutsmethoden te skriuwen mei Embedded Kafka Broker. Dit elimineert de needsaak om ienheidstests te skriuwen foar yndividuele metoaden net, mar wy wolle leaver komplekse gefallen testen mei Kafka.
In protte omtinken waard betelle oan tracing logs sadat har TraceId net ferlern gean soe as útsûnderingen foarkomme tidens de operaasje fan tsjinsten of by it wurkjen mei Kafka batch. En as d'r gjin spesjale problemen wiene mei de earste, dan wurde wy yn it twadde gefal twongen om alle TraceIds te loggen wêrmei de batch kaam en ien selektearje om troch te gean mei tracing. Dan, by it sykjen mei it orizjinele TraceId, sil de brûker maklik útfine wêrmei't de tracing trochgie.
Taak 3. De needsaak om in grutte hoemannichte gegevens op te slaan: Mear dan 1 miljard etiketten yn 't jier foar tabak allinich komme nei X5. Se fereaskje konstante en flugge tagong. Yn totaal moat it systeem sawat 10 miljard records ferwurkje fan 'e bewegingsskiednis fan dizze markearre guod.
Om it tredde probleem op te lossen, waard de NoSQL-database MongoDB keazen. Wy hawwe boud in shard fan 5 knopen en elke node hat in Replica Set fan 3 tsjinners. Hjirmei kinne jo it systeem horizontaal skaalje, nije tsjinners tafoegje oan it kluster en soargje foar syn skuldtolerânsje. Hjir hawwe wy in oar probleem tsjinkaam - it garandearjen fan transaksjonaliteit yn 'e mongo-kluster, rekken hâldend mei it gebrûk fan horizontaal skalberbere mikrotsjinsten. Bygelyks, ien fan 'e taken fan ús systeem is om besykjen te identifisearjen om produkten opnij te ferkeapjen mei deselde etikettekoades. Hjir ferskine overlays mei ferkearde scans of ferkearde operaasjes troch kassiers. Wy fûnen dat sokke duplikaten kinne foarkomme sawol binnen ien Kafka batch wurdt ferwurke, en binnen twa batches wurde ferwurke parallel. Sadwaande joech it kontrolearjen op duplikaten troch it freegjen fan de databank neat. Foar elke mikrotsjinst hawwe wy it probleem apart oplost op basis fan 'e saaklike logika fan dizze tsjinst. Bygelyks, foar kontrôles, hawwe wy in sjek tafoege binnen batch en aparte ferwurking foar it ferskinen fan duplikaten by it ynfoegjen.
Om te soargjen dat it wurk fan brûkers mei de skiednis fan operaasjes op gjin inkelde manier it wichtichste ding beynfloedet - it funksjonearjen fan ús saaklike prosessen, hawwe wy alle histoaryske gegevens skieden yn in aparte tsjinst mei in aparte database, dy't ek ynformaasje ûntfangt fia Kafka . Op dizze manier wurkje brûkers mei in isolearre tsjinst sûnder de tsjinsten te beynfloedzjen dy't gegevens ferwurkje foar oanhâldende operaasjes.
Taak 4: Wachtrige werferwurking en tafersjoch:
Yn ferdielde systemen ûntsteane ûnûntkomber problemen en flaters yn 'e beskikberens fan databases, wachtrigen en eksterne gegevensboarnen. Yn it gefal fan Marcus is de boarne fan sokke flaters yntegraasje mei eksterne systemen. It wie nedich om in oplossing te finen dy't werhelle oanfragen foar ferkearde antwurden mei wat spesifisearre timeout mooglik meitsje soe, mar tagelyk net stopje mei it ferwurkjen fan suksesfolle oanfragen yn 'e haadwachtrige. Foar dit doel waard keazen foar it saneamde "ûnderwerp basearre opnij besykjen" konsept. Foar elk haadûnderwerp wurde ien of mear probearje-ûnderwerpen oanmakke dêr't ferkearde berjochten nei stjoerd wurde en tagelyk wurdt de fertraging by it ferwurkjen fan berjochten út it haadûnderwerp eliminearre. Ynteraksjeskema -
Om sa'n skema út te fieren, hiene wy it folgjende nedich: dizze oplossing te yntegrearjen mei Spring en koadeduplikaasje te foarkommen. By it surfen op it web kamen wy in ferlykbere oplossing tsjin op basis fan Spring BeanPostProccessor, mar it like ús ûnnedich omslachtich. Us team hat in ienfâldiger oplossing makke wêrmei ús yntegrearje kinne yn 'e Spring-syklus foar it meitsjen fan konsuminten en ek konsuminten opnij tafoegje. Wy biede in prototype fan ús oplossing oan it Spring-team, jo kinne it sjen . It oantal konsuminten opnij besykje en it oantal besykjen foar elke konsumint wurde konfigureare troch parameters, ôfhinklik fan 'e behoeften fan it bedriuwsproses, en foar alles om te wurkjen, bliuwt allinich de annotaasje ta te foegjen org.springframework.kafka.annotation.KafkaListener , dy't bekend is foar alle Spring-ûntwikkelders.
As it berjocht koe net wurde ferwurke nei alle opnij besykjen, giet it nei DLT (deade letter ûnderwerp) mei help Spring DeadLetterPublishingRecoverer. Op fersyk fan stipe hawwe wy dizze funksjonaliteit útwreide en in aparte tsjinst makke wêrmei jo berjochten kinne besjen opnaam yn DLT, stackTrace, traceId en oare nuttige ynformaasje oer har. Dêrneist waarden tafersjoch en warskôgings tafoege oan alle DLT-ûnderwerpen, en no, yn feite, is it ferskinen fan in berjocht yn in DLT-ûnderwerp in reden om in defekt te analysearjen en te reparearjen. Dit is heul handich - troch de namme fan it ûnderwerp begripe wy fuortendaliks yn hokker stap fan it proses it probleem ûntstie, wat it sykjen nei syn woartel oarsaak signifikant fersnelt.
Meast resint hawwe wy in ynterface ymplementearre wêrmei ús berjochten opnij kinne ferstjoere mei help fan ús stipe nei it eliminearjen fan har oarsaken (bygelyks it werstellen fan 'e funksjonaliteit fan it eksterne systeem) en, fansels, it korrespondearjende defekt foar analyse fêststelle. Dit is wêr't ús selsûnderwerpen fan pas komme: om in lange ferwurkingsketen net opnij te begjinnen, kinne jo it opnij starte fanôf de winske stap.
Platfoarm Operaasje
It platfoarm is al yn produktive operaasje, elke dei fiere wy leveringen en ferstjoeren út, ferbine nije distribúsjesintra en winkels. As ûnderdiel fan 'e pilot wurket it systeem mei de produktgroepen "Tabak" en "Shoes".
Us heule team docht mei oan it útfieren fan pilots, analysearret opkommende problemen en makket suggestjes foar it ferbetterjen fan ús produkt, fan it ferbetterjen fan logs oant it feroarjen fan prosessen.
Om ús flaters net te werheljen, wurde alle gefallen fûn tidens de pilot werjûn yn automatisearre tests. De oanwêzigens fan in grut oantal autotests en ienheidstests kinne jo regressjetesten útfiere en in hotfix letterlik binnen in pear oeren ynstallearje.
No bliuwe wy ús platfoarm ûntwikkelje en ferbetterje, en stean konstant foar nije útdagings. As jo ynteressearre binne, sille wy prate oer ús oplossingen yn 'e folgjende artikels.
Boarne: www.habr.com