„Ходам у ципелама“ - чекајте, јесу ли означене?

Од 2019. године Русија има закон о обавезном обележавању. Закон се не примењује на све групе роба, а датуми ступања на снагу обавезног обележавања за групе производа су различити. Дуван, обућа и лекови први ће бити подвргнути обавезном обележавању, а други производи ће бити додати касније, на пример, парфеми, текстил и млеко. Ова законска иновација подстакла је развој нових ИТ решења која ће омогућити да се прати цео животни ланац производа од производње до куповине од стране крајњег потрошача, до свих учесника у процесу: како саме државе, тако и свих организација које продају робу. обавезно обележавање.

У Кс5 систем који ће пратити означену робу и размењивати податке са државом и добављачима назива се „Марцус”. Хајде да вам кажемо редом како и ко га је развио, који је његов технолошки скуп и зашто имамо чиме да се поносимо.

Реал ХигхЛоад

„Марцус” решава многе проблеме, а главни је интеграцијска интеракција између Кс5 информационих система и државног информационог система за означене производе (ГИС МП) за праћење кретања означених производа. Платформа такође чува све кодове за означавање које смо примили и целокупну историју кретања ових кодова по објектима и помаже у елиминисању поновног оцењивања означених производа. На примеру дуванских производа, који су били уврштени у прве групе означене робе, само један камион цигарета садржи око 600 паклица, од којих свака има своју јединствену шифру. А задатак нашег система је да прати и проверава законитост кретања сваког таквог паковања између магацина и продавница и на крају провери прихватљивост њихове продаје крајњем купцу. И бележимо око 000 готовинских трансакција на сат, а такође треба да евидентирамо како је сваки такав пакет ушао у продавницу. Дакле, узимајући у обзир сва кретања између објеката, очекујемо десетине милијарди записа годишње.

Тим М

Упркос чињеници да се Марцус сматра пројектом у оквиру Кс5, он се имплементира користећи производни приступ. Тим ради по Сцрум-у. Пројекат је започет прошлог лета, али су први резултати дошли тек у октобру – комплетно је окупљен сопствени тим, развијена архитектура система и набављена опрема. Сада тим има 16 људи, од којих је шест укључено у бацкенд и фронтенд развој, од којих су три укључена у анализу система. Још шест људи је укључено у ручно тестирање, учитавање, аутоматизовано тестирање и одржавање производа. Поред тога, имамо специјалисте за СРЕ.

Не само да програмери пишу код у нашем тиму; скоро сви момци знају како да програмирају и пишу аутотестове, учитавају скрипте и скрипте за аутоматизацију. Овоме посвећујемо посебну пажњу, јер чак и подршка производа захтева висок ниво аутоматизације. Увек се трудимо да саветујемо и помогнемо колегама који до сада нису програмирали и дамо им неке мале задатке на којима треба да раде.

Због пандемије корона вируса, пребацили смо цео тим на даљински рад; доступност свих алата за управљање развојем, уграђени радни ток у Јира и ГитЛаб-у омогућили су да се ова фаза лако прође. Месеци проведени на даљину показали су да продуктивност тима није пала због тога; за многе се повећала удобност на послу, једино што је недостајало била је жива комуникација.

Састанак тима на даљину

Састанци током рада на даљину

Технолошки скуп решења

Стандардно спремиште и ЦИ/ЦД алат за Кс5 је ГитЛаб. Користимо га за складиштење кода, континуирано тестирање и примену на серверима за тестирање и производњу. Такође користимо праксу прегледа кода, када најмање 2 колеге треба да одобре промене које је програмер направио у коду. Статички анализатори кода СонарКубе и ЈаЦоЦо нам помажу да наш код буде чист и обезбеђује потребан ниво покривености тестом јединица. Све промене кода морају проћи кроз ове провере. Све тестне скрипте које се покрећу ручно су накнадно аутоматизоване.

За успешну имплементацију пословних процеса од стране „Марцуса“ морали смо да решимо низ технолошких проблема, сваки по реду.

Задатак 1. Потреба хоризонталне скалабилности система

Да бисмо решили овај проблем, изабрали смо микросервисни приступ архитектури. Истовремено, било је веома важно разумети области одговорности служби. Покушали смо да их поделимо на пословне операције, узимајући у обзир специфичности процеса. На пример, пријем у складиште није веома честа, али веома обимна операција, током које је потребно брзо добити од државног регулатора информације о јединицама робе које се прихватају, чији број у једној испоруци достиже 600000 , проверите прихватљивост пријема овог производа у складиште и вратите све потребне информације за систем аутоматизације складишта. Али пошиљка из складишта има много већи интензитет, али у исто време ради са малим количинама података.

Све услуге имплементирамо на бази без држављанства и чак покушавамо да поделимо унутрашње операције на кораке, користећи оно што називамо Кафкиним самотемама. Ово је када микросервис шаље поруку себи, што вам омогућава да уравнотежите оптерећење на операцијама које захтевају више ресурса и поједностављује одржавање производа, али о томе касније.

Одлучили смо да раздвојимо модуле за интеракцију са екстерним системима у засебне сервисе. Ово је омогућило да се реши проблем често мењања АПИ-ја екстерних система, практично без утицаја на сервисе са пословном функционалношћу.

Све микросервисе су распоређене у ОпенСхифт кластеру, што решава и проблем скалирања сваке микросервисе и омогућава нам да не користимо алате за откривање услуга треће стране.

Задатак 2. Потреба за одржавањем високог оптерећења и веома интензивне размене података између сервиса платформе: Само током фазе покретања пројекта, изврши се око 600 операција у секунди. Очекујемо да ће се ова вредност повећати на 5000 операција у секунди како се малопродајна места повезују са нашом платформом.

Овај проблем је решен применом Кафка кластера и скоро потпуно напуштањем синхроне интеракције између микросервиса платформе. Ово захтева веома пажљиву анализу системских захтева, пошто не могу све операције бити асинхроне. Истовремено, не само да преносимо догађаје преко брокера, већ и све потребне пословне информације у поруци. Дакле, величина поруке може достићи неколико стотина килобајта. Ограничење величине поруке у Кафки захтева од нас да тачно предвидимо величину поруке, а по потреби их поделимо, али је подела логична, везана за пословање.
На пример, робу која стиже аутомобилом делимо у кутије. За синхроне операције, додељују се одвојени микросервис и врши се темељно тестирање оптерећења. Коришћење Кафке представљало нам је још један изазов - тестирање рада нашег сервиса узимајући у обзир Кафка интеграцију чини све наше тестове јединица асинхроним. Решили смо овај проблем писањем сопствених услужних метода користећи Ембеддед Кафка Брокер. Ово не елиминише потребу за писањем јединичних тестова за појединачне методе, али ми више волимо да тестирамо сложене случајеве користећи Кафку.

Много пажње је посвећено праћењу дневника како се њихов ТрацеИд не би изгубио када се појаве изузеци током рада сервиса или када се ради са Кафка пакетом. А ако није било посебних проблема са првим, онда смо у другом случају приморани да евидентирамо све ТрацеИд-ове са којима је пакет дошао и да изаберемо један да бисмо наставили праћење. Затим, приликом претраге по оригиналном ТрацеИд-у, корисник ће лако сазнати којим је праћењем настављено.

Задатак 3. Потреба за складиштењем велике количине података: Више од милијарду етикета годишње само за дуван долази на Кс1. Захтевају сталан и брз приступ. Укупно, систем мора да обради око 5 милијарди записа о историји кретања ове означене робе.

За решавање трећег проблема изабрана је НоСКЛ база података МонгоДБ. Направили смо део од 5 чворова и сваки чвор има скуп реплика од 3 сервера. Ово вам омогућава да хоризонтално скалирате систем, додајући нове сервере у кластер и обезбедите његову толеранцију грешака. Овде смо наишли на још један проблем – обезбеђивање трансакција у монго кластеру, узимајући у обзир коришћење хоризонтално скалабилних микросервиса. На пример, један од задатака нашег система је да идентификује покушаје препродаје производа са истим кодовима за означавање. Овде се појављују преклопи са погрешним скенирањима или погрешним операцијама благајника. Открили смо да се такви дупликати могу појавити како у оквиру једне Кафка серије која се обрађује, тако и у оквиру две серије које се обрађују паралелно. Дакле, провера дупликата испитивањем базе података није дала ништа. За сваки микросервис проблем смо решавали посебно на основу пословне логике овог сервиса. На пример, за чекове смо додали чек унутар серије и одвојену обраду за појаву дупликата приликом уметања.

Како бисмо осигурали да рад корисника са историјом пословања ни на који начин не утиче на најважнију ствар – функционисање наших пословних процеса, све историјске податке смо издвојили у посебан сервис са посебном базом података, који такође прима информације преко Кафке. . На овај начин корисници раде са изолованом услугом без утицаја на услуге које обрађују податке за текуће операције.

Задатак 4: Поновна обрада и надзор у реду чекања:

У дистрибуираним системима, проблеми и грешке се неизбежно јављају у доступности база података, редова чекања и екстерних извора података. У случају Маркуса, извор таквих грешака је интеграција са спољним системима. Било је неопходно пронаћи решење које би омогућило поновљене захтеве за погрешне одговоре са одређеним временским ограничењем, али у исто време не зауставило обраду успешних захтева у главном реду. У ту сврху изабран је такозвани концепт поновног покушаја заснованог на теми. За сваку главну тему креира се једна или више тема за поновни покушај на које се шаљу погрешне поруке и истовремено се елиминише кашњење у обради порука из главне теме. Шема интеракције -

Да бисмо имплементирали такву шему, било нам је потребно следеће: да интегришемо ово решење са Спринг-ом и избегнемо дуплирање кода. Док смо сурфовали вебом, наишли смо на слично решење засновано на Спринг БеанПостПроццессор-у, али нам се чинило непотребно гломазним. Наш тим је направио једноставније решење које нам омогућава да се интегришемо у Спринг циклус за креирање потрошача и додатно додамо Ретри Цонсумерс. Понудили смо прототип нашег решења Спринг тиму, можете га видети овде. Број Ретри Цонсумерс и број покушаја за сваког потрошача се конфигуришу кроз параметре, у зависности од потреба пословног процеса, а да би све функционисало, остаје само да се дода напомена орг.спрингфрамеворк.кафка.аннотатион.КафкаЛистенер , који је познат свим Спринг програмерима.

Ако порука није могла да се обради након свих покушаја поновног покушаја, она иде у ДЛТ (тема мртвог писма) користећи Спринг ДеадЛеттерПублисхингРецоверер. На захтев подршке, проширили смо ову функционалност и креирали посебну услугу која вам омогућава да видите поруке укључене у ДЛТ, стацкТраце, трацеИд и друге корисне информације о њима. Поред тога, свим ДЛТ темама је додат надзор и упозорења и сада је, заправо, појава поруке у ДЛТ теми разлог за анализу и отклањање квара. Ово је веома згодно - по имену теме одмах разумемо у ком кораку процеса је настао проблем, што значајно убрзава потрагу за његовим основним узроком.

Недавно смо имплементирали интерфејс који нам омогућава да поново шаљемо поруке користећи нашу подршку након што елиминишемо њихове узроке (на пример, враћамо функционалност спољног система) и, наравно, утврдимо одговарајући недостатак за анализу. Овде наше самосталне теме добро долазе: да не бисте поново покренули дуг ланац обраде, можете га поново покренути од жељеног корака.

Операција платформе

Платформа је већ у продуктивном раду, свакодневно вршимо испоруке и отпреме, повезујемо нове дистрибутивне центре и продавнице. Као део пилот-производа, систем ради са групама производа „Дуван“ и „Ципеле“.

Цео наш тим учествује у спровођењу пилота, анализира нове проблеме и даје предлоге за побољшање нашег производа, од побољшања евиденције до промене процеса.

Да не бисмо поновили наше грешке, сви случајеви пронађени током пилотирања се одражавају у аутоматизованим тестовима. Присуство великог броја аутотестова и јединичних тестова омогућава вам да спроведете регресијско тестирање и инсталирате хитну исправку буквално у року од неколико сати.

Сада настављамо да развијамо и унапређујемо нашу платформу и стално се суочавамо са новим изазовима. Ако сте заинтересовани, говорићемо о нашим решењима у следећим чланцима.

Извор: ввв.хабр.цом