24/01/2020

Кейс kt.team: микросервисы, компьютерное зрение и машинное обучение в логистике

Сегодня мы расскажем об интересном сотрудничестве с крупным логистическим оператором.

Нам очень нравятся современные взгляды команды клиента: они давно «за» IT, автоматизацию и механизацию во всех своих рабочих процессах. Например, на складах они используют квадрокоптеры для инвентаризации верхних ярусов, беспилотные штабелёры — для перевозок в пределах склада, а интернет-заказы перемещают по «умной» конвейерной ленте с автовзвешиванием и сортировкой.

Мы гордимся тем, что наша команда добавила несколько полезных IT-продуктов в их портфель технологий. Среди наших решений — сервис валидации бумажных документов с компьютерным зрением, принт-сервис с интересной архитектурой и другие полезные продукты.

Сроки проекта

Мерчант — заказчик услуг логистической компании.

CV & ML — computer vision and machine learning, рус. компьютерное зрение и машинное обучение.

Октябрь 2018

На первом этапе в основном занимались интеграциями существующих WMS с информационными системами мерчантов.

Лето 2019

Начали разработку по продукту CV & ML для автоматизации электронного документооборота.

Сентябрь 2019

Запустили конвейер.

Сейчас

Дорабатываем продукт, в разработке которого используем компьютерное зрение и машинное обучение (нейросети), и занимаемся поддержкой внедрённых решений.

Команда

TDD — test-driven development, рус. разработка через тестирование.

Основной состав команды на этом проекте — четыре опытных backend-разработчика. Дополнительно подключались ещё три junior-разработчика, которые помогали с несложными задачами и занимались поддержкой.

За время проекта все в команде выросли по стеку и прокачали hard skills.

Например, ребята из основной четвёрки раньше не работали на Node.js, но в процессе изучили этот фреймворк — и сейчас все на нём пишут. Код писали по принципам TDD — прокачали и этот навык.

Чтобы узнать больше технических подробностей, мы взяли интервью у Антона — руководителя проекта.

Технические подробности проекта

— Антон, с какими запросами и проблемами к нам пришёл этот заказчик?

— Они хотели развить e-Commerce-направление для доставки заказов на сайтах крупных брендов. Для этого им не хватало гибкости: они использовали несколько довольно старых WMS, которые было сложно интегрировать с более современными информационными системами мерчантов. К тому же на одном и том же складе эти ИС могли стоять одновременно, распределение мерчантов по ним было довольно хаотичным. Всё взаимодействие выглядело как обмен Excel-файлами через FTP-сервер.

Т. к. все эти WMS до сих пор используются для управления складом, их было необходимо сохранить.

В этих условиях брендам-партнёрам пришлось бы платить крупные суммы за IT-интеграции с логистами, плюс проводить разработку потоков на своей стороне за собственный счёт, т. к. создание API для тех WMS было технически невозможно или заняло бы несколько лет.

Чтобы стать удобным и выгодным логистическим оператором для всех, нужно было либо предлагать интеграцию с API мерчантов, либо сделать свой универсальный API и предлагать интеграцию с ним. Так цена сделки будет гораздо ниже. Но это должен быть именно API, а не обмен файлами устаревших форматов.

— Как решили эти проблемы?

— Мы создали решение на базе Magento. Теперь все заказы, которые поступают от внешних брендов, собирает Magento. У многих мерчантов эта же CMS, и это дополнительное преимущество: в таком случае структура заказов и бизнес-логика их обработки ложится идеально.

LMS — last mile service, рус. сервис «последней мили».

У каждого заказчика логистических услуг есть свои особенности, каждому нужен индивидуальный подход, а решение на Magento достаточно гибкое, чтобы учесть и подстроиться под бизнес-процессы каждого из них.

Сейчас Magento интегрируется с мерчантами и получает от них первоначальный заказ на сборку. Затем данные передаются в WMS, где заказы видит и собирает оператор. После этого WMS отправляет статус заказа через Magento обратно мерчанту (если ему это нужно), и на финальных статусах он улетает в LMS (например DPD, Shiptor, «Почта России» или Lamoda). Далее подтягиваются дополнительные документы из LMS, ставятся необходимые наклейки (по умолчанию — собственная наклейка логистического оператора, но, например, DPD может потребовать наклеить свою наклейку, в таком случае её запрашивает Magento и печатает наш принт-сервис). Заказ отправляется по конвейеру на паллеты и ожидает службу доставки с соответствующими документами.

Чтобы процесс создания и контроля заявок стал проще и прозрачнее, мы создали B2B-портал, на котором операторы формируют заявки в электронном виде и отслеживают статус доставки онлайн.

— Какие ещё задачи стояли перед нашими разработчиками?

— Логистические операторы часто сталкиваются с проблемой, когда один и тот же документ нужно печатать одновременно на нескольких принтерах в разных местах склада. Проблему решили так: создали принт-сервис, который занимается маршрутизацией и доставкой данных до принтера. Кстати, у него очень интересное архитектурное решение: API на Python и сервер печати Linux CUPS для подключения принтеров.

Управление заказами было только первым шагом. Дальше нужно было автоматизировать финансовые расчёты. Сделать это не так просто: каждому заказу соответствует определённый набор услуг, и для каждого мерчанта он свой (ответственное хранение, доставка до LMS, ожидание на адресе и т. д.).

— Расскажи про сервис с CV & ML.

— Это сервис анализа и классификации бумажных документов, которыми наш заказчик обменивается с транспортными компаниями и клиентами.

Большой грузопоток генерирует большое количество первичных учётных документов, которые обрабатывает вручную целый отдел.

Чтобы облегчить работу сотрудников, мы используем специальный сервис для классификации и сверки документов с тем количеством, которое ожидает TMS.

TMS — transport management system, рус. система управления транспортом.

После запуска сервиса будет достаточно всего лишь загрузить в систему сканы документов для анализа — система распознаёт класс документов, проверяет комплектность и наличие обязательных атрибутов для конкретного контрагента (подписи, печати), сохраняет документы в базе данных и архиве.

Сейчас мы разрабатываем интерфейс, дорабатываем логику. Проект находится на стадии proof of concept.

— Какое участие команда принимала в автоматизации конвейера?

— Конвейер установили для улучшения процесса сборки, увеличения объёма и скорости обработки заказов. Он расположен внутри огромного склада, на каждом этаже которого находится свой набор мерчантов. Наверху операторы собирают все заказы и кладут их на конвейер, который идёт вниз. На первом этаже стоит платформа, которая взвешивает проезжающие коробки и отправляет эти данные в Magento, а Magento — через API в «Почту России» или в другие LMS, которым тоже нужны данные о весе. После получения ответа печатается наклейка в ту цель, куда по конвейеру приезжают посылки этой службы доставки.

Получается так: все заказы собираются и упаковываются на этажах нужным образом, после этого коробки съезжают вниз, там конвейер распределяет их по целям. На каждой цели собираются паллеты в соответствующую службу доставки («DPD-восток», «DPD-север», «Почта России» и т. д.).

Часть программного обеспечения, которое отвечает за эти процессы, поставлялась вместе с конвейером.

Наша система передаёт заказы сначала в WMS, а потом, после сборки, — в сортер; с сортера принимает данные о весе и габаритах грузов и отправляет их в LMS. Далее через принт-сервис печатается наклейка.

Также мы разработали интерфейс для мобильного сканера штрихкодов. Сканер представляет собой защищённый смартфон Honeywell на Android'е. Наш интерфейс позволяет легко управлять отгрузками — сканер считывает данные о собранных паллетах и, если они подходят по заданным критериям, формирует отгрузку. Для этой отгрузки приходят нужные первичные документы, и далее эти паллеты загружаются в машину.

— Что интересного можно сказать об архитектуре проекта и используемом стеке?

— Первоначально мы предлагали заказчику коробочную версию Magento с доработкой и написанием модулей.
В процессе мы пришли к другой концепции, которую и реализуем сейчас: пласты бизнес-логики выносим в отдельные сервисы, тем самым изолируем их друг от друга.

1

Тесты для независимого сервиса писать проще
Логика независимого сервиса изолирована, и поэтому требуется меньше работы для написания теста. На этом проекте используются функциональные, интеграционные, юнит-тесты. Некоторые сервисы делаем через TDD.
2

Сервис с нуля
Когда пишешь новый сервис с нуля, проще внедрять лучшие практики, контролировать процесс и поддерживать высокое качество. За счёт изоляции уменьшилась регрессия.
3

Изоляция логики
В изолированный кусок логики проще вникнуть, ничего не нужно искать в монолите. Сервис со всей своей логикой интегрируется с остальными частями системы через API, который «выставлен» наружу, поэтому с ним удобно работать.
4

Независимые релизы
За счёт разделения логики мы сможем подготавливать независимые релизы. При реализации софта для конвейера мы столкнулись со сложностью: выпускать релиз Magento в произвольное, удобное нам время невозможно. С подключением конвейера заказ уже через 10 минут оказывается на ленте, и если за это время от системы не пришло оповещение (например система недоступна из-за релиза), заказ уходит в ошибку. Таргет с ошибками переполняется большим количеством коробок, и это стопорит работу всего склада. Чтобы решить возникшую проблему, прежде всего мы зафиксировали строго определённое время для релизов.

В ближайшее время планируем создать отдельный сервис, который будет моментально принимать сообщения от WMS на конвейер и параллельно отправлять их на обработку на Magento. Это позволит нам осуществлять релиз, не прерывая отправку информации о заказах в сортер.

О стеке

Когда мы пришли к микросервисной архитектуре, часть сервисов стали писать на Node.js. Это удобно из-за его асинхронности, и на нём очень легко реализовывать различные виды API. Также использовали PHP (Magento 2.3, Slim для микросервисов), RabbitMQ в качестве брокера очередей. Python задействовали в разработке принт-сервиса и сервиса валидации печатей.

Все технологии kt.team

Благодарим за интервью нашего эксперта Антона и желаем команде успешного завершения разработки.

Читай также

Как стать разработчиком, если нет профильного образования?

Тебе наверняка не раз говорили: «Профессия — это на всю жизнь! Выбирай с умом, чтобы потом не разочароваться». Да, раньше это было правдой.

Что выбрать разработчику: фриланс или работу в офисе?

Где разработчику выгоднее и удобнее развивать свою карьеру: на фрилансе или в офисе? Рассматриваем опыт фриланса и работу в kt.team.

Data-driven design и UX-аналитика в дизайне интернет-магазина (часть 1)

Почему мы используем маркетинговый подход в web-дизайне (data-driven design) и как UX-исследования от Baymard помогают нам улучшать юзабилити интернет-магазинов.

Шейминг, предрассудки и стереотипы: как на самом деле живётся девушкам в IT?

Скандал на «Стачке» и удаление сексистского спикера. А что на самом деле происходит с женщинами в IT? Наш опыт.

Офис для программистов: требования, примеры, опыт kt.team

Примеры дизайна и организации пространства в офисах IT-компаний. Что и зачем нужно программистам в офисе? Сравнение мировой практики и опыта kt.team.

Подписывайся на наши социальные сети
и telegram-канал вакансий