Mula noong 2019, nagkaroon ng batas ang Russia sa mandatoryong pag-label. Ang batas ay hindi nalalapat sa lahat ng pangkat ng mga produkto, at ang mga petsa para sa pagpasok sa puwersa ng mandatoryong pag-label para sa mga pangkat ng produkto ay iba. Ang tabako, sapatos, at mga gamot ang unang sasailalim sa mandatoryong label; ang iba pang mga produkto ay idaragdag sa ibang pagkakataon, halimbawa, pabango, tela, at gatas. Ang legislative innovation na ito ay nag-udyok sa pagbuo ng mga bagong solusyon sa IT na gagawing posible na subaybayan ang buong chain ng buhay ng isang produkto mula sa produksyon hanggang sa pagbili ng end consumer, sa lahat ng kalahok sa proseso: ang estado mismo at lahat ng organisasyong nagbebenta ng mga kalakal gamit ang ipinag-uutos na pag-label.
Sa X5, ang system na susubaybay sa mga may label na produkto at makipagpalitan ng data sa estado at mga supplier ay tinatawag na "Marcus". Sabihin natin sa iyo sa pagkakasunud-sunod kung paano at sino ang bumuo nito, kung ano ang stack ng teknolohiya nito, at kung bakit mayroon tayong maipagmamalaki.
Tunay na HighLoad
Ang "Marcus" ay malulutas ang maraming mga problema, ang pangunahing isa ay ang integrasyon ng pakikipag-ugnayan sa pagitan ng mga sistema ng impormasyon ng X5 at ang sistema ng impormasyon ng estado para sa mga produktong may label (GIS MP) upang subaybayan ang paggalaw ng mga produktong may label. Iniimbak din ng platform ang lahat ng mga code sa pag-label na natanggap namin at ang buong kasaysayan ng paggalaw ng mga code na ito sa mga bagay, at tumutulong na alisin ang muling pag-grado ng mga produktong may label. Gamit ang halimbawa ng mga produktong tabako, na kasama sa mga unang grupo ng mga produktong may label, isang trak lamang ng sigarilyo ang naglalaman ng humigit-kumulang 600 pakete, na ang bawat isa ay may sariling natatanging code. At ang gawain ng aming system ay subaybayan at i-verify ang legalidad ng mga paggalaw ng bawat naturang pack sa pagitan ng mga bodega at tindahan, at sa huli ay i-verify ang pagiging matanggap ng kanilang pagbebenta sa huling mamimili. At nagre-record kami ng humigit-kumulang 000 cash na transaksyon kada oras, at kailangan din naming i-record kung paano nakapasok ang bawat naturang pack sa tindahan. Kaya, isinasaalang-alang ang lahat ng mga paggalaw sa pagitan ng mga bagay, inaasahan namin ang sampu-sampung bilyong mga talaan bawat taon.
Team M
Sa kabila ng katotohanan na si Marcus ay itinuturing na isang proyekto sa loob ng X5, ito ay ipinatupad gamit ang isang diskarte sa produkto. Ang koponan ay gumagana ayon sa Scrum. Nagsimula ang proyekto noong nakaraang tag-araw, ngunit ang mga unang resulta ay dumating lamang noong Oktubre - ang aming sariling koponan ay ganap na binuo, ang sistema ng arkitektura ay binuo at ang kagamitan ay binili. Ngayon ang koponan ay may 16 na tao, anim sa kanila ay kasangkot sa backend at frontend development, tatlo sa kanila ay kasangkot sa pagsusuri ng system. Anim pang tao ang kasangkot sa manual, load, automated testing, at product maintenance. Bilang karagdagan, mayroon kaming espesyalista sa SRE.
Hindi lang mga developer ang nagsusulat ng code sa aming team; halos lahat ng mga lalaki ay marunong mag-program at magsulat ng mga autotest, mag-load ng mga script at automation script. Nagbibigay kami ng espesyal na pansin dito, dahil kahit na ang suporta sa produkto ay nangangailangan ng mataas na antas ng automation. Palagi kaming nagsisikap na payuhan at tulungan ang mga kasamahan na hindi pa nakaprograma noon, at bigyan sila ng ilang maliliit na gawain upang gawin.
Dahil sa pandemya ng coronavirus, inilipat namin ang buong team sa malayong trabaho; ang pagkakaroon ng lahat ng tool para sa pamamahala ng pag-unlad, ang built workflow sa Jira at GitLab ay naging posible na madaling makapasa sa yugtong ito. Ang mga buwan na ginugol sa malayo ay nagpakita na ang pagiging produktibo ng koponan ay hindi nagdusa bilang isang resulta; para sa marami, ang ginhawa sa trabaho ay tumaas, ang tanging bagay na nawawala ay ang live na komunikasyon.
Remote na pagpupulong ng koponan
Mga pagpupulong sa panahon ng malayong trabaho
Technology stack ng solusyon
Ang karaniwang repositoryo at CI/CD tool para sa X5 ay GitLab. Ginagamit namin ito para sa pag-iimbak ng code, patuloy na pagsubok, at pag-deploy sa mga server ng pagsubok at produksyon. Ginagamit din namin ang kasanayan sa pagsusuri ng code, kapag kailangan ng hindi bababa sa 2 kasamahan na aprubahan ang mga pagbabagong ginawa ng developer sa code. Tinutulungan kami ng mga static na code analyzer na SonarQube at JaCoCo na panatilihing malinis ang aming code at tiyakin ang kinakailangang antas ng saklaw ng unit test. Ang lahat ng mga pagbabago sa code ay dapat dumaan sa mga pagsusuring ito. Ang lahat ng pansubok na script na pinapatakbo nang manu-mano ay pagkatapos ay awtomatiko.
Para sa matagumpay na pagpapatupad ng mga proseso ng negosyo ni "Marcus", kinailangan naming lutasin ang isang bilang ng mga teknolohikal na problema, tungkol sa bawat isa sa pagkakasunud-sunod.
Gawain 1. Ang pangangailangan para sa pahalang na scalability ng system
Upang malutas ang problemang ito, pumili kami ng isang microservice na diskarte sa arkitektura. Kasabay nito, napakahalagang maunawaan ang mga lugar ng responsibilidad ng mga serbisyo. Sinubukan naming hatiin ang mga ito sa mga operasyon ng negosyo, na isinasaalang-alang ang mga detalye ng mga proseso. Halimbawa, ang pagtanggap sa isang bodega ay hindi napakadalas, ngunit napakalaking operasyon, kung saan kinakailangan upang mabilis na makuha mula sa regulator ng estado ang impormasyon tungkol sa mga yunit ng mga kalakal na tinatanggap, ang bilang nito sa isang paghahatid ay umabot sa 600000 , suriin ang pagiging matanggap ng pagtanggap ng produktong ito sa bodega at ibalik ang lahat ng kinakailangang impormasyon para sa sistema ng automation ng warehouse. Ngunit ang pagpapadala mula sa mga bodega ay may mas mataas na intensity, ngunit sa parehong oras ay nagpapatakbo sa maliit na dami ng data.
Ipinapatupad namin ang lahat ng serbisyo sa walang estadong batayan at kahit na sinusubukan naming hatiin ang mga panloob na operasyon sa mga hakbang, gamit ang tinatawag naming mga paksa sa sarili ng Kafka. Ito ay kapag ang isang microservice ay nagpapadala ng mensahe sa sarili nito, na nagbibigay-daan sa iyong balansehin ang pag-load sa mas maraming resource-intensive na operasyon at pinapasimple ang pagpapanatili ng produkto, ngunit higit pa sa paglaon.
Nagpasya kaming paghiwalayin ang mga module para sa pakikipag-ugnayan sa mga panlabas na system sa magkakahiwalay na serbisyo. Ginawa nitong posible na malutas ang problema ng madalas na pagbabago ng mga API ng mga panlabas na system, na halos walang epekto sa mga serbisyong may functionality ng negosyo.
Ang lahat ng mga microservice ay naka-deploy sa isang OpenShift cluster, na malulutas ang parehong problema sa pag-scale ng bawat microservice at nagbibigay-daan sa amin na huwag gumamit ng mga tool sa Pagtuklas ng Serbisyo ng third-party.
Gawain 2. Ang pangangailangang magpanatili ng mataas na pagkarga at napakatindi ng pagpapalitan ng data sa pagitan ng mga serbisyo ng platform: Sa yugto ng paglulunsad ng proyekto lamang, humigit-kumulang 600 na operasyon bawat segundo ang ginagawa. Inaasahan naming tataas ang halagang ito sa 5000 ops/sec habang kumokonekta ang mga retail outlet sa aming platform.
Ang problemang ito ay nalutas sa pamamagitan ng pag-deploy ng isang Kafka cluster at halos ganap na pag-abandona sa magkakasabay na pakikipag-ugnayan sa pagitan ng mga microservice ng platform. Nangangailangan ito ng napakaingat na pagsusuri sa mga kinakailangan ng system, dahil hindi lahat ng operasyon ay maaaring maging asynchronous. Kasabay nito, hindi lamang namin ipinapadala ang mga kaganapan sa pamamagitan ng broker, ngunit ipinapadala din ang lahat ng kinakailangang impormasyon ng negosyo sa mensahe. Kaya, ang laki ng mensahe ay maaaring umabot ng ilang daang kilobytes. Ang limitasyon sa laki ng mensahe sa Kafka ay nangangailangan sa amin na tumpak na mahulaan ang laki ng mensahe, at kung kinakailangan, hinahati namin ang mga ito, ngunit ang dibisyon ay lohikal, na nauugnay sa mga pagpapatakbo ng negosyo.
Halimbawa, hinahati namin ang mga kalakal na dumarating sa isang kotse sa mga kahon. Para sa magkakasabay na operasyon, ang mga hiwalay na microservice ay inilalaan at ang masusing pagsusuri sa pagkarga ay isinasagawa. Ang paggamit ng Kafka ay nagbigay sa amin ng isa pang hamon - ang pagsubok sa pagpapatakbo ng aming serbisyo na isinasaalang-alang ang pagsasama ng Kafka ay ginagawang asynchronous ang lahat ng aming mga pagsubok sa unit. Nalutas namin ang problemang ito sa pamamagitan ng pagsulat ng aming sariling mga pamamaraan ng utility gamit ang Naka-embed na Kafka Broker. Hindi nito inaalis ang pangangailangang magsulat ng mga unit test para sa mga indibidwal na pamamaraan, ngunit mas gusto naming subukan ang mga kumplikadong kaso gamit ang Kafka.
Ang malaking pansin ay binayaran sa pagsubaybay sa mga log upang ang kanilang TraceId ay hindi mawala kapag may mga pagbubukod sa panahon ng pagpapatakbo ng mga serbisyo o kapag nagtatrabaho sa Kafka batch. At kung walang mga espesyal na isyu sa una, pagkatapos ay sa pangalawang kaso napipilitan kaming i-log ang lahat ng TraceId na kasama ng batch at pumili ng isa upang magpatuloy sa pagsubaybay. Pagkatapos, kapag naghahanap sa pamamagitan ng orihinal na TraceId, madaling malalaman ng user kung saan nagpatuloy ang pagsubaybay.
Gawain 3. Ang pangangailangang mag-imbak ng malaking halaga ng data: Mahigit sa 1 bilyong label bawat taon para sa tabako lamang ang dumating sa X5. Nangangailangan sila ng patuloy at mabilis na pag-access. Sa kabuuan, dapat iproseso ng system ang humigit-kumulang 10 bilyong talaan ng kasaysayan ng paggalaw ng mga may label na kalakal na ito.
Upang malutas ang pangatlong problema, napili ang database ng NoSQL na MongoDB. Nakagawa kami ng shard ng 5 node at bawat node ay may Replica Set ng 3 server. Binibigyang-daan ka nitong i-scale ang system nang pahalang, pagdaragdag ng mga bagong server sa cluster, at tiyakin ang fault tolerance nito. Dito ay nakatagpo kami ng isa pang problema - tinitiyak ang pagiging transaksyon sa kumpol ng mongo, na isinasaalang-alang ang paggamit ng mga pahalang na nasusukat na microservice. Halimbawa, ang isa sa mga gawain ng aming system ay tukuyin ang mga pagtatangka na muling magbenta ng mga produkto na may parehong mga code sa pag-label. Dito, lumalabas ang mga overlay na may mga maling pag-scan o maling operasyon ng mga cashier. Nalaman namin na ang mga naturang duplicate ay maaaring mangyari sa loob ng isang Kafka batch na pinoproseso, at sa loob ng dalawang batch na pinoproseso nang magkatulad. Kaya, ang pagsuri para sa mga duplicate sa pamamagitan ng pagtatanong sa database ay hindi nagbigay ng anuman. Para sa bawat microservice, nalutas namin ang problema nang hiwalay batay sa lohika ng negosyo ng serbisyong ito. Halimbawa, para sa mga tseke, nagdagdag kami ng tseke sa loob ng batch at hiwalay na pagproseso para sa paglitaw ng mga duplicate kapag naglalagay.
Upang matiyak na ang trabaho ng mga user sa kasaysayan ng mga operasyon ay hindi sa anumang paraan makakaapekto sa pinakamahalagang bagay - ang paggana ng aming mga proseso ng negosyo, pinaghiwalay namin ang lahat ng makasaysayang data sa isang hiwalay na serbisyo na may hiwalay na database, na tumatanggap din ng impormasyon sa pamamagitan ng Kafka . Sa ganitong paraan, gumagana ang mga user sa isang nakahiwalay na serbisyo nang hindi naaapektuhan ang mga serbisyong nagpoproseso ng data para sa mga kasalukuyang operasyon.
Gawain 4: Pagproseso at pagsubaybay ng queue:
Sa mga distributed system, ang mga problema at error ay hindi maiiwasang lumitaw sa pagkakaroon ng mga database, queues, at external na data source. Sa kaso ni Marcus, ang pinagmulan ng naturang mga pagkakamali ay ang pagsasama sa mga panlabas na sistema. Kinakailangang humanap ng solusyon na magpapahintulot sa mga paulit-ulit na kahilingan para sa mga maling tugon na may ilang tinukoy na timeout, ngunit sa parehong oras ay hindi huminto sa pagproseso ng mga matagumpay na kahilingan sa pangunahing pila. Para sa layuning ito, napili ang tinatawag na "topic based retry" na konsepto. Para sa bawat pangunahing paksa, isa o higit pang subukang muli ang mga paksa kung saan ipinapadala ang mga maling mensahe at kasabay nito ay inaalis ang pagkaantala sa pagproseso ng mga mensahe mula sa pangunahing paksa. scheme ng pakikipag-ugnayan -
Upang ipatupad ang gayong pamamaraan, kailangan namin ang sumusunod: upang isama ang solusyong ito sa Spring at maiwasan ang pagdoble ng code. Habang nagsu-surf sa web, nakatagpo kami ng katulad na solusyon batay sa Spring BeanPostProccessor, ngunit tila hindi kinakailangan na mahirap sa amin. Ang aming team ay gumawa ng isang mas simpleng solusyon na nagbibigay-daan sa amin na isama sa Spring cycle para sa paglikha ng mga consumer at bilang karagdagan, idagdag ang Retry Consumer. Nag-alok kami ng prototype ng aming solusyon sa Spring team, makikita mo ito . Ang bilang ng Retry Consumer at ang bilang ng mga pagsubok para sa bawat consumer ay na-configure sa pamamagitan ng mga parameter, depende sa mga pangangailangan ng proseso ng negosyo, at para gumana ang lahat, ang natitira na lang ay idagdag ang annotation org.springframework.kafka.annotation.KafkaListener , na pamilyar sa lahat ng developer ng Spring.
Kung hindi maproseso ang mensahe pagkatapos ng lahat ng muling pagsubok, mapupunta ito sa DLT (dead letter topic) gamit ang Spring DeadLetterPublishingRecoverer. Sa kahilingan ng suporta, pinalawak namin ang functionality na ito at lumikha ng isang hiwalay na serbisyo na nagbibigay-daan sa iyong tingnan ang mga mensaheng kasama sa DLT, stackTrace, traceId at iba pang kapaki-pakinabang na impormasyon tungkol sa mga ito. Bilang karagdagan, ang pagsubaybay at mga alerto ay idinagdag sa lahat ng mga paksa ng DLT, at ngayon, sa katunayan, ang paglitaw ng isang mensahe sa isang paksa ng DLT ay isang dahilan upang suriin at ayusin ang isang depekto. Ito ay napaka-maginhawa - sa pamamagitan ng pangalan ng paksa, agad naming nauunawaan kung anong hakbang ng proseso ang lumitaw ang problema, na makabuluhang nagpapabilis sa paghahanap para sa ugat na sanhi nito.
Kamakailan lamang, nagpatupad kami ng interface na nagbibigay-daan sa amin na magpadala muli ng mga mensahe gamit ang aming suporta pagkatapos na alisin ang mga sanhi ng mga ito (halimbawa, pagpapanumbalik ng functionality ng external system) at, siyempre, pagtatatag ng kaukulang depekto para sa pagsusuri. Dito nagagamit ang aming mga paksa sa sarili: upang hindi masimulan muli ang isang mahabang chain sa pagpoproseso, maaari mo itong i-restart mula sa nais na hakbang.
Pagpapatakbo ng Platform
Ang platform ay nasa produktibo nang operasyon, araw-araw ay nagsasagawa kami ng mga paghahatid at pagpapadala, nagkokonekta ng mga bagong sentro ng pamamahagi at mga tindahan. Bilang bahagi ng piloto, gumagana ang system sa mga pangkat ng produkto na "Tabako" at "Mga Sapatos".
Ang aming buong team ay nakikilahok sa pagsasagawa ng mga pilot, sinusuri ang mga umuusbong na problema at gumagawa ng mga mungkahi para sa pagpapabuti ng aming produkto, mula sa pagpapabuti ng mga log hanggang sa pagbabago ng mga proseso.
Upang hindi maulit ang aming mga pagkakamali, ang lahat ng mga kaso na natagpuan sa panahon ng pilot ay makikita sa mga awtomatikong pagsubok. Ang pagkakaroon ng malaking bilang ng mga autotest at unit test ay nagbibigay-daan sa iyong magsagawa ng regression testing at literal na mag-install ng hotfix sa loob ng ilang oras.
Ngayon ay patuloy kaming nagpapaunlad at nagpapahusay sa aming platform, at patuloy na humaharap sa mga bagong hamon. Kung interesado ka, pag-uusapan natin ang tungkol sa aming mga solusyon sa mga sumusunod na artikulo.
Pinagmulan: www.habr.com