„Одење во моите чевли“ - чекајте, дали се обележани?

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

Во X5, системот што ќе ги следи означените стоки и ќе разменува податоци со државата и добавувачите се нарекува „Маркус“. Ајде да ви кажеме по ред како и кој го развил, каков е технолошкиот куп и зошто имаме со што да се гордееме.

Вистинско високо оптоварување

„Маркус“ решава многу проблеми, главниот е интеграциската интеракција помеѓу информациските системи X5 и државниот информациски систем за етикетирани производи (GIS MP) за следење на движењето на етикетирани производи. Платформата, исто така, ги складира сите кодови за етикетирање добиени од нас и целата историја на движење на овие шифри низ објекти и помага да се елиминира повторното оценување на етикетирани производи. Користејќи го примерот на тутунските производи, кои беа вклучени во првите групи на означени стоки, само еден камион цигари содржи околу 600 кутии, од кои секоја има свој единствен код. А задачата на нашиот систем е да ја следи и потврди законитоста на движењата на секое такво пакување помеѓу магацините и продавниците и на крајот да ја потврди прифатливоста на нивната продажба на крајниот купувач. И ние снимаме околу 000 готовински трансакции на час, а исто така треба да евидентираме како секој таков пакет влезе во продавницата. Така, земајќи ги предвид сите движења меѓу објектите, очекуваме десетици милијарди записи годишно.

Тимот М

И покрај фактот дека Marcus се смета за проект во рамките на X5, тој се спроведува со користење на пристап на производи. Тимот работи според Scrum. Проектот започна минатото лето, но првите резултати дојдоа дури во октомври - нашиот сопствен тим беше целосно составен, развиена е архитектурата на системот и набавена е опрема. Сега тимот има 16 луѓе, од кои шест се вклучени во развој на задни и преден дел, од кои тројца се вклучени во системска анализа. Уште шест луѓе се вклучени во рачно, оптоварување, автоматско тестирање и одржување на производот. Покрај тоа, имаме специјалист за SRE.

Не само програмерите пишуваат код во нашиот тим; речиси сите момци знаат како да програмираат и пишуваат автоматски тестови, да вчитуваат скрипти и скрипти за автоматизација. Посветуваме посебно внимание на ова, бидејќи дури и поддршката за производи бара високо ниво на автоматизација. Секогаш се трудиме да ги советуваме и помагаме колегите кои претходно не програмирале и им даваме некои мали задачи на кои треба да работат.

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

Состанок на далечина на тимот

Состаноци за време на работа на далечина

Технолошки оџак на решението

Стандардното складиште и алатката CI/CD за X5 е GitLab. Го користиме за складирање на кодови, континуирано тестирање и распоредување на сервери за тестирање и производство. Ја користиме и практиката на прегледување на кодот, кога најмалку 2 колеги треба да ги одобрат промените направени од развивачот во кодот. Анализаторите на статички кодови SonarQube и JaCoCo ни помагаат да го одржуваме нашиот код чист и да го обезбедиме потребното ниво на покриеност на тестот на единицата. Сите промени на кодот мора да поминат низ овие проверки. Сите тест скрипти кои се извршуваат рачно се автоматизираат последователно.

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

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

За да го решиме овој проблем, избравме микросервисен пристап кон архитектурата. Во исто време, беше многу важно да се разберат областите на одговорност на службите. Се обидовме да ги поделиме на деловно работење, земајќи ги предвид спецификите на процесите. На пример, прифаќањето во складиште не е многу честа, но многу голема операција, при што е неопходно брзо да се добијат од државниот регулатор информации за единиците на стоки што се прифаќаат, чиј број при една испорака достигнува 600000 , проверете ја прифатливоста за прифаќање на овој производ во магацинот и вратете ги сите потребни информации за системот за автоматизација на складиштето. Но, пратката од магацини има многу поголем интензитет, но во исто време работи со мал обем на податоци.

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

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

Сите микроуслуги се распоредени во кластер OpenShift, што го решава и проблемот со скалирање на секоја микросервис и ни овозможува да не користиме алатки за откривање услуги од трета страна.

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

Овој проблем беше решен со распоредување на кластерот Кафка и речиси целосно напуштање на синхроната интеракција помеѓу микросервисите на платформата. Ова бара многу внимателна анализа на системските барања, бидејќи не сите операции можат да бидат асинхрони. Во исто време, не само што пренесуваме настани преку брокерот, туку ги пренесуваме и сите потребни деловни информации во пораката. Така, големината на пораката може да достигне неколку стотици килобајти. Ограничувањето на големината на пораката во Кафка бара прецизно да ја предвидиме големината на пораката и доколку е потребно, ги делиме, но поделбата е логична, поврзана со деловните операции.
На пример, стоката што пристигнува во автомобил ја делиме во кутии. За синхрони операции, се доделуваат посебни микросервиси и се врши темелно тестирање на оптоварувањето. Користењето на Кафка ни постави уште еден предизвик - тестирањето на работата на нашата услуга земајќи ја предвид интеграцијата на Кафка ги прави сите наши тестови на единицата асинхрони. Го решивме овој проблем со пишување на нашите сопствени корисни методи со помош на Embedded Kafka Broker. Ова не ја елиминира потребата да се пишуваат единечни тестови за поединечни методи, но претпочитаме да тестираме сложени случаи користејќи Кафка.

Многу внимание беше посветено на логовите за следење за да не се изгуби нивниот TraceId кога ќе се појават исклучоци за време на работењето на услугите или кога се работи со серија на Кафка. И ако немаше посебни проблеми со првиот, тогаш во вториот случај ние сме принудени да ги евидентираме сите TraceIds со кои дојде серијата и да избереме еден за да продолжиме со следење. Потоа, при пребарување по оригиналниот TraceId, корисникот лесно ќе открие со кој следењето продолжило.

Задача 3. Потребата за складирање на голема количина на податоци: Повеќе од 1 милијарда етикети годишно само за тутун доаѓаат до X5. Тие бараат постојан и брз пристап. Севкупно, системот мора да обработи околу 10 милијарди записи од историјата на движење на овие етикетирани стоки.

За да се реши третиот проблем, беше избрана NoSQL базата на податоци MongoDB. Имаме изградено парче од 5 јазли и секој јазол има Replica сет од 3 сервери. Ова ви овозможува да го размерите системот хоризонтално, додавајќи нови сервери во кластерот и да ја обезбедите неговата толеранција на грешки. Овде наидовме на друг проблем - обезбедување трансакција во кластерот монго, земајќи ја предвид употребата на хоризонтално скалабилни микросервиси. На пример, една од задачите на нашиот систем е да ги идентификува обидите за препродажба на производи со исти шифри за етикетирање. Овде се појавуваат преклопувања со погрешни скенирања или погрешни операции од касиери. Откривме дека таквите дупликати може да се појават и во една серија на Кафка што се обработува и во две серии што се обработуваат паралелно. Така, проверката за дупликати со барање во базата на податоци не даде ништо. За секој микросервис го решивме проблемот посебно врз основа на деловната логика на оваа услуга. На пример, за проверки, додадовме проверка во серијата и посебна обработка за појавата на дупликати при вметнување.

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

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

Во дистрибуираните системи, неизбежно се појавуваат проблеми и грешки во достапноста на базите на податоци, редици и надворешни извори на податоци. Во случајот на Маркус, изворот на таквите грешки е интеграцијата со надворешни системи. Неопходно беше да се најде решение што ќе овозможи повторени барања за погрешни одговори со одредено одредено време на траење, но во исто време нема да престане да ги обработува успешните барања во главниот ред. За таа цел беше избран таканаречениот концепт „повторно обид заснован на тема“. За секоја главна тема се креираат една или повеќе теми за повторен обид на кои се испраќаат погрешни пораки и во исто време се елиминира доцнењето во обработката на пораките од главната тема. Шема за интеракција -

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

Ако пораката не може да се обработи по сите обиди за повторен обид, таа оди во DLT (тема на мртва буква) со помош на Spring DeadLetterPublishingRecoverer. На барање на поддршка, ја проширивме оваа функционалност и создадовме посебна услуга која ви овозможува да гледате пораки вклучени во DLT, stackTrace, traceId и други корисни информации за нив. Покрај тоа, мониторингот и предупредувањата беа додадени на сите DLT теми, а сега, всушност, појавата на порака во тема DLT е причина за анализа и поправка на дефект. Ова е многу погодно - по името на темата, веднаш разбираме во кој чекор од процесот настанал проблемот, што значително го забрзува пребарувањето за нејзината основна причина.

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

Работење на платформата

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

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

За да не ги повториме нашите грешки, сите случаи пронајдени за време на пилотот се рефлектираат во автоматизирани тестови. Присуството на голем број автоматски тестови и тестови за единици ви овозможува да спроведете тестирање за регресија и да инсталирате жешка поправка буквално во рок од неколку часа.

Сега продолжуваме да ја развиваме и подобруваме нашата платформа и постојано се соочуваме со нови предизвици. Доколку сте заинтересирани, ќе зборуваме за нашите решенија во следните статии.

Извор: www.habr.com