Привет! Меня зовут Евгений Рябышев, я разработчик в одной из команд направления Warehouse Management System (WMS) компании Lamoda. Я занимаюсь тем, что автоматизирую склад. В этой статье расскажу, как мы строим нашу модульную архитектуру.
Наши основные бизнес-процессы для управления складом долго выстраивались и доказали свою эффективность. В то же время они сильно связаны между собой. Склад — это большой монолит, который не получится безболезненно разделить на части. Но решение нашлось: мы строим модульную архитектуру без использования микросервисов.
Складские бизнес-процессы: от поступления товара до отправки заказчику
В настоящий момент WMS — это монолитная архитектура, которая поставляется единым .ear-файлом и разворачивается в контейнеры приложения в Wildfly. Она позволяет управлять тремя основными бизнес-процессами на складе.
Inbound отвечает за входящий поток товаров, партнерских или наших собственных, которые мы покупаем для реализации через сайт или мобильное приложение. Внутри есть бизнес-процессы, связанные с товарами: Rejects и Claims (возвраты и претензии, соответственно). Если одежда или обувь не подошла покупателю, мы возвращаем эти вещи и кладем обратно на склад.
Тут же находится бизнес-процесс CIC (Central Inbound Clearing). Он позволяет сотрудникам склада решать проблемы во время приемки товаров. Например, на товаре нет наклейки, и они перепечатывают ее, или товар не соотносится с картинкой, к которой он привязан.
Outbound — исходящий поток товаров. Когда пользователь делает заказ в Lamoda, все начинается с Order Management. Это подпроцесс, который отвечает за старт сборки заказов.
После того как работники склада собрали товары в заказ, начинается упаковка. Мы используем три способа:
- Полуавтоматическая упаковка Item Sorter.
- Ручная упаковка через minibatch. Это рабочее место с компьютером и столом, где находится упаковочный материал.
- Автоматическая упаковка через АВМ (Auto Bagging Machine или автоматическую упаковочную машину).
После этого мы размещаем товары на паллеты. Начинается подпроцесс Palletising: заказы отправляются к месту назначения. Тут же есть подпроцесс СОС (Central Outbound Clearing). Он используется для аналогичных целей, что и Central Inbound Clearing, но только на этапе отгрузки.
Stock — последний основной бизнес-процесс.
В нем есть три подпроцесса.
- Putaway занимается размещением товаров на складе.
- Picking отвечает за сборку товаров для заказа и для внутреннего аудита. Например, когда менеджеры хотят проверить срок годности косметики.
- Inventory (инвентаризация). Он нужен, чтобы проводить частичную или полную инвентаризацию на складе.
Архитектура WMS: из чего она состоит
Первый компонент — Printing service, который отвечает за распечатывание этикеток. Они расклеиваются везде: на паллеты, товары, контейнеры, рабочие станции — в общем, на все сущности, которыми управляет WMS. Следовательно, этикетка позволяет сотруднику склада понять, с чем сейчас он имеет дело.
Мониторинг — это основной сервис для операционных менеджеров, поскольку там отражается состояние склада в реальном времени. Сотрудник склада всегда может понять, что делать во время пиковой нагрузки. Например, перекинуть группу людей, которые разгрузят или отнесут товар. Мониторинг помогает складу работать намного эффективнее.
Следующий компонент — это фронтенд-клиент. Его можно разделить на два подтипа: клиент для рабочих станций, где происходит упаковка, и клиент для десктоп, написанный на Angular. Последний нужен, чтобы пользователи общались с нашей WMS.
Еще есть мобильный клиент. Подробнее о нем рассказывали в одной из наших статей. В основном он нужен пользователям, которые не сидят за компьютером, а постоянно находятся в движении.
И последний компонент — ESB (Enterprise Service Bus). Он позволяет общаться с внешними системами, обрабатывать и получать заказы, отправлять сведения о том, что мы обработали заказы.
Почему бы не перейти на микросервисы? А вот почему
Бизнес-процессы нашего склада тесно связаны между собой — это нормальная ситуация для монолитной архитектуры. Плюс под управлением WMS находится более чем 250 сущностей, где постоянно меняется их статус. И это для монолитной архитектуры также абсолютно приемлемо.
Недавно перед нами встала задача: мы должны были заменить подпроцесс Reject на абсолютно новый. Вытащить его из связанной логики было не так просто. Пришлось немного повоевать, но в итоге мы это сделали. И тут пришло понимание, что пора как-то инкапсулировать нашу логику.
Наверное, первое, что приходит в голову — переписать всё на микросервисы. Но они предполагают управление скромным количеством сущностей, а еще для каждого микросервиса нужна своя база данных. Но у нас очень много объектов, а значит, понадобится очень много баз данных. А после одного запроса на наш сервер может поменяться много сущностей.
Допустим, пришла поставка и пользователь сканирует последний товар из нее, а затем делает запрос на наш сервер. Состояние товара сразу же меняется на «принят после сканирования». Меняется состояние заказа, затем поставки и грузовика. После этого должен измениться стейт склада, так как товар стал доступен для заказа на сайте.
У нас есть связанность между бизнес-процессами Stock и Inbound. И если что-то пойдет не так, мы всегда сможем откатиться благодаря механизмам транзакций в базе данных. Так что, микросервисы нам не очень подходят.
Конечно, мы используем такие паттерны, как распределенные транзакции. Но в основном они сводятся к тому, что мы должны руками написать огромное количество роллбэков. А так как у нас очень много сущностей, то мы будем всю жизнь писать роллбэки и не делать никаких новых фич.
Также мы рассматривали для модульной архитектуры OSGI-фреймворк, но для себя нашли в нем несколько минусов. Например, проблему с большим количеством зависимостей в разных модулях, которые могут конфликтовать между собой. К тому же, это не самая популярная технология, а связка spring и osgi тоже не очень распространена. Поэтому мы решили отказаться от него.
К какому решению пришли
Итак, у нас есть три основных бизнес-процесса. Значит, мы хотим иметь три сервиса, которые будут отвечать за каждый из них.
На картинке все выглядит просто, но WMS — очень сложная система, у которой есть много скрытых процессов. Например, она контролирует сессии пользователя, направления конвейерных линий и товаров. Эти процессы тоже нельзя оставить без внимания.
Идея такова: мы делим бизнес логику на 3 основных модуля, а технические процессы (Printing Service, Conveyor Service, Tote Service и Auth Service) делаем общими, независимыми сервисами. Выглядит достаточно логично, поскольку оборудование на складе может выходить из строя, не работать, модернизироваться, обновляться. Допустим, сейчас у нас один поставщик оборудования, завтра придет другой, и на складе будет совсем другая автоматизация. Нам важно, чтобы это никак не влияло на наши основные бизнес-процессы.
В итоге получается следующая схема: три основных бизнес-процесса и четыре вспомогательных сервиса. Самое прикольное, что до сих пор остается одна база данных. То есть мы не теряем наших преимуществ в транзакции, и у нас нет проблем с распределенными транзакциями.
Сейчас у нас одна база данных с репликами. Поскольку мы используем PostgreSQL, мы собираемся разделить имеющуюся схему на несколько для каждого сервиса. Благодаря этому, мы сможем менять стейты сущностей внутри одного сервиса исходя из сущностей стейтов и другого сервиса. Следовательно, нам больше не нужна распределенная транзакция, так как это все происходит на одной базе.
Что происходит сейчас
Завершили внедрение сервиса авторизации, который был написан на базе Keycloak. Сейчас мы активно переписываем наш Printing Service с использованием второго SpringBoot и Kotlin на беке.
Выпустили новый клиент для мобильных устройств, переписав его с JSP на Android — WMS Mobile. Теперь у нас нативное приложение для мобильных устройств, которое тратит меньше энергии и имеет огромное количество возможностей.
Планируем выносить наш Conveyor service и уже настолько разогнались, что сейчас думаем, как имплементировать нашу логику для него.
В итоге мы получили инкапсулированные бизнес-процессы внутри каждого бизнес-сервиса. Изменения в одном никак не будут влиять на логику в других.
У нас есть выделенный бизнес-сервис, а служебные, как Conveyor service или сервис авторизации, могут меняться. Допустим, завтра мы решим использовать другую авторизацию или другие конвейерные линии. В этом случае легко сможем отказаться от нынешних, напишем новые сервисы, и эти изменения никак не затронут бизнес-логику.
Вся наша схема не имеет проблем с определенными транзакциями. Сейчас мы движемся в этом направлении и планируем строить наши сервисы и модульную архитектуру.