2019 жылдан бастап Ресейде міндетті таңбалау туралы заң бар. Заң барлық тауарлар топтарына қолданылмайды, ал өнім топтары үшін міндетті таңбалаудың күшіне ену мерзімдері әртүрлі. Темекі, аяқ киім және дәрі-дәрмек міндетті түрде таңбалануға тиіс бірінші болып, басқа өнімдер кейінірек қосылады, мысалы, парфюмерия, тоқыма және сүт. Бұл заңнамалық инновация өнімнің өндірістен бастап түпкілікті тұтынушы сатып алғанға дейінгі барлық өмірлік тізбегін процеске қатысушылардың барлығына: мемлекеттің өзі де, тауарларды сататын барлық ұйымдарға дейін қадағалауға мүмкіндік беретін жаңа АТ шешімдерін әзірлеуге түрткі болды. міндетті таңбалау.
X5 жүйесінде таңбаланған тауарларды қадағалайтын және мемлекетпен және жеткізушілермен деректер алмасатын жүйе «Маркус» деп аталады. Оны қалай және кім жасағанын, оның технологиялық стекі қандай екенін және бізде неге мақтанатын нәрсе бар екенін ретімен айтып берейік.
Нағыз жоғары жүктеме
«Маркус» көптеген мәселелерді шешеді, ең бастысы - таңбаланған өнімдердің қозғалысын бақылау үшін X5 ақпараттық жүйелері мен таңбаланған өнімдердің мемлекеттік ақпараттық жүйесі (GIS MP) арасындағы интеграциялық өзара әрекеттесу. Платформа сонымен қатар біз алған барлық таңбалау кодтарын және осы кодтардың нысандар бойынша қозғалысының бүкіл тарихын сақтайды және таңбаланған өнімдерді қайта бағалауды жоюға көмектеседі. Таңбаланған тауарлардың бірінші топтарына кіретін темекі өнімдерінің мысалын қолданатын болсақ, бір жүк көліктегі темекіде шамамен 600 000 қорап бар, олардың әрқайсысының өзіндік бірегей коды бар. Ал біздің жүйенің міндеті - әрбір осындай қаптаманың қоймалар мен дүкендер арасындағы қозғалысының заңдылығын қадағалау және тексеру және түпкілікті сатып алушыға оларды сатудың рұқсат етілгендігін тексеру. Біз сағатына шамамен 125 000 қолма-қол ақша транзакциясын жазамыз, сондай-ақ әрбір осындай пакеттің дүкенге қалай түскенін жазуымыз керек. Осылайша, объектілер арасындағы барлық қозғалыстарды ескере отырып, біз жылына ондаған миллиардтаған жазбаларды күтеміз.
М командасы
Маркус X5 аясындағы жоба болып саналғанына қарамастан, ол өнім тәсілін қолдану арқылы жүзеге асырылуда. Топ Scrum бойынша жұмыс істейді. Жоба өткен жазда басталды, бірақ алғашқы нәтижелер тек қазан айында келді – біздің жеке команда толығымен жиналды, жүйе архитектурасы әзірленді және жабдықтар сатып алынды. Қазір командада 16 адам бар, олардың алтауы бэкенд пен фронтендті әзірлеумен айналысады, оның үшеуі жүйелік талдаумен айналысады. Тағы алты адам қолмен, жүктемемен, автоматтандырылған сынаумен және өнімге техникалық қызмет көрсетумен айналысады. Сонымен қатар, бізде SRE маманы бар.
Біздің командада тек әзірлеушілер ғана емес код жазады; барлық жігіттер дерлік автотесттерді қалай бағдарламалауды және жазуды, сценарийлерді және автоматтандыру сценарийлерін жүктеуді біледі. Біз бұған ерекше назар аударамыз, өйткені тіпті өнімді қолдау автоматтандырудың жоғары деңгейін талап етеді. Біз әрқашан бұрын бағдарлама жасамаған әріптестерімізге кеңес беріп, көмектесуге тырысамыз және оларға жұмыс істеу үшін шағын тапсырмалар береміз.
Коронавирустық пандемияға байланысты біз бүкіл команданы қашықтан жұмыс істеуге ауыстырдық; әзірлеуді басқаруға арналған барлық құралдардың болуы, Jira және GitLab-те салынған жұмыс процесі бұл кезеңнен оңай өтуге мүмкіндік берді. Қашықтықта өткізілген айлар нәтижесінде команданың өнімділігі төмендемегенін көрсетті, көптеген адамдар үшін жұмыстағы жайлылық артты, жалғыз жетіспейтін нәрсе - тікелей байланыс болды.
Қашықтағы топ жиналысы
Қашықтықтан жұмыс кезінде кездесулер
Шешімнің технологиялық стекі
X5 үшін стандартты репозиторий және CI/CD құралы GitLab болып табылады. Біз оны кодты сақтау, үздіксіз тестілеу және сынақ және өндірістік серверлерді орналастыру үшін пайдаланамыз. Біз сондай-ақ кем дегенде 2 әріптес кодқа әзірлеуші енгізген өзгерістерді мақұлдау қажет болғанда кодты қарап шығу тәжірибесін қолданамыз. SonarQube және JaCoCo статикалық код анализаторлары кодымызды таза ұстауға және бірлік сынақ қамтуының қажетті деңгейін қамтамасыз етуге көмектеседі. Кодқа енгізілген барлық өзгерістер осы тексерулерден өтуі керек. Қолмен іске қосылатын барлық сынақ сценарийлері кейіннен автоматтандырылады.
«Маркус» бизнес-процестерін сәтті жүзеге асыру үшін бізге әрқайсысына қатысты бірқатар технологиялық мәселелерді шешуге тура келді.
Тапсырма 1. Жүйенің горизонтальды масштабталу қажеттілігі
Бұл мәселені шешу үшін архитектураға микросервис тәсілін таңдадық. Бұл ретте қызметтердің жауапкершілік салаларын түсіну өте маңызды болды. Біз процестердің ерекшеліктерін ескере отырып, оларды шаруашылық операцияларға бөлуге тырыстық. Мысалы, қоймаға қабылдау өте жиі емес, өте ауқымды операция болып табылады, оның барысында мемлекеттік реттеушіден қабылданатын тауар бірліктері туралы ақпаратты жылдам алу қажет, олардың саны бір жеткізілімде 600000 XNUMX-ға жетеді. , осы өнімді қоймаға қабылдаудың рұқсат етілгендігін тексеріңіз және қойманы автоматтандыру жүйесі үшін барлық қажетті ақпаратты қайтарыңыз. Бірақ қоймалардан жөнелту әлдеқайда үлкен қарқындылыққа ие, бірақ сонымен бірге деректердің шағын көлемімен жұмыс істейді.
Біз барлық қызметтерді азаматтығы жоқ негізде жүзеге асырамыз және тіпті Кафканың өзіндік тақырыптары деп атайтын нәрсені пайдалана отырып, ішкі операцияларды қадамдарға бөлуге тырысамыз. Бұл микросервис өзіне хабарлама жібереді, ол ресурсты көп қажет ететін операцияларға жүктемені теңестіруге мүмкіндік береді және өнімге техникалық қызмет көрсетуді жеңілдетеді, бірақ бұл туралы кейінірек.
Біз сыртқы жүйелермен өзара әрекеттесу үшін модульдерді бөлек қызметтерге бөлуді шештік. Бұл сыртқы жүйелердің API интерфейстерін жиі өзгерту мәселесін шешуге мүмкіндік берді, бұл бизнес функционалдығы бар қызметтерге іс жүзінде әсер етпейді.
Барлық микросервистер OpenShift кластерінде орналастырылған, бұл әрбір микросервисті масштабтау мәселесін де шешеді және үшінші тараптың Service Discovery құралдарын пайдаланбауға мүмкіндік береді.
Тапсырма 2. Платформа қызметтері арасында жоғары жүктеме мен өте қарқынды деректер алмасуды қолдау қажеттілігі: Жобаны іске қосу кезеңінде ғана секундына шамамен 600 операция орындалады. Біздің платформаға бөлшек сауда нүктелері қосылатындықтан, бұл мән 5000 опс/сек дейін артады деп күтеміз.
Бұл мәселе Кафка кластерін орналастыру және платформаның микросервистері арасындағы синхронды өзара әрекеттесуден толықтай дерлік бас тарту арқылы шешілді. Бұл жүйе талаптарын өте мұқият талдауды талап етеді, өйткені барлық операциялар асинхронды бола алмайды. Бұл ретте біз брокер арқылы оқиғаларды жіберіп қана қоймай, хабарламадағы барлық қажетті іскерлік ақпаратты жібереміз. Осылайша, хабарлама көлемі бірнеше жүз килобайтқа жетуі мүмкін. Кафкадағы хабар өлшемін шектеу бізден хабарлама өлшемін дәл болжауды талап етеді, қажет болса, біз оларды бөлеміз, бірақ бөлу логикалық, бизнес операцияларымен байланысты.
Мысалы, көлікпен келетін тауарларды жәшіктерге бөлеміз. Синхронды операциялар үшін бөлек микросервистер бөлінеді және мұқият жүктеме сынағы жүргізіледі. Кафканы пайдалану бізге тағы бір қиындықты тудырды - Кафка интеграциясын ескере отырып, қызметіміздің жұмысын тексеру біздің барлық бірлік сынақтарын асинхронды етеді. Біз бұл мәселені Embedded Kafka Broker көмегімен өзіміздің қызметтік әдістерімізді жазу арқылы шештік. Бұл жеке әдістер үшін бірлік сынақтарын жазу қажеттілігін жоймайды, бірақ біз Кафка арқылы күрделі жағдайларды тексеруді жөн көреміз.
Қызметтер жұмысы кезінде немесе Кафка бумасымен жұмыс істегенде ерекше жағдайлар орын алған кезде олардың TraceId жоғалмауы үшін журналдарды қадағалауға көп көңіл бөлінді. Ал егер біріншісінде ерекше мәселелер болмаса, екінші жағдайда біз пакетпен бірге келген барлық TraceId кодтарын тіркеуге және іздеуді жалғастыру үшін біреуін таңдауға мәжбүрміз. Содан кейін, түпнұсқа TraceId арқылы іздеу кезінде пайдаланушы бақылаудың немен жалғасатынын оңай табады.
Тапсырма 3. Мәліметтердің үлкен көлемін сақтау қажеттілігі: Тек темекіге арналған жыл сайын 1 миллиардтан астам жапсырма X5-ке келеді. Олар тұрақты және жылдам қол жеткізуді қажет етеді. Жалпы алғанда, жүйе осы таңбаланған тауарлардың қозғалыс тарихының шамамен 10 миллиард жазбасын өңдеуі керек.
Үшінші мәселені шешу үшін MongoDB NoSQL дерекқоры таңдалды. Біз 5 түйіннен тұратын үзінді жасадық және әрбір түйінде 3 серверден тұратын репликалар жинағы бар. Бұл жүйені көлденеңінен масштабтауға, кластерге жаңа серверлерді қосуға және оның ақауларға төзімділігін қамтамасыз етуге мүмкіндік береді. Бұл жерде біз тағы бір мәселеге тап болдық – көлденең масштабталатын микросервистерді пайдалануды ескере отырып, mongo кластерінде транзакциялық мүмкіндіктерді қамтамасыз ету. Мысалы, біздің жүйенің міндеттерінің бірі өнімдерді бірдей таңбалау кодтарымен қайта сату әрекеттерін анықтау болып табылады. Мұнда қате сканерлеумен немесе кассирлердің қате операцияларымен қабаттасмалар пайда болады. Біз мұндай көшірмелер Кафканың өңделетін бір бумасының ішінде де, параллель өңделетін екі топтаманың ішінде де болуы мүмкін екенін анықтадық. Осылайша, дерекқорды сұрау арқылы көшірмелерді тексеру ештеңе бермеді. Әрбір микросервис үшін біз мәселені осы қызметтің іскерлік логикасына негізделген бөлек шештік. Мысалы, чектер үшін біз пакеттің ішіндегі чекті және кірістіру кезінде көшірмелердің пайда болуы үшін бөлек өңдеуді қостық.
Пайдаланушылардың операциялар тарихымен жұмысы ең маңызды нәрсеге - біздің бизнес-процестердің жұмысына ешқандай әсер етпеуі үшін біз барлық тарихи деректерді Кафка арқылы ақпаратты алатын жеке дерекқоры бар бөлек қызметке бөлдік. . Осылайша, пайдаланушылар ағымдағы операциялар үшін деректерді өңдейтін қызметтерге әсер етпестен оқшауланған қызметпен жұмыс істейді.
4-тапсырма: Кезекті қайта өңдеу және бақылау:
Бөлінген жүйелерде дерекқорлардың, кезектердің және сыртқы деректер көздерінің қолжетімділігінде проблемалар мен қателер сөзсіз туындайды. Маркус жағдайында мұндай қателердің көзі сыртқы жүйелермен интеграция болып табылады. Белгілі бір күту уақыты бар қате жауаптар үшін қайталанатын сұрауларға мүмкіндік беретін, бірақ сонымен бірге негізгі кезекте сәтті сұрауларды өңдеуді тоқтатпайтын шешім табу қажет болды. Осы мақсатта «тақырыпқа негізделген қайталау» деп аталатын тұжырымдама таңдалды. Әрбір негізгі тақырып үшін қате хабарламалар жіберілетін бір немесе бірнеше қайталанатын тақырыптар жасалады және сонымен бірге негізгі тақырыптағы хабарламаларды өңдеудегі кідіріс жойылады. Өзара әрекеттесу схемасы -
Мұндай схеманы жүзеге асыру үшін бізге мыналар қажет болды: бұл шешімді Spring-пен біріктіру және кодтың қайталануын болдырмау. Интернетті шарлау кезінде біз Spring BeanPostProccessor негізіндегі ұқсас шешімге тап болдық, бірақ бұл бізге қажетсіз болып көрінді. Біздің команда тұтынушыларды құру үшін көктемгі циклге біріктіруге және тұтынушыларды қайталау мүмкіндігін қосымша қосуға мүмкіндік беретін қарапайымырақ шешім жасады. Біз көктем командасына шешіміміздің прототипін ұсындық, сіз оны көре аласыз . Қайталау тұтынушыларының саны және әрбір тұтынушыға арналған әрекеттер саны бизнес процесінің қажеттіліктеріне байланысты параметрлер арқылы конфигурацияланады және бәрі жұмыс істеуі үшін org.springframework.kafka.annotation.KafkaListener аннотациясын қосу ғана қалады. , бұл барлық Spring әзірлеушілеріне таныс.
Егер хабарды барлық қайталау әрекеттерінен кейін өңдеу мүмкін болмаса, ол Spring DeadLetterPublishingRecoverer көмегімен DLT (өлі әріп тақырыбы) өтеді. Қолдау сұрауы бойынша біз бұл функцияны кеңейттік және DLT, stackTrace, traceId және олар туралы басқа пайдалы ақпаратты қамтитын хабарларды көруге мүмкіндік беретін бөлек қызметті жасадық. Сонымен қатар, барлық DLT тақырыптарына мониторинг пен ескертулер қосылды және қазір, шын мәнінде, DLT тақырыбында хабарламаның пайда болуы ақауды талдауға және түзетуге негіз болып табылады. Бұл өте ыңғайлы - тақырыптың атауы бойынша біз мәселенің процестің қай сатысында пайда болғанын бірден түсінеміз, бұл оның негізгі себебін іздеуді айтарлықтай жылдамдатады.
Жақында біз олардың себептерін жойғаннан кейін (мысалы, сыртқы жүйенің функционалдығын қалпына келтіргеннен кейін) және, әрине, талдау үшін сәйкес ақауды орнатқаннан кейін, қолдауымызды пайдалана отырып, хабарламаларды қайта жіберуге мүмкіндік беретін интерфейсті енгіздік. Бұл жерде біздің жеке тақырыптарымыз пайдалы болады: ұзақ өңдеу тізбегін қайта іске қоспау үшін оны қажетті қадамнан қайта бастауға болады.
Платформаның жұмысы
Платформа қазірдің өзінде өнімді жұмыс істейді, біз күн сайын жеткізулер мен жөнелтілімдерді жүзеге асырамыз, жаңа тарату орталықтары мен дүкендерді қосамыз. Пилоттық жобаның бір бөлігі ретінде жүйе «Темекі» және «Аяқ киім» өнім топтарымен жұмыс істейді.
Біздің бүкіл командамыз пилоттарды жүргізуге қатысады, туындайтын мәселелерді талдайды және журналдарды жақсартудан бастап процестерді өзгертуге дейін өнімімізді жақсарту бойынша ұсыныстар жасайды.
Қателіктерімізді қайталамау үшін пилоттық сынақ кезінде табылған барлық жағдайлар автоматтандырылған сынақтарда көрсетіледі. Автотесттердің және бірлік сынақтарының көп санының болуы регрессиялық тестілеуді жүргізуге және түзетуді бірнеше сағат ішінде орнатуға мүмкіндік береді.
Енді біз платформамызды дамытып, жетілдіре береміз және үнемі жаңа міндеттерге тап боламыз. Егер сізді қызықтыратын болса, біз келесі мақалаларда шешімдеріміз туралы айтатын боламыз.
Ақпарат көзі: www.habr.com