Привет! Меня зовут Евгений Рябышев, я разработчик в одной из команд направления «Системы управления складом (WMS)» компании Lamoda. Я автоматизирую склад. В этой статье я расскажу вам, как мы строим нашу модульную архитектуру.
Наши основные бизнес-процессы по управлению складом выстроены давно и доказали свою эффективность.
В то же время они сильно связаны друг с другом.
Склад — это большой монолит, который невозможно безболезненно разделить на части.
Но решение было найдено: строим модульную архитектуру без использования микросервисов.
Складские бизнес-процессы: от поступления товара до отправки покупателю
В настоящее время WMS представляет собой монолитную архитектуру, которая поставляется в виде одного файла .ear и развертывается в контейнерах приложений в Wildfly. Он позволяет управлять тремя основными бизнес-процессами на складе.
Входящий отвечает за входящий поток товаров.
, партнерские или свои, которые мы покупаем на продажу через сайт или мобильное приложение.
Внутри есть бизнес-процессы, связанные с товарами: Rejects и Claims (возврат и претензии соответственно).
Если одежда или обувь не устраивает покупателя, мы возвращаем эти вещи и помещаем их обратно на склад. 
Здесь находится бизнес-процесс.
CIC (Центральный входящий клиринг) .
Это позволяет сотрудникам склада решать проблемы при поступлении товара.
Например, на товаре нет наклейки и его перепечатывают, или товар не соответствует изображению, к которому прикреплен.
Исходящий – исходящий поток товаров.
Когда пользователь размещает заказ в Lamoda, все начинается с управления заказами.
Это подпроцесс, отвечающий за начало сборки заказа.
После того, как работники склада собрали товар в заказ, начинается упаковка.
Мы используем три метода:
- Полуавтоматический сортировщик упаковочных материалов.
- Ручная упаковка мини-пакетами.
Это рабочее место с компьютером и столом, на котором находится упаковочный материал.
- Автоматическая упаковка с помощью AVM (автоматическая упаковочная машина или автоматическая упаковочная машина).
После этого размещаем товар на поддонах.
Начинается подпроцесс Паллетизация : Заказы отправляются по назначению.
Также есть подпроцесс COS (центральный исходящий клиринг) .
Он используется для тех же целей, что и центральный входящий клиринг, но только на этапе отгрузки.
Запас — последний основной бизнес-процесс.
Он имеет три подпроцесса.
- Putaway занимается размещением товаров на складе.
- Комплектование отвечает за сборку товаров для заказа и внутренний аудит. Например, когда менеджеры хотят проверить срок годности косметики.
- Инвентарь.
Необходимо провести частичную или полную инвентаризацию на складе.
Архитектура WMS: из чего она состоит?
Первый компонент – это Полиграфические услуги , который отвечает за печать этикеток.
Они размещены повсюду: на поддонах, товарах, контейнерах, рабочих станциях – в общем, на всех объектах, управляемых WMS. Таким образом, этикетка позволяет работнику склада понять, с чем он в данный момент имеет дело.
Мониторинг является основным сервисом для оперативных менеджеров, поскольку отражает состояние склада в режиме реального времени.
Сотрудник склада всегда может понять, что делать в период пиковой нагрузки.
Например, передать группу людей, которые будут разгружать или переносить товар.
Мониторинг помогает складу работать гораздо эффективнее.
Следующий компонент — внешний клиент .
Его можно разделить на два подтипа: клиент для рабочей станции, в котором происходит упаковка, и клиент для настольных компьютеров, написанный на Angular. Последнее необходимо для того, чтобы пользователи могли общаться с нашей WMS. Также есть мобильный клиент. Подробнее об этом мы говорили в одном из наших статьи .
В основном он нужен пользователям, которые не сидят за компьютером, а постоянно находятся в движении.
И последний компонент - ESB (корпоративная сервисная шина) .
Он позволяет вам взаимодействовать с внешними системами, обрабатывать и получать заказы, а также отправлять информацию о том, что мы обработали заказы.
Почему бы не перейти на микросервисы? Вот почему
Бизнес-процессы нашего склада тесно взаимосвязаны – это нормальная ситуация для монолитной архитектуры.Плюс WMS контролирует более 250 организаций, статус которых постоянно меняется.
И это тоже абсолютно приемлемо для монолитной архитектуры.
Недавно перед нами встала задача: нужно было заменить подпроцесс Reject на совершенно новый.
Вытащить его из связанной логики было не так-то просто.
Нам пришлось немного побороться, но в итоге мы это сделали.
И тут пришло понимание, что пора как-то инкапсулировать нашу логику.
Наверное, первое, что приходит в голову — переписать всё на микросервисы.
Но они предполагают управление небольшим количеством объектов, и каждому микросервису также нужна собственная база данных.
Но объектов у нас много, а значит, нам понадобится много баз данных.
И после одного запроса к нашему серверу может измениться множество сущностей.
Допустим, пришла поставка и пользователь сканирует из нее последний товар, а затем делает запрос на наш сервер.
Статус отправления сразу меняется на «принято после сканирования».
Меняется статус заказа, затем доставка и фура.
После этого статус склада должен измениться, так как товар стал доступен для заказа на сайте.
У нас есть связь между бизнес-процессами Stock и Inbound. А если что-то пойдет не так, мы всегда сможем выполнить откат благодаря механизмам транзакций в базе данных.
Итак, микросервисы нам не очень подходят. Конечно, мы используем такие шаблоны, как распределенные транзакции.
Но в основном они сводятся к тому, что нам приходится писать огромное количество откатов вручную.
А так как сущностей у нас много, то мы всю жизнь будем писать откаты и не делать новых фич.
Мы также рассматривали OSGI-фреймворк для модульной архитектуры, но для себя нашли в нем несколько недостатков.
Например, проблема с большим количеством зависимостей в разных модулях, которые могут конфликтовать между собой.
К тому же это не самая популярная технология, и сочетание пружины и осги тоже не очень распространено.
Поэтому мы решили отказаться от этого.
К какому решению вы пришли?
Итак, у нас есть три основных бизнес-процесса.Это означает, что мы хотим иметь три службы, которые будут отвечать за каждую из них.
На картинке это выглядит просто, но WMS — очень сложная система, имеющая множество скрытых процессов.
Например, он контролирует сессии пользователей, направления конвейерных линий и товаров.
Эти процессы также нельзя игнорировать.
Идея такая: делим бизнес-логику на 3 основных модуля, а технические процессы (Служба печати, Служба конвейеров, Служба тотализатора и Служба аутентификации) делаем общими независимыми сервисами.
Это выглядит вполне логично, поскольку оборудование на складе может выйти из строя, не работать, модернизироваться или обновляться.
Допустим, сейчас у нас один поставщик оборудования, завтра приедет другой, и на складе будет совсем другая автоматизация.
Для нас важно, чтобы это никак не повлияло на наши основные бизнес-процессы.
В результате получается следующая схема: три основных бизнес-процесса и четыре вспомогательных сервиса.
Самое крутое, что осталась всего одна база данных.
То есть мы не теряем своих преимуществ в транзакции и у нас нет проблем с распределенными транзакциями.
Теперь у нас есть одна база данных с репликами.
Поскольку мы используем PostgreSQL, мы собираемся разделить существующую схему на несколько для каждого сервиса.
Благодаря этому мы сможем менять состояния сущностей внутри одного сервиса на основе состояний сущностей другого сервиса.
Поэтому нам больше не нужна распределенная транзакция, так как все происходит на одной базе.
Что сейчас происходит
- Мы завершили внедрение сервиса авторизации, который был написан на базе Keycloak. Сейчас мы активно переписываем нашу службу печати, используя второй SpringBoot и Kotlin на сервере.
- Мы выпустили новый клиент для мобильных устройств, переписав его с JSP на Android — WMS Mobile. Теперь у нас есть нативное приложение для мобильных устройств, которое потребляет меньше энергии и имеет огромное количество функций.
- Мы планируем развернуть наш сервис Conveyor и уже настолько быстро это сделали, что теперь думаем о том, как реализовать для него нашу логику.
Изменения в одном не повлияют на логику других.
У нас есть выделенный бизнес-сервис, а сервисные, такие как Конвейер или сервис авторизации, могут меняться.
Допустим, завтра мы решим использовать другую авторизацию или другие конвейеры.
В этом случае мы легко можем отказаться от текущих, написать новые сервисы, и эти изменения никак не повлияют на бизнес-логику.
Вся наша схема не имеет проблем с некоторыми транзакциями.
Сейчас мы движемся в этом направлении и планируем строить наши сервисы и модульную архитектуру.
Теги: #Управление проектами #java #склад #модульная архитектура
-
Вам Нужны Услуги Веб-Сайта Uebersetzen?
19 Oct, 24 -
Часть 1. Краткие Советы По Трафику
19 Oct, 24 -
Дизайн С Большой Буквы.
19 Oct, 24
