Od 2019. godine Rusija ima zakon o obaveznom označavanju. Zakon se ne odnosi na sve grupe roba, a datumi stupanja na snagu obaveznog označavanja za grupe proizvoda su različiti. Duvan, obuća i lijekovi prvi će biti podvrgnuti obaveznom označavanju, a drugi proizvodi će biti dodani kasnije, na primjer, parfemi, tekstil i mlijeko. Ova zakonska inovacija potaknula je razvoj novih IT rješenja koja će omogućiti praćenje cijelog životnog lanca proizvoda od proizvodnje do kupovine od strane krajnjeg potrošača, do svih sudionika u procesu: kako same države tako i svih organizacija koje prodaju robu sa obavezno obeležavanje.
U X5 sistem koji će pratiti označenu robu i razmjenjivati podatke sa državom i dobavljačima zove se “Marcus”. Hajde da vam kažemo redom kako i ko ga je razvio, koji je njegov tehnološki skup i zašto imamo čime da se ponosimo.
Real HighLoad
“Marcus” rješava mnoge probleme, a glavni je integracijska interakcija između X5 informacionih sistema i državnog informacionog sistema za označene proizvode (GIS MP) za praćenje kretanja označenih proizvoda. Platforma također pohranjuje sve kodove za označavanje koje smo primili i cjelokupnu povijest kretanja tih kodova po objektima, te pomaže u eliminaciji ponovnog gradiranja označenih proizvoda. Na primjeru duhanskih proizvoda, koji su uvršteni u prve grupe označene robe, samo jedan kamion cigareta sadrži oko 600 paklica, od kojih svaka ima svoju jedinstvenu šifru. A zadatak našeg sistema je da prati i provjerava zakonitost kretanja svakog takvog pakiranja između skladišta i radnji, te na kraju provjeri prihvatljivost njihove prodaje krajnjem kupcu. A mi bilježimo oko 000 gotovinskih transakcija na sat, a također moramo evidentirati kako je svaki takav paket dospio u radnju. Dakle, uzimajući u obzir sva kretanja između objekata, očekujemo desetine milijardi zapisa godišnje.
Tim M
Unatoč činjenici da se Marcus smatra projektom unutar X5, implementira se koristeći proizvodni pristup. Tim radi po Scrum-u. Projekat je počeo prošlog ljeta, ali su prvi rezultati stigli tek u oktobru - kompletno je okupljen vlastiti tim, razvijena arhitektura sistema i nabavljena oprema. Sada tim ima 16 ljudi, od kojih je šest uključeno u backend i frontend razvoj, od kojih su tri uključena u analizu sistema. Još šest ljudi uključeno je u ručno testiranje, učitavanje, automatizirano testiranje i održavanje proizvoda. Osim toga, imamo stručnjaka za SRE.
Ne samo programeri pišu kod u našem timu, gotovo svi momci znaju kako programirati i pisati autotestove, učitavati skripte i automatizacijske skripte. Tome posvećujemo posebnu pažnju, jer čak i podrška proizvoda zahtijeva visok nivo automatizacije. Uvijek se trudimo da savjetujemo i pomognemo kolegama koji do sada nisu programirali i dajemo im neke male zadatke na kojima će raditi.
Zbog pandemije koronavirusa, cijeli tim smo prebacili na daljinski rad; dostupnost svih alata za upravljanje razvojem, izgrađen radni tok u Jira i GitLabu omogućili su da se ova faza lako prođe. Mjeseci provedeni na daljinu pokazali su da produktivnost tima nije patila zbog toga; za mnoge se povećala udobnost na poslu, jedino što je nedostajalo bila je živa komunikacija.
Sastanak tima na daljinu
Sastanci tokom rada na daljinu
Tehnološki niz rješenja
Standardno spremište i CI/CD alat za X5 je GitLab. Koristimo ga za skladištenje koda, kontinuirano testiranje i implementaciju na servere za testiranje i proizvodnju. Takođe koristimo praksu pregleda koda, kada najmanje 2 kolege treba da odobre promjene koje je programer napravio u kodu. Statički analizatori koda SonarQube i JaCoCo nam pomažu da naš kod bude čist i osigurava potrebnu razinu pokrivenosti testom jedinica. Sve promjene koda moraju proći kroz ove provjere. Sve testne skripte koje se pokreću ručno su naknadno automatizirane.
Za uspješnu implementaciju poslovnih procesa od strane “Marcusa” morali smo riješiti niz tehnoloških problema, svaki po redu.
Zadatak 1. Potreba horizontalne skalabilnosti sistema
Da bismo riješili ovaj problem, odabrali smo mikroservisni pristup arhitekturi. Istovremeno, bilo je veoma važno razumjeti područja odgovornosti službi. Pokušali smo ih podijeliti na poslovne operacije, vodeći računa o specifičnostima procesa. Na primjer, prijem u skladištu nije vrlo česta, ali vrlo velika operacija, tokom koje je potrebno brzo dobiti od državnog regulatora informacije o jedinicama robe koja se prihvata, čiji broj u jednoj isporuci dostiže 600000 , provjerite prihvatljivost prijema ovog proizvoda u skladište i vratite sve potrebne informacije za sistem automatizacije skladišta. Ali pošiljka iz skladišta ima mnogo veći intenzitet, ali istovremeno radi sa malim količinama podataka.
Sve usluge implementiramo na bazi bez državljanstva i čak pokušavamo podijeliti interne operacije u korake, koristeći ono što nazivamo Kafkinim samo-temama. To je kada mikroservis sam sebi šalje poruku, što vam omogućava da uravnotežite opterećenje na resursno intenzivnijim operacijama i pojednostavljuje održavanje proizvoda, ali o tome kasnije.
Odlučili smo da odvojimo module za interakciju sa eksternim sistemima u zasebne servise. To je omogućilo rješavanje problema često mijenjanja API-ja eksternih sistema, bez ikakvog utjecaja na usluge s poslovnom funkcionalnošću.
Sve mikroservise su raspoređene u OpenShift klasteru, što rješava i problem skaliranja svake mikroservise i omogućava nam da ne koristimo alate za otkrivanje usluga treće strane.
Zadatak 2. Potreba za održavanjem visokog opterećenja i vrlo intenzivne razmjene podataka između servisa platforme: Samo u fazi pokretanja projekta izvede se oko 600 operacija u sekundi. Očekujemo da će se ova vrijednost povećati na 5000 operacija u sekundi kako se maloprodajna mjesta povezuju na našu platformu.
Ovaj problem je riješen postavljanjem Kafka klastera i gotovo potpunim napuštanjem sinhrone interakcije između mikroservisa platforme. Ovo zahtijeva vrlo pažljivu analizu sistemskih zahtjeva, jer ne mogu sve operacije biti asinhrone. Istovremeno, ne samo da prenosimo događaje preko brokera, već i sve potrebne poslovne informacije u poruci. Dakle, veličina poruke može doseći nekoliko stotina kilobajta. Ograničenje veličine poruke u Kafki zahtijeva od nas da precizno predvidimo veličinu poruke, a po potrebi ih i podijelimo, ali je podjela logična, vezana za poslovanje.
Na primjer, robu koja stiže automobilom dijelimo u kutije. Za sinhrone operacije dodjeljuju se odvojeni mikroservis i provodi se temeljno testiranje opterećenja. Korištenje Kafke predstavljalo nam je još jedan izazov - testiranje rada našeg servisa uzimajući u obzir Kafka integraciju čini sve naše testove jedinica asinhronim. Ovaj problem smo riješili pisanjem vlastitih uslužnih metoda koristeći Embedded Kafka Broker. Ovo ne eliminiše potrebu za pisanjem jediničnih testova za pojedinačne metode, ali mi radije testiramo složene slučajeve koristeći Kafku.
Puno pažnje je posvećeno praćenju logova kako se njihov TraceId ne bi izgubio kada dođe do izuzetaka tokom rada servisa ili kada se radi sa Kafka paketom. A ako nije bilo posebnih problema s prvim, onda smo u drugom slučaju primorani da evidentiramo sve TraceId-ove sa kojima je paket došao i odaberemo jedan za nastavak praćenja. Zatim, prilikom pretraživanja po originalnom TraceId-u, korisnik će lako saznati s kojim je praćenje nastavljeno.
Zadatak 3. Potreba za pohranjivanjem velike količine podataka: Više od milijardu etiketa godišnje samo za duhan dolazi na X1. Zahtevaju stalan i brz pristup. Ukupno, sistem mora obraditi oko 5 milijardi zapisa o istoriji kretanja ove označene robe.
Za rješavanje trećeg problema odabrana je NoSQL baza podataka MongoDB. Napravili smo dio od 5 čvorova i svaki čvor ima skup replika od 3 servera. Ovo vam omogućava da horizontalno skalirate sistem, dodajući nove servere u klaster i osigurate njegovu toleranciju grešaka. Ovdje smo naišli na još jedan problem – osiguranje transakcionosti u mongo klasteru, uzimajući u obzir korištenje horizontalno skalabilnih mikroservisa. Na primjer, jedan od zadataka našeg sistema je da identifikuje pokušaje preprodaje proizvoda sa istim kodovima za označavanje. Ovdje se pojavljuju preklapanja s pogrešnim skeniranjima ili pogrešnim operacijama blagajnika. Otkrili smo da se takvi duplikati mogu pojaviti kako unutar jedne Kafka serije koja se obrađuje, tako i unutar dvije serije koje se obrađuju paralelno. Dakle, provjera duplikata ispitivanjem baze podataka nije dala ništa. Za svaki mikroservis problem smo rješavali posebno na osnovu poslovne logike ovog servisa. Na primjer, za čekove smo dodali ček unutar serije i odvojenu obradu za pojavu duplikata prilikom umetanja.
Kako rad korisnika sa istorijom poslovanja ni na koji način ne utiče na najvažniju stvar - funkcionisanje naših poslovnih procesa, sve istorijske podatke smo izdvojili u poseban servis sa posebnom bazom podataka, koji takođe prima informacije preko Kafke. . Na ovaj način korisnici rade sa izoliranom uslugom bez utjecaja na servise koji obrađuju podatke za tekuće operacije.
Zadatak 4: Ponovna obrada i nadzor u redu čekanja:
U distribuiranim sistemima, problemi i greške se neizbežno javljaju u dostupnosti baza podataka, redova čekanja i eksternih izvora podataka. U slučaju Markusa, izvor takvih grešaka je integracija sa eksternim sistemima. Bilo je potrebno pronaći rješenje koje bi omogućilo ponovljene zahtjeve za pogrešne odgovore sa određenim vremenskim ograničenjem, ali u isto vrijeme ne zaustaviti obradu uspješnih zahtjeva u glavnom redu čekanja. U tu svrhu odabran je takozvani koncept ponovnog pokušaja zasnovanog na temi. Za svaku glavnu temu kreira se jedna ili više tema za ponovni pokušaj na koje se šalju pogrešne poruke i istovremeno se eliminiše kašnjenje u obradi poruka iz glavne teme. Šema interakcije -
Da bismo implementirali takvu šemu, bilo nam je potrebno sljedeće: integrirati ovo rješenje sa Springom i izbjeći dupliciranje koda. Surfajući internetom naišli smo na slično rješenje bazirano na Spring BeanPostProccessoru, ali nam se činilo nepotrebno glomaznim. Naš tim je napravio jednostavnije rešenje koje nam omogućava da se integrišemo u Spring ciklus za kreiranje potrošača i dodatno dodamo Retry Consumers. Ponudili smo prototip našeg rješenja Spring timu, možete ga vidjeti . Broj Retry Consumers i broj pokušaja za svakog potrošača konfiguriše se kroz parametre, u zavisnosti od potreba poslovnog procesa, a da bi sve funkcionisalo, ostaje samo da se doda napomena org.springframework.kafka.annotation.KafkaListener , koji je poznat svim Spring programerima.
Ako se poruka ne može obraditi nakon svih pokušaja ponovnog pokušaja, ona ide u DLT (tema mrtvog pisma) koristeći Spring DeadLetterPublishingRecoverer. Na zahtjev podrške, proširili smo ovu funkcionalnost i kreirali zasebnu uslugu koja vam omogućava da vidite poruke uključene u DLT, stackTrace, traceId i druge korisne informacije o njima. Dodatno, svim DLT temama je dodat nadzor i upozorenja, a sada je, zapravo, pojava poruke u DLT temi razlog za analizu i otklanjanje kvara. Ovo je vrlo zgodno - po imenu teme odmah razumijemo u kojem koraku procesa je nastao problem, što značajno ubrzava potragu za njegovim korijenskim uzrokom.
Nedavno smo implementirali interfejs koji nam omogućava da ponovo šaljemo poruke koristeći našu podršku nakon eliminisanja njihovih uzroka (na primjer, vraćanje funkcionalnosti vanjskog sistema) i, naravno, utvrđivanje odgovarajućeg defekta za analizu. Ovdje dobro dolaze naše samostalne teme: kako ne biste ponovo pokrenuli dugi lanac obrade, možete ga ponovo pokrenuti od željenog koraka.
Operacija platforme
Platforma je već u produktivnom radu, svakodnevno vršimo isporuke i otpreme, povezujemo nove distributivne centre i prodavnice. Kao dio pilot-proizvoda, sistem radi sa grupama proizvoda “Duvan” i “Cipele”.
Cijeli naš tim sudjeluje u izvođenju pilota, analizira probleme koji se pojavljuju i daje prijedloge za poboljšanje našeg proizvoda, od poboljšanja dnevnika do promjene procesa.
Kako ne bismo ponavljali naše greške, svi slučajevi pronađeni tokom pilotiranja se odražavaju u automatiziranim testovima. Prisustvo velikog broja autotestova i jediničnih testova omogućava vam da izvršite regresijsko testiranje i instalirate hitnu ispravku doslovno u roku od nekoliko sati.
Sada nastavljamo da razvijamo i unapređujemo našu platformu i stalno se suočavamo sa novim izazovima. Ako ste zainteresirani, govorit ćemo o našim rješenjima u sljedećim člancima.
izvor: www.habr.com