«Walking in my shoes» — стоп, а те маркирани ли са?

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

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

Истински HighLoad

"Маркус" решава множество задачи, най-важната от които е интеграционното взаимодействие между информационните системи на Х5 и държавната информационна система за маркираната продукция (ГИС МП) за проследяване на движението на маркираната продукция. Платформата също така съхранява всички получени от нас кодове за маркировка и цялата история на движението на тези кодове по обекти, помага да се избегне попадането на неразпределени маркирани стоки. Например, в случая с тютюневите изделия, които влязоха в първите маркирани стоки, само един камион цигари съдържа около 600 000 кутии, всяка от които има свой уникален код. Задачата на нашата система е да проследи и провери легалността на движението на всяка такава кутийка между складовете и магазините и в крайна сметка да провери допустимостта на тяхната продажба на крайния купувач. Още повече, регистрираме около 125 000 касови операции на час, а също така трябва да регистрираме как всяка такава кутийка е попаднала в магазина. Учитывайки всички движение между обектите, очакваме десетки милиарди записи на година.

Екипът на М

Въпреки че "Маркус" се счита за проект в рамките на Х5, той се реализира по продуктовия подход. Екипът работи по Scrum. Стартирането на проекта беше през лятото на миналата година, но първите резултати пристигнаха едва през октомври - беше събраният екип, разработена архитектура на системата и закупено оборудване. В момента екипът се състои от 16 души, шест от които се занимават с разработка на backend и frontend, три с системен анализ. Още шест човека работят по ръчно, натоварващо и автоматизирано тестване и поддръжка на продукта. Освен това разполагаме с SRE специалист.

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

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

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

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

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

Стандартният репозиториум и инструмент за CI/CD за Х5 е GitLab. Ние го използваме за съхраняване на кода, непрекъснато тестване, разгръщане на тестови и продуктивни сървъри. Също така използваме практиката на code review, когато минимум 2 колеги трябва да одобрят промените в кода, направени от разработчика. Статичните анализатори на кода SonarQube и JaCoCo ни помагат да поддържаме кода чист и да осигурим необходимото ниво на покритие с unit тестове. Всички промени в кода задължително преминават през тези проверки. Всички тестови сценарии, които се изпълняват ръчно, впоследствие се автоматизират.

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

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

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

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

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

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

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

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

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

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

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

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

Задача 4. Повторна обработка на опашките и мониторинг:

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

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

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

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

Експлоатация на платформата

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

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

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

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

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