2019az geroztik, Errusiak derrigorrezko etiketatzeari buruzko legea du. Legea ez da ondasun-talde guztietan aplikatzen, eta produktu-taldeen derrigorrezko etiketatzea indarrean jartzeko datak desberdinak dira. Tabakoa, oinetakoak eta sendagaiak izango dira derrigorrezko etiketatuko lehenak; beste produktu batzuk gehituko dira geroago, adibidez, lurrinak, ehunak eta esnea. Legegintza-berrikuntza honek produktu baten bizitza-kate osoa jarraipena egiteko aukera emango dion informatika-soluzio berriak garatzea bultzatu zuen azken kontsumitzaileak ekoizpenetik erostera arte, prozesuko parte-hartzaile guztien artean: bai estatua bera, bai salgaiak saltzen dituzten erakunde guztien artean. derrigorrezko etiketatzea.
X5-en, etiketatutako ondasunen jarraipena egingo duen eta estatuarekin eta hornitzaileekin datuak trukatuko dituen sistemari "Marcus" deitzen zaio. Esan dezagun ordenan nola eta nork garatu duen, zein den bere teknologia pila eta zergatik daukagun harro egoteko zerbait.
Benetako High Load
"Marcus"-ek arazo asko konpontzen ditu, nagusia X5 informazio sistemen eta etiketatutako produktuen estatuko informazio sistemaren (GIS MP) arteko interakzioa da etiketatutako produktuen mugimendua jarraitzeko. Plataformak guk jasotako etiketatze-kode guztiak eta kode horiek objektuetan zehar mugitzearen historia osoa gordetzen ditu, eta etiketatutako produktuen birkalifikazioa kentzen laguntzen du. Etiketatutako produktuen lehen taldeetan sartu ziren tabako-produktuen adibidea erabiliz, zigarro-kamioi bakar batek 600 pakete inguru ditu, eta bakoitzak bere kode berezia du. Eta gure sistemaren zeregina da biltegi eta denden arteko pakete bakoitzaren mugimenduen legezkotasuna kontrolatzea eta egiaztatzea, eta azken finean, azken erosleari saltzea onargarria den egiaztatzea. Eta 000 diru-transakzio inguru erregistratzen ditugu orduko, eta horrelako pakete bakoitza dendan nola sartu zen ere erregistratu behar dugu. Horrela, objektuen arteko mugimendu guztiak kontuan hartuta, urtean hamar mila milioi erregistro espero ditugu.
M taldea
Marcus X5-en barruan proiektutzat hartzen den arren, produktuaren ikuspegia erabiliz inplementatzen ari da. Taldeak Scrum-en arabera egiten du lan. Proiektua joan den udan hasi zen, baina lehen emaitzak urrian baino ez ziren iritsi: gure taldea guztiz osatu zen, sistemaren arkitektura garatu eta ekipamendua erosi zen. Orain taldeak 16 pertsona ditu, horietatik sei backend eta frontend garapenean parte hartzen dutenak, horietatik hiru sistemaren analisian. Beste sei lagunek eskuzko, kargako, proba automatikoetan eta produktuen mantentze-lanetan parte hartzen dute. Horrez gain, SRE espezialista bat dugu.
Garatzaileek ez dute soilik kodea idazten gure taldean; ia mutil guztiek dakite autotestak programatzen eta idazten, scriptak kargatzen eta automatizazio scriptak. Arreta berezia jartzen diogu horri, produktuen laguntzak ere automatizazio maila handia eskatzen baitu. Beti saiatzen gara aurretik programatu ez duten lankideei aholkuak ematen eta laguntzen, eta lan txiki batzuk ematen dizkiegu.
Coronavirus pandemia dela eta, talde osoa urruneko lanera pasa genuen; garapena kudeatzeko tresna guztien eskuragarritasunak, Jira eta GitLab-en eraikitako lan-fluxuak etapa hau erraz gainditzea ahalbidetu zuten. Urrutitik igarotako hilabeteek erakutsi zuten taldearen produktibitateak ez zuela horren ondorioz kaltetu; askorentzat laneko erosotasuna handitu zen, falta zen bakarra zuzeneko komunikazioa zen.
Urruneko taldearen bilera
Bilerak urrutiko lanetan
Soluzioaren pila teknologikoa
X5rako biltegi estandarra eta CI/CD tresna GitLab da. Kodea biltegiratzeko, etengabeko probak egiteko eta proba eta ekoizpen zerbitzarietarako inplementatzeko erabiltzen dugu. Kodea berrikusteko praktika ere erabiltzen dugu, gutxienez 2 lankidek garatzaileak kodean egindako aldaketak onartu behar dituztenean. SonarQube eta JaCoCo kode estatikoko analizatzaileek gure kodea garbi mantentzen eta unitate-testen estaldura-maila ziurtatzen laguntzen digute. Kodearen aldaketa guztiak egiaztapen hauetatik pasatu behar dira. Eskuz exekutatzen diren proba-script guztiak automatizatu egiten dira gero.
"Marcusek" negozio-prozesuak arrakastaz ezartzeko, arazo teknologiko batzuk konpondu behar izan genituen, bakoitzari buruz ordenan.
1. ataza. Sistemaren eskalagarritasun horizontalaren beharra
Arazo hau konpontzeko, arkitekturarako mikrozerbitzuen ikuspegia aukeratu dugu. Aldi berean, oso garrantzitsua zen zerbitzuen ardura-eremuak ulertzea. Negozio-eragiketetan banatzen saiatu gara, prozesuen berezitasunak kontuan hartuta. Esate baterako, biltegi batean onartzea ez da oso maiz, baina eskala handiko eragiketa, eta horretan beharrezkoa da estatuko erregulatzaileengandik onartzen diren ondasun-unitateei buruzko informazioa azkar eskuratzea, zeina entrega batean 600000ra iristen den. , egiaztatu produktu hau biltegian onartzeko onargarria den eta biltegiko automatizazio sistemarako beharrezko informazio guztia itzuli. Baina biltegietatik bidalketak intentsitate handiagoa du, baina, aldi berean, datu-bolumen txikiekin funtzionatzen du.
Zerbitzu guztiak estaturik gabe ezartzen ditugu eta barne-eragiketak urratsetan banatzen saiatzen gara ere, Kafkaren auto-gaiak deitzen ditugunak erabiliz. Hau da mikrozerbitzu batek bere buruari mezu bat bidaltzen dionean, eta horri esker, baliabideen erabilera handiagoko eragiketetan karga orekatzeko eta produktuaren mantentze-lanak errazten dira, baina gehiago geroago.
Kanpo sistemekin interakziorako moduluak zerbitzu bereizietan bereiztea erabaki genuen. Horri esker, kanpoko sistemen APIak maiz aldatzen diren arazoa konpontzea ahalbidetu zuen, negozio funtzionaltasuna duten zerbitzuetan ia eraginik gabe.
Mikrozerbitzu guztiak OpenShift kluster batean zabaltzen dira, eta horrek mikrozerbitzu bakoitza eskalatzearen arazoa konpontzen du eta hirugarrenen Service Discovery tresnak ez erabiltzeko aukera ematen digu.
2. ataza. Plataformako zerbitzuen artean karga handia eta datu-truke oso intentsiboa mantentzeko beharra: Proiektua abiarazteko fasean bakarrik, segundoko 600 eragiketa inguru egiten dira. Saltokiak gure plataformara konektatzen diren heinean balio hori 5000 operazio/seg-ra igotzea espero dugu.
Arazo hau Kafka kluster bat zabalduz eta plataformako mikrozerbitzuen arteko elkarrekintza sinkronoa ia erabat alde batera utzita konpondu zen. Horrek sistemaren eskakizunen azterketa oso zehatza eskatzen du, eragiketa guztiak ezin baitira asinkronoak izan. Aldi berean, brokeraren bidez gertaerak transmititzeaz gain, mezuan beharrezko negozio-informazio guztia ere transmititzen dugu. Horrela, mezuaren tamaina ehunka kilobytera irits daiteke. Kafka-n mezuen tamainaren mugak mezuaren tamaina zehatz-mehatz iragartzea eskatzen digu, eta behar izanez gero, banatzen ditugu, baina zatiketa logikoa da, negozio-eragiketekin lotuta.
Adibidez, kotxe batean iristen diren salgaiak kutxatan banatzen ditugu. Eragiketa sinkronikoetarako, mikrozerbitzu bereiziak esleitzen dira eta karga proba sakonak egiten dira. Kafka erabiltzeak beste erronka bat aurkeztu zigun: Kafkaren integrazioa kontuan hartuta gure zerbitzuaren funtzionamendua probatzeak gure unitate-proba guztiak asinkronoak bihurtzen ditu. Arazo hau gure erabilgarritasun-metodoak idatziz konpondu dugu Embedded Kafka Broker erabiliz. Horrek ez du metodo indibidualetarako unitate-probak idazteko beharra kentzen, baina nahiago dugu kasu konplexuak probatu Kafka erabiliz.
Erregistroen jarraipenari arreta handia jarri zitzaion, haien TraceId-a galdu ez zedin, zerbitzuen funtzionamenduan edo Kafka batch-ekin lan egiten denean salbuespenak gertatzen direnean. Eta lehenengoarekin arazo berezirik ez bazegoen, bigarren kasuan loteak zekartzan TraceId guztiak erregistratzera behartuta gaude eta bat hautatzen jarraitzeko. Ondoren, jatorrizko TraceId-aren bidez bilatzean, erabiltzaileak erraz jakingo du zeinekin jarraitu duen trazadura.
3. ataza. Datu kopuru handia gordetzeko beharra: Urtean 1 milioi etiketa baino gehiago tabakorako bakarrik iristen dira X5-era. Sarbide etengabea eta azkarra behar dute. Guztira, sistemak etiketatutako ondasun horien mugimenduaren historiaren 10 milioi erregistro inguru prozesatu behar ditu.
Hirugarren arazoa konpontzeko, NoSQL datu-basea MongoDB aukeratu zen. 5 nodoko zati bat eraiki dugu eta nodo bakoitzak 3 zerbitzariko Erreplika Multzo bat du. Horri esker, sistema horizontalki eskala dezakezu, zerbitzari berriak klusterrean gehituz eta akatsen tolerantzia bermatuz. Hemen beste arazo bat topatu dugu: mongo klusterrean transakzionaltasuna bermatzea, horizontalki eskalagarriak diren mikrozerbitzuen erabilera kontuan hartuta. Adibidez, gure sistemaren zereginetako bat etiketatze-kode berdinak dituzten produktuak berriro saltzeko saiakerak identifikatzea da. Hemen, kutxazainek egindako miaketa okerrekin edo kutxazainen eragiketa okerrekin gainjartzeak agertzen dira. Bikoiztu horiek prozesatzen ari diren Kafka lote batean eta paraleloan prozesatzen diren bi loteetan gerta daitezkeela ikusi dugu. Horrela, datu-baseari kontsultatuz bikoiztuak egiaztatzeak ez zuen ezer eman. Mikrozerbitzu bakoitzeko, arazoa bereizita konpondu dugu zerbitzu honen negozio-logikan oinarrituta. Esate baterako, egiaztapenetarako, txeke bat gehitu dugu lotearen barruan eta prozesaketa bereizia txertatzean bikoiztuak agertzeko.
Eragiketen historiarekin erabiltzaileen lanak inola ere garrantzitsuenari eraginik ez diezaion ziurtatzeko - gure negozio-prozesuen funtzionamenduan, datu historiko guztiak zerbitzu bereizi batean banatu ditugu datu-base bereizi batekin, eta Kafkaren bidez ere informazioa jasotzen du. . Horrela, erabiltzaileek zerbitzu isolatu batekin lan egiten dute, etengabeko eragiketetarako datuak prozesatzen dituzten zerbitzuetan eragin gabe.
4. ataza: ilarak birprozesatzea eta kontrolatzea:
Banatutako sistemetan, arazoak eta akatsak sortzen dira ezinbestean datu-baseen, ilararen eta kanpoko datu-iturrien erabilgarritasunean. Marcusen kasuan, horrelako akatsen iturria kanpoko sistemekin integratzea da. Beharrezkoa zen denbora-muga zehatz batekin erantzun okerrak errepikatzeko eskaerak baimenduko zituen irtenbide bat bilatu, baina, aldi berean, ilara nagusian eskaera arrakastatsuak prozesatzeari utzi gabe. Horretarako, “topic based retry” kontzeptua aukeratu zen. Gai nagusi bakoitzeko, berriro saiakera-gai bat edo gehiago sortzen dira, zeinetara mezu okerrak bidaltzen diren eta, aldi berean, gai nagusiko mezuak prozesatzeko atzerapena ezabatzen da. Interakzio eskema -
Horrelako eskema bat ezartzeko, honako hau behar genuen: irtenbide hau Spring-ekin integratzea eta kodea bikoiztea saihestea. Sarean nabigatzen ari ginela, Spring BeanPostProccessor-en oinarritutako antzeko irtenbide bat topatu genuen, baina alferrik astuna iruditu zitzaigun. Gure taldeak irtenbide sinpleagoa egin du, kontsumitzaileak sortzeko Udaberriko zikloan integratzeko eta, gainera, Berriro Saiatzeko Kontsumitzaileak gehitzeko. Gure irtenbidearen prototipoa eskaini genion Spring taldeari, ikus dezakezue . Berriro saiatu kontsumitzaileen kopurua eta kontsumitzaile bakoitzaren saiakera kopurua parametroen bidez konfiguratzen dira, negozio-prozesuaren beharren arabera, eta denak funtziona dezan, org.springframework.kafka.annotation.KafkaListener oharpena gehitzea besterik ez da geratzen. , Spring garatzaile guztientzat ezaguna dena.
Berriro saiakera guztien ondoren mezua ezin bada prozesatu, Spring DeadLetterPublishingRecoverer erabiliz DLTra doa (letra hildako gaia). Laguntza eskatuta, funtzionalitate hau zabaldu dugu eta zerbitzu bereizi bat sortu dugu, DLT, stackTrace, traceId eta haiei buruzko beste informazio erabilgarria barne dauden mezuak ikusteko aukera ematen duena. Gainera, jarraipena eta alertak gehitu zitzaizkien DLT gai guztiei, eta orain, hain zuzen ere, DLT gai batean mezu bat agertzea akats bat aztertzeko eta konpontzeko arrazoia da. Hau oso erosoa da - gaiaren izenaren arabera, berehala ulertzen dugu prozesuaren zein urratsetan sortu den arazoa, eta horrek nabarmen bizkortzen du bere kausaren bilaketa.
Duela gutxi, gure euskarria erabiliz mezuak berriro bidaltzeko aukera ematen digun interfaze bat ezarri dugu haien kausak ezabatu ondoren (adibidez, kanpoko sistemaren funtzionaltasuna berreskuratu) eta, jakina, analisirako dagokion akatsa ezarriz. Hona hemen gure auto-gaiak ondo etortzen dira: prozesatzeko kate luze bat berrabiarazteko, nahi duzun urratsetik berrabiarazi dezakezu.
Plataformaren funtzionamendua
Plataforma dagoeneko funtzionamendu produktiboan dago, egunero bidalketak eta bidalketak egiten ditugu, banaketa zentro eta denda berriak konektatzen ditugu. Pilotuaren barruan, sistemak "Tabako" eta "Oinetakoak" produktu taldeekin lan egiten du.
Gure talde osoak pilotuak egiten parte hartzen du, sortzen ari diren arazoak aztertzen eta gure produktua hobetzeko iradokizunak egiten ditu, erregistroak hobetzen hasi eta prozesuak aldatzeraino.
Gure akatsak ez errepikatzeko, pilotuan aurkitutako kasu guztiak proba automatizatuetan islatzen dira. Autotest eta unitate proba ugari egoteak erregresio probak egiteko eta konponketa bat literalki ordu gutxiren buruan instalatzeko aukera ematen du.
Orain gure plataforma garatzen eta hobetzen jarraitzen dugu, eta etengabe erronka berriei aurre egiten. Interesa baduzu, gure irtenbideei buruz hitz egingo dugu hurrengo artikuluetan.
Iturria: www.habr.com