Vuodesta 2019 lähtien Venäjällä on ollut laki pakollisista merkinnöistä. Laki ei koske kaikkia tavararyhmiä, ja tuoteryhmien pakollisten merkintöjen voimaantulopäivät ovat erilaisia. Tupakka, kengät ja lääkkeet tulevat ensimmäisenä pakollisiin merkintöihin, muut tuotteet lisätään myöhemmin, esimerkiksi hajuvedet, tekstiilit ja maito. Tämä lainsäädännöllinen innovaatio sai aikaan uusien IT-ratkaisujen kehittämisen, jotka mahdollistavat tuotteen koko elinkaaren seurannan tuotannosta loppukuluttajan ostoon, kaikkiin prosessiin osallistuviin: sekä valtioon itseensä että kaikkiin tavaroita myyviin organisaatioihin. pakollinen merkintä.
X5:ssä järjestelmää, joka seuraa merkittyjä tuotteita ja vaihtaa tietoja valtion ja toimittajien kanssa, kutsutaan nimellä "Marcus". Kerrotaan järjestyksessä kuinka ja kuka sen on kehittänyt, mikä sen teknologiapino on ja miksi meillä on syytä olla ylpeitä.
Todellinen HighLoad
”Marcus” ratkaisee monia ongelmia, joista tärkein on integraatiovuorovaikutus X5-tietojärjestelmien ja merkittyjen tuotteiden tilatietojärjestelmän (GIS MP) välillä merkittyjen tuotteiden liikkeiden seuraamiseksi. Alusta tallentaa myös kaikki saamamme merkintäkoodit ja koko historian näiden koodien liikkumisesta objektien välillä ja auttaa välttämään merkittyjen tuotteiden uudelleenluokittelun. Ensimmäisiin merkittyjen tavaroiden ryhmiin kuuluneiden tupakkatuotteiden esimerkin mukaisesti vain yksi rekkakuorma savukkeita sisältää noin 600 000 pakkausta, joista jokaisella on oma yksilöllinen koodinsa. Ja järjestelmämme tehtävänä on seurata ja varmistaa kunkin tällaisen pakkauksen varastojen ja myymälöiden välisten liikkeiden laillisuus ja viime kädessä varmistaa niiden myynnin hyväksyttävyys lopulliselle ostajalle. Ja tallennamme noin 125 000 käteistapahtumaa tunnissa, ja meidän on myös kirjattava, kuinka kukin tällainen pakkaus pääsi kauppaan. Näin ollen, kun otetaan huomioon kaikki objektien väliset liikkeet, odotamme kymmeniä miljardeja tietueita vuodessa.
Joukkue M
Huolimatta siitä, että Marcusta pidetään X5-projektina, sitä toteutetaan tuotelähestymistapaa käyttäen. Ryhmä toimii Scrumin mukaan. Projekti käynnistyi viime kesänä, mutta ensimmäiset tulokset tulivat vasta lokakuussa - oma tiimimme koottiin valmiiksi, järjestelmäarkkitehtuuria kehitettiin ja laitteet hankittiin. Nyt tiimissä on 16 henkilöä, joista kuusi on mukana tausta- ja frontend-kehityksessä, joista kolme on mukana järjestelmäanalyysissä. Kuusi muuta henkilöä osallistuu manuaaliseen, kuormitukseen, automaattiseen testaukseen ja tuotteiden ylläpitoon. Lisäksi meillä on SRE-asiantuntija.
Ei vain kehittäjät kirjoita koodia tiimissämme, melkein kaikki kaverit osaavat ohjelmoida ja kirjoittaa automaattisia testejä, ladata komentosarjoja ja automaatiokomentosarjoja. Kiinnitämme tähän erityistä huomiota, sillä myös tuotetuki vaatii korkeaa automaatiotasoa. Pyrimme aina neuvomaan ja auttamaan työtovereita, jotka eivät ole aiemmin ohjelmoineet, ja annamme heille pieniä tehtäviä.
Koronaviruspandemian vuoksi siirsimme koko tiimin etätöihin, kehityshallinnan kaikkien työkalujen saatavuus, Jiran ja GitLabin rakennettu työnkulku mahdollisti tämän vaiheen helpon läpimenon. Etäkäytössä vietetyt kuukaudet osoittivat, että joukkueen tuottavuus ei tästä kärsinyt, vaan monille työmukavuus lisääntyi, vain live-kommunikaatio puuttui.
Ryhmän etäkokous
Tapaamiset etätyön aikana
Ratkaisun teknologiapino
X5:n vakiovarasto ja CI/CD-työkalu on GitLab. Käytämme sitä koodin tallentamiseen, jatkuvaan testaukseen ja käyttöönottoon testi- ja tuotantopalvelimissa. Käytämme myös koodin tarkistuskäytäntöä, kun vähintään kahden kollegan on hyväksyttävä kehittäjän koodiin tekemät muutokset. Staattiset koodianalysaattorit SonarQube ja JaCoCo auttavat meitä pitämään koodimme puhtaana ja varmistamaan vaaditun yksikkötestin kattavuuden. Kaikki koodiin tehtävät muutokset on läpäistävä nämä tarkistukset. Kaikki manuaalisesti suoritettavat testiskriptit automatisoidaan myöhemmin.
Jotta "Marcus" voisi toteuttaa liiketoimintaprosessit onnistuneesti, meidän piti ratkaista useita teknisiä ongelmia, suunnilleen jokainen järjestyksessä.
Tehtävä 1. Järjestelmän horisontaalisen skaalautuvuuden tarve
Tämän ongelman ratkaisemiseksi valitsimme mikropalvelulähestymistavan arkkitehtuuriin. Samalla oli erittäin tärkeää ymmärtää palvelujen vastuualueet. Pyrimme jakamaan ne liiketoimintaan prosessien erityispiirteet huomioiden. Esimerkiksi varastoon vastaanotto ei ole kovin yleistä, mutta erittäin laajamittaista toimintaa, jonka aikana on tarpeen saada nopeasti valtion viranomaiselta tiedot vastaanotettavissa olevista tavarayksiköistä, joiden määrä yhdessä toimituksessa on 600000 XNUMX , tarkista tämän tuotteen hyväksyminen varastoon ja palauta kaikki tarvittavat tiedot varaston automaatiojärjestelmää varten. Mutta varastoista lähetys on paljon voimakkaampaa, mutta samalla se toimii pienillä tietomäärillä.
Toteutamme kaikki palvelut valtiottomalla pohjalla ja yritämme jopa jakaa sisäisen toiminnan vaiheisiin käyttämällä niin kutsuttuja Kafka-oma-aiheita. Tällöin mikropalvelu lähettää itselleen viestin, jonka avulla voit tasapainottaa resurssiintensiivisemmän toiminnan kuormitusta ja yksinkertaistaa tuotteen ylläpitoa, mutta siitä lisää myöhemmin.
Päätimme erottaa moduulit ulkoisten järjestelmien kanssa vuorovaikutusta varten erillisiksi palveluiksi. Tämä mahdollisti ulkoisten järjestelmien usein vaihtuvien sovellusliittymien ongelman ratkaisemisen ilman käytännössä mitään vaikutusta liiketoimintatoiminnallisilla palveluihin.
Kaikki mikropalvelut otetaan käyttöön OpenShift-klusterissa, mikä ratkaisee sekä kunkin mikropalvelun skaalausongelman että antaa meille mahdollisuuden olla käyttämättä kolmannen osapuolen Service Discovery -työkaluja.
Tehtävä 2. Tarve ylläpitää korkeaa kuormitusta ja erittäin intensiivistä tiedonvaihtoa alustapalvelujen välillä: Pelkästään projektin käynnistysvaiheessa tehdään noin 600 operaatiota sekunnissa. Odotamme tämän arvon nousevan 5000 XNUMX toimintoon sekunnissa, kun vähittäismyyntipisteet yhdistyvät alustaamme.
Tämä ongelma ratkaistiin ottamalla käyttöön Kafka-klusteri ja luopumalla lähes kokonaan alustan mikropalvelujen synkronisesta vuorovaikutuksesta. Tämä vaatii erittäin huolellista järjestelmävaatimusten analysointia, koska kaikki toiminnot eivät voi olla asynkronisia. Samalla emme vain välitä tapahtumia välittäjän kautta, vaan välitämme myös kaikki viestissä tarvittavat liiketoimintatiedot. Näin viestin koko voi olla useita satoja kilotavuja. Kafkan sanoman kokorajoitus edellyttää viestikoon tarkkaa ennustamista, ja tarvittaessa jaamme ne, mutta jako on looginen, liiketoimintaan liittyvä.
Jaamme esimerkiksi autossa saapuvat tavarat laatikoihin. Synkronisille toiminnoille allokoidaan erilliset mikropalvelut ja suoritetaan perusteellinen kuormitustestaus. Kafkan käyttö toi meille toisen haasteen - palvelumme toiminnan testaus Kafka-integraatio huomioon ottaen tekee kaikista yksikkötesteistämme asynkronisia. Ratkaisimme tämän ongelman kirjoittamalla omat apumenetelmämme käyttämällä Embedded Kafka Brokeria. Tämä ei poista tarvetta kirjoittaa yksikkötestejä yksittäisille menetelmille, mutta testaamme mieluummin monimutkaisia tapauksia Kafkan avulla.
Lokien jäljittämiseen kiinnitettiin paljon huomiota, jotta niiden TraceId ei katoaisi, kun palveluiden toiminnassa tai Kafka-erän kanssa työskennellessä tapahtuu poikkeuksia. Ja jos ensimmäisen kanssa ei ollut erityisiä ongelmia, niin toisessa tapauksessa meidän on kirjattava kaikki erän mukana tulleet TraceIds-tunnukset ja valitse niistä yksi jatkaaksesi jäljitystä. Sitten, kun käyttäjä etsii alkuperäisellä TraceId:llä, hän saa helposti selville, millä jäljitys jatkui.
Tehtävä 3. Tarve tallentaa suuri määrä tietoa: Yli miljardi tupakan etikettiä vuodessa tulee X1:lle. Ne vaativat jatkuvan ja nopean pääsyn. Yhteensä järjestelmän on käsiteltävä noin 5 miljardia tietuetta näiden merkittyjen tavaroiden liikehistoriasta.
Kolmannen ongelman ratkaisemiseksi valittiin NoSQL-tietokanta MongoDB. Olemme rakentaneet 5 solmun sirpaleen ja jokaisessa solmussa on 3 palvelimen replikasarja. Näin voit skaalata järjestelmää vaakasuunnassa, lisätä uusia palvelimia klusteriin ja varmistaa sen vikasietoisuuden. Tässä kohtasimme toisen ongelman - mongoklusterin transaktioiden varmistamisen, ottaen huomioon horisontaalisesti skaalautuvien mikropalvelujen käytön. Esimerkiksi yksi järjestelmämme tehtävistä on tunnistaa yritykset jälleenmyydä tuotteita samoilla merkintäkoodeilla. Tässä näkyy peittokuvia, joissa on virheellisiä skannauksia tai kassojen virheellisiä toimintoja. Havaitsimme, että tällaisia kaksoiskappaleita voi esiintyä sekä yhdessä käsiteltävässä Kafka-erässä että kahdessa rinnakkain käsitellyssä erässä. Näin ollen kaksoiskappaleiden tarkistaminen tietokannasta kyselyllä ei antanut mitään. Ratkaisimme kunkin mikropalvelun osalta ongelman erikseen tämän palvelun liiketoimintalogiikan perusteella. Esimerkiksi shekkeihin lisäsimme erän sisällä olevan tarkistuksen ja erillisen käsittelyn kaksoiskappaleiden näyttämiseksi lisäämisen yhteydessä.
Jotta käyttäjien työ toimintahistorian kanssa ei millään tavalla vaikuta tärkeimpään - liiketoimintaprosessiemme toimivuuteen, olemme erotelleet kaikki historiatiedot erilliseksi palveluksi, jossa on oma tietokanta, joka myös vastaanottaa tiedot Kafkan kautta. . Tällä tavalla käyttäjät työskentelevät erillisen palvelun kanssa vaikuttamatta palveluihin, jotka käsittelevät tietoja käynnissä olevaa toimintaa varten.
Tehtävä 4: Jonon uudelleenkäsittely ja valvonta:
Hajautetuissa järjestelmissä ongelmia ja virheitä syntyy väistämättä tietokantojen, jonojen ja ulkoisten tietolähteiden saatavuudessa. Marcuksen tapauksessa tällaisten virheiden lähde on integraatio ulkoisiin järjestelmiin. Oli tarpeen löytää ratkaisu, joka sallisi virheellisten vastausten toistuvat pyynnöt tietyllä aikakatkaisulla, mutta ei samalla lopettaisi onnistuneiden pyyntöjen käsittelyä pääjonossa. Tätä tarkoitusta varten valittiin niin sanottu "aihepohjainen uudelleenyritys" -konsepti. Jokaiselle pääaiheelle luodaan yksi tai useampi uudelleenyritysaihe, joihin lähetetään virheellisiä viestejä ja samalla eliminoidaan pääaiheen viestien käsittelyn viive. Vuorovaikutussuunnitelma -
Tällaisen järjestelmän toteuttamiseksi tarvitsimme seuraavan: integroida tämä ratkaisu Springiin ja välttää koodin päällekkäisyys. Netissä surffaillessamme törmäsimme samanlaiseen Spring BeanPostProccessoriin perustuvaan ratkaisuun, mutta se tuntui meistä tarpeettoman hankalalta. Tiimimme on tehnyt yksinkertaisemman ratkaisun, jonka avulla voimme integroitua kevätsykliin kuluttajien luomiseksi ja lisäksi lisätä Retry Consumers. Tarjosimme ratkaisumme prototyypin Spring-tiimille, näet sen . Uudelleenyrittävien kuluttajien määrä ja kunkin kuluttajan yritysten määrä määritetään parametrien avulla liiketoimintaprosessin tarpeiden mukaan, ja jotta kaikki toimisi, ei ole muuta kuin lisättävä huomautus org.springframework.kafka.annotation.KafkaListener. , joka on tuttu kaikille Spring-kehittäjille.
Jos viestiä ei voitu käsitellä kaikkien uudelleenyritysten jälkeen, se siirtyy DLT:hen (dead letter topic) Spring DeadLetterPublishingRecovererin avulla. Laajensimme tätä toimintoa tuen pyynnöstä ja loimme erillisen palvelun, jonka avulla voit tarkastella DLT-, stackTrace-, traceId- ja muita hyödyllisiä tietoja niistä. Lisäksi valvonta ja hälytykset lisättiin kaikkiin DLT-aiheisiin, ja nyt itse asiassa viestin ilmestyminen DLT-aiheeseen on syy analysoida ja korjata vika. Tämä on erittäin kätevää - aiheen nimen perusteella ymmärrämme heti, missä prosessin vaiheessa ongelma syntyi, mikä nopeuttaa merkittävästi sen perimmäisen syyn etsintää.
Viimeksi olemme ottaneet käyttöön käyttöliittymän, jonka avulla voimme lähettää viestejä uudelleen tukimme avulla sen jälkeen, kun niiden syyt on poistettu (esimerkiksi palautettu ulkoisen järjestelmän toimivuus) ja tietysti löydetty vastaava vika analysointia varten. Tässä oma-aiheemme ovat hyödyllisiä: jotta pitkä käsittelyketju ei käynnisty uudelleen, voit aloittaa sen uudelleen halutusta vaiheesta.
Alustan toiminta
Alusta on jo tuottavassa toiminnassa, joka päivä suoritamme toimituksia ja lähetyksiä, yhdistämme uusia jakelukeskuksia ja myymälöitä. Osana pilottia järjestelmä toimii tuoteryhmien ”Tupakka” ja ”Kengät” kanssa.
Koko tiimimme osallistuu pilottien tekemiseen, analysoi esiin nousevia ongelmia ja tekee ehdotuksia tuotteemme parantamiseksi lokien parantamisesta prosessien muutoksiin.
Jotta virheemme ei toistuisi, kaikki pilotin aikana löydetyt tapaukset näkyvät automaattisissa testeissä. Suuri määrä automaattisia ja yksikkötestejä mahdollistaa regressiotestauksen suorittamisen ja hotfix-korjauksen asentamisen kirjaimellisesti muutamassa tunnissa.
Nyt jatkamme alustamme kehittämistä ja parantamista ja kohtaamme jatkuvasti uusia haasteita. Jos olet kiinnostunut, kerromme ratkaisuistamme seuraavissa artikkeleissa.
Lähde: will.com