„Вървя в моите обувки“ – изчакайте, маркирани ли са?

От 2019 г. Русия има закон за задължително етикетиране. Законът не важи за всички групи стоки, а датите за влизане в сила на задължителното етикетиране за групите стоки са различни. Тютюнът, обувките и лекарствата ще бъдат първи обект на задължително етикетиране, други продукти ще бъдат добавени по-късно, например парфюми, текстил и мляко. Тази законодателна иновация подтикна разработването на нови ИТ решения, които ще направят възможно проследяването на цялата жизнена верига на продукта от производството до покупката от крайния потребител, до всички участници в процеса: както самата държава, така и всички организации, продаващи стоки с задължително етикетиране.

В X5 системата, която ще проследява етикетираните стоки и ще обменя данни с държавата и доставчиците, се нарича „Маркус“. Нека ви разкажем по ред как и кой го е разработил, какъв е неговият технологичен стек и защо имаме с какво да се гордеем.

Real HighLoad

„Маркус“ решава много проблеми, основният от които е интеграционното взаимодействие между информационните системи X5 и държавната информационна система за етикетирани продукти (GIS MP) за проследяване на движението на етикетирани продукти. Платформата също така съхранява всички кодове за етикетиране, получени от нас, и цялата история на движението на тези кодове в обектите и помага да се елиминира повторното класифициране на етикетираните продукти. На примера с тютюневите изделия, включени в първите групи етикетирани стоки, само един камион с цигари съдържа около 600 000 пакета, всеки от които има свой уникален код. А задачата на нашата система е да проследи и провери законността на движението на всяка такава опаковка между складове и магазини и в крайна сметка да провери допустимостта на продажбата им на крайния купувач. И ние записваме около 125 000 парични транзакции на час и също трябва да запишем как всяка такава опаковка е попаднала в магазина. Така, като вземем предвид всички движения между обекти, очакваме десетки милиарди записи годишно.

Екипът М

Въпреки факта, че Marcus се счита за проект в рамките на X5, той се изпълнява с помощта на продуктов подход. Екипът работи по Scrum. Проектът стартира миналото лято, но първите резултати дойдоха едва през октомври – собственият ни екип беше напълно сглобен, разработена беше системната архитектура и беше закупено оборудване. Сега екипът има 16 души, шестима от които участват в backend и frontend разработка, трима от които участват в системен анализ. Още шестима души участват в ръчно, товарно, автоматизирано тестване и поддръжка на продукта. Освен това имаме SRE специалист.

Не само разработчиците пишат код в нашия екип; почти всички момчета знаят как да програмират и пишат автотестове, зареждат скриптове и скриптове за автоматизация. Обръщаме специално внимание на това, тъй като дори продуктовата поддръжка изисква високо ниво на автоматизация. Винаги се опитваме да съветваме и помагаме на колеги, които не са програмирали преди, и да им даваме някои малки задачи, върху които да работят.

Поради пандемията от коронавирус прехвърлихме целия екип на дистанционна работа; наличието на всички инструменти за управление на разработката, изграденият работен процес в Jira и GitLab направиха възможно лесното преминаване на този етап. Месеците, прекарани дистанционно, показаха, че производителността на екипа не пострада в резултат на това, за мнозина комфортът на работа се увеличи, единственото, което липсваше, беше комуникацията на живо.

Дистанционна среща на екипа

Срещи по време на дистанционна работа

Технологичен стек на решението

Стандартното хранилище и CI/CD инструмент за X5 е GitLab. Използваме го за съхранение на код, непрекъснато тестване и внедряване на тестови и производствени сървъри. Използваме и практиката за преглед на кода, когато поне 2-ма колеги трябва да одобрят промените, направени от разработчика в кода. Анализаторите на статичен код SonarQube и JaCoCo ни помагат да поддържаме кода си чист и да гарантираме необходимото ниво на покритие на теста на единица. Всички промени в кода трябва да преминат през тези проверки. Всички тестови скриптове, които се изпълняват ръчно, впоследствие се автоматизират.

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

Задача 1. Необходимостта от хоризонтална мащабируемост на системата

За да разрешим този проблем, ние избрахме подход към архитектурата на микросервизи. В същото време беше много важно да се разберат областите на отговорност на службите. Опитахме се да ги разделим на бизнес операции, съобразявайки се със спецификата на процесите. Например приемането в склад не е много честа, но много мащабна операция, по време на която е необходимо бързо да се получи от държавния регулатор информация за единиците стоки, които се приемат, чийто брой в една доставка достига 600000 XNUMX , проверете допустимостта на приемането на този продукт в склада и върнете цялата необходима информация за системата за автоматизация на склада. Но пратката от складове има много по-голяма интензивност, но в същото време работи с малки обеми данни.

Ние внедряваме всички услуги на база без състояние и дори се опитваме да разделим вътрешните операции на стъпки, използвайки това, което наричаме Kafka self-thems. Това е моментът, когато микроуслугата изпраща съобщение до себе си, което ви позволява да балансирате натоварването при по-ресурсоемки операции и опростява поддръжката на продукта, но повече за това по-късно.

Решихме да отделим модулите за взаимодействие с външни системи в отделни услуги. Това направи възможно решаването на проблема с често променящите се API на външни системи, без практически никакво въздействие върху услугите с бизнес функционалност.

Всички микроуслуги са внедрени в клъстер OpenShift, което решава както проблема с мащабирането на всяка микроуслуга, така и ни позволява да не използваме инструменти за откриване на услуги на трети страни.

Задача 2. Необходимостта от поддържане на високо натоварване и много интензивен обмен на данни между услугите на платформата: Само по време на фазата на стартиране на проекта се извършват около 600 операции в секунда. Очакваме тази стойност да се увеличи до 5000 операции/сек, когато търговските обекти се свържат с нашата платформа.

Този проблем беше решен чрез внедряване на клъстер Kafka и почти пълно изоставяне на синхронното взаимодействие между микроуслугите на платформата. Това изисква много внимателен анализ на системните изисквания, тъй като не всички операции могат да бъдат асинхронни. В същото време ние не само предаваме събития чрез брокера, но и предаваме цялата необходима бизнес информация в съобщението. Така размерът на съобщението може да достигне няколкостотин килобайта. Ограничението за размера на съобщенията в Kafka изисква точно да предвидим размера на съобщенията и ако е необходимо, ги разделяме, но разделението е логично, свързано с бизнес операциите.
Например, ние разделяме стоките, които пристигат с кола, в кашони. За синхронни операции се разпределят отделни микроуслуги и се извършва задълбочено тестване на натоварването. Използването на Kafka ни изправи пред друго предизвикателство - тестването на работата на нашата услуга, като се вземе предвид интеграцията на Kafka, прави всички наши модулни тестове асинхронни. Решихме този проблем, като написахме наши собствени помощни методи, използвайки Embedded Kafka Broker. Това не премахва необходимостта от писане на модулни тестове за отделни методи, но ние предпочитаме да тестваме сложни случаи с помощта на Kafka.

Беше обърнато много внимание на проследяването на регистрационните файлове, така че техният TraceId да не бъде загубен, когато възникнат изключения по време на работа на услуги или при работа с Kafka batch. И ако не е имало особени проблеми с първия, тогава във втория случай сме принудени да регистрираме всички TraceIds, с които дойде партидата, и да изберем един, за да продължим проследяването. След това, когато търсите по оригиналния TraceId, потребителят лесно ще разбере с какво е продължило проследяването.

Задача 3. Необходимостта от съхраняване на голямо количество данни: Повече от 1 милиард етикета годишно само за тютюн идват в X5. Те изискват постоянен и бърз достъп. Общо системата трябва да обработи около 10 милиарда записа от историята на движението на тези етикетирани стоки.

За решаване на третия проблем беше избрана NoSQL базата данни MongoDB. Изградихме шард от 5 възела и всеки възел има комплект реплики от 3 сървъра. Това ви позволява да мащабирате системата хоризонтално, като добавяте нови сървъри към клъстера и гарантирате неговата устойчивост на грешки. Тук се сблъскахме с друг проблем - осигуряване на транзакционност в mongo клъстера, като се вземе предвид използването на хоризонтално мащабируеми микроуслуги. Например, една от задачите на нашата система е да идентифицира опити за препродажба на продукти със същите етикетиращи кодове. Тук се появяват наслагвания с грешни сканирания или грешни операции от касиери. Ние открихме, че такива дубликати могат да възникнат както в една партида на Kafka, която се обработва, така и в рамките на две партиди, които се обработват паралелно. По този начин проверката за дубликати чрез заявка в базата данни не даде нищо. За всяка микроуслуга решихме проблема отделно въз основа на бизнес логиката на тази услуга. Например за проверките добавихме проверка в партида и отделна обработка за появата на дубликати при вмъкване.

За да гарантираме, че работата на потребителите с историята на операциите по никакъв начин не засяга най-важното - функционирането на нашите бизнес процеси, ние отделихме всички исторически данни в отделна услуга с отделна база данни, която също получава информация чрез Kafka . По този начин потребителите работят с изолирана услуга, без да засягат услугите, които обработват данни за текущи операции.

Задача 4: Повторна обработка и наблюдение на опашка:

В разпределените системи неизбежно възникват проблеми и грешки при наличието на бази данни, опашки и външни източници на данни. В случая с Marcus източникът на такива грешки е интеграцията с външни системи. Беше необходимо да се намери решение, което да позволи повтарящи се заявки за грешни отговори с определено време за изчакване, но в същото време да не спира обработката на успешни заявки в главната опашка. За тази цел беше избрана така наречената концепция „повторен опит, базиран на тема“. За всяка основна тема се създават една или повече теми за повторен опит, към които се изпращат грешни съобщения и в същото време се елиминира забавянето при обработката на съобщения от основната тема. Схема на взаимодействие -

За да реализираме такава схема, ни трябваше следното: да интегрираме това решение с Spring и да избегнем дублиране на код. Докато сърфирахме в мрежата, попаднахме на подобно решение, базирано на Spring BeanPostProccessor, но ни се стори ненужно тромаво. Нашият екип направи по-просто решение, което ни позволява да се интегрираме в пролетния цикъл за създаване на потребители и допълнително да добавим потребители за повторен опит. Предложихме прототип на нашето решение на екипа на Spring, можете да го видите тук. Броят на Retry Consumers и броят опити за всеки потребител се конфигурират чрез параметри, в зависимост от нуждите на бизнес процеса и за да работи всичко, остава само да добавите анотацията org.springframework.kafka.annotation.KafkaListener , който е познат на всички разработчици на Spring.

Ако съобщението не може да бъде обработено след всички повторни опити, то отива към DLT (тема за мъртво писмо) с помощта на Spring DeadLetterPublishingRecoverer. По искане на поддръжката разширихме тази функционалност и създадохме отделна услуга, която ви позволява да преглеждате съобщения, включени в DLT, stackTrace, traceId и друга полезна информация за тях. В допълнение към всички DLT теми бяха добавени мониторинг и предупреждения и сега всъщност появата на съобщение в DLT тема е причина за анализ и коригиране на дефект. Това е много удобно - по името на темата веднага разбираме на коя стъпка от процеса е възникнал проблемът, което значително ускорява търсенето на неговата първопричина.

Съвсем наскоро внедрихме интерфейс, който ни позволява да изпращаме отново съобщения с помощта на нашата поддръжка, след като елиминираме причините за тях (например възстановяване на функционалността на външната система) и, разбира се, установим съответния дефект за анализ. Тук са полезни нашите теми за себе си: за да не рестартирате дълга верига за обработка, можете да я рестартирате от желаната стъпка.

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

Платформата вече работи продуктивно, всеки ден извършваме доставки и пратки, свързваме нови дистрибуторски центрове и магазини. Като част от пилота системата работи с продуктовите групи „Тютюн” и „Обувки”.

Целият ни екип участва в провеждането на пилотни проекти, анализира възникващи проблеми и прави предложения за подобряване на нашия продукт, от подобряване на регистрационните файлове до промяна на процесите.

За да не повтаряме нашите грешки, всички случаи, открити по време на пилотния тест, се отразяват в автоматизирани тестове. Наличието на голям брой автотестове и модулни тестове ви позволява да провеждате регресионно тестване и да инсталирате актуална корекция буквално в рамките на няколко часа.

Сега ние продължаваме да развиваме и подобряваме нашата платформа и постоянно се изправяме пред нови предизвикателства. Ако се интересувате, ще говорим за нашите решения в следващите статии.

Източник: www.habr.com