Последнее время всё больше вопросов от заказчиков к нам приходит по поводу архитектуры нашего решения. Опять мы с Женей Древалем вступили в дебаты по поводу выбора архитектуры. После чего мы с нашей дружной командой постарались структурировать ответы на эти вопросы в некий FAQ, чтобы иметь возможность быстро и по возможности ясно ответить на большинство вопросов пользователей.
Итак, первый вопрос.На текущий момент все представленные на рынке WMS являются монолитными. Как, почему и зачем мы приняли решение строить гибридную систему с использованием микросервисов?Естественно, что говорить «монолит умер, до здравствует микросервис» не то, что рано, но даже слегка не уместно. Выбор архитектуры всегда зависит от множества факторов. Но давайте по порядку.
Монолитная архитектура представляет собой интегрированную систему, где все компоненты и функциональности являются частью одного приложения. В монолите все компоненты взаимодействуют напрямую друг с другом. Примером монолитного WMS может быть система, в которой все функции - от формирования топологии до управления заданиями и их исполнения - реализуются внутри одной системы. На текущий момент все представленные на рынке решения относятся к «монолитам», развивавшимся десятилетиями и обросшие таким количеством легаси, что проще написать все заново, чем капитально изменить имеющуюся архитектуру. Чаще всего эта архитектура сводится к данным в БД, бизнес логике, построенной на SQL-запросах или, о ужас, на хранимых процедурах и некоторому фреймворку для построения фронт-энда.Плюсы монолитной архитектуры WMS:
1. Простота: Монолиты проще разрабатывать и администрировать, так как все компоненты внутри одного приложения. Исторически так сложилось, что на рынке большая часть проектов делается на решениях, построенных с использованием платформы «1С:Предприятие», что также упрощает «вход» в мир WMS ввиду большого количества разработчиков.
2. Меньшие задержки при обращении к компонентам: Все компоненты монолита обычно находятся в одной физической среде, что уменьшает задержки при передаче данных и взаимодействии компонент между собой. Однако со временем такая система становится сложной и тяжелой, и любые взаимодействия в ней затрудняются.
3. Простота отладки: Когда весь код и логика находятся в одном приложении, проще отслеживать и устранять ошибки, ведь весь код находится в одной среде программирования.
Минусы монолитной архитектуры WMS:
1. Сложность масштабирования: Прирост нагрузки на систему может означать, что нужно масштабировать всё приложение целиком, даже если только одна его часть испытывает проблемы. Например, при росте нагрузки в пиковый сезон, создается большое количество задач на отбор, при этом входящий поток может оставаться неизменным, но увеличивать мощности придется для всей системы, что в случае с вариантом использования системы On-Premise потребует приобретение нового сервера или модернизации действующего.
2. Отсутствие гибкости: Внесение изменений в одну часть монолита может потребовать пересборку, тестирование и публикацию всего приложения.
3. Риски при обновлениях: Обновление монолита может представлять собой большой риск, поскольку любая ошибка может сразу привести к недоступности всей системы, а при использовании системы для управления несколькими складами, это может быть риском «обрушения» всей логистической цепи.
4. Сложность внедрения новой функциональности. Внедрение новых технологий в монолит может быть сложным или невозможным без переписывания всего приложения. Так, например, все вендоры, которые сейчас присутствуют на рынке, буквально поседели, а в аптеках заканчивался «Ново-Пассит», когда государство ввело «Честный знак» и всем пришлось перерабатывать полностью структуру хранения данных об остатках.
В целом, монолитная архитектура WMS обладает простотой и удобством в управлении, но ограничивает гибкость и масштабируемость системы, а также усложняет внедрение новых функциональных возможностей.
Микросервисная архитектура, с другой стороны, представляет собой распределенную систему, состоящую из набора независимых приложений (микросервисов), каждый из которых выполняет конкретную функцию. Микросервисы взаимодействуют посредством REST API, что позволяет им быть разработанными и внедряемыми независимо друг от друга. В контексте WMS это может означать, что каждый сервис будет отвечать за управление определенным функциональным блоком системы, например, планированием заданий на размещение или отбор.
Плюсы архитектуры нашей WMS:
1. Масштабирование. Каждый компонент системы может получить вычислительные мощности, что в нашем случае позволит разнести размещение и отбор по разным «серверам» и получить возможности для неограниченного масштабирования не только в плане количества обрабатываемых заказов или сотрудников, но и обслуживаемых одной инсталляцией WMS складов.
2. Гибкость. Любая новая функциональность может быть разработана в новом и/или существующем сервисе, при этом абсолютно необязательно переписывать всю систему целиком. Существует возможность развертывания микросервисов независимо друг от друга, что очень удобно для складов, которые переходят на WMS частями/операциями. Например, сначала мы можем запустить входящий поток, а с течением времени исходящий поток и внутренние операции без остановки склада и WMS, без пересборки системы, что положительно влияет на скорость запуска и стоимость услуг.
3. Снижение рисков. В случае какого-то сбоя в микросервисе, все остальные сервисы остаются работоспособными. Отладка занимает существенно меньше времени, чем в случае с монолитом.
Минусы архитектуры нашей WMS:
1. Высокие требования к команде разработки. Для разработки системы требуются люди, с мягко скажем, другим набором знаний. Здесь потребуются спецы с пониманием CLOUD, API, Docker и т.д. Благо сейчас всё больше разработчиков на рынке, знакомых с данными технологиями.
2. Память. Её нужно много. Это не совсем требования микросервисов, но система для работы держит в памяти объектную модель склада и его окружения. Все наши алгоритмы работают с готовыми объектами в памяти, переходят по объектным ссылкам, ищут по хэш-мэпам — это очень быстро. При этом БД играет роль лога, где хранит актуальные состояния объектов.
Подведем предварительные итоги по различиям в WMS, построенных на монолитной и микросервисной архитектуре:
1. Управление.
В монолитной архитектуре все компоненты находятся в одной среде, что упрощает управление системой.В микросервисной архитектуре необходимо управлять набором отдельных микросервисов.
2. Масштабирование.
В монолитной архитектуре масштабирование происходит путем масштабирования всего приложения.В микросервисной архитектуре можно масштабировать только нужные компоненты, что позволяет более гибко управлять ресурсами.
3. Развитие и изменения.
В монолитной архитектуре изменения определенного компонента требуют пересборки и публикации всего приложения.В микросервисной архитектуре можно изменять и развивать каждый микросервис независимо от других.
4. Ошибки и отладка.
В монолитной архитектуре отладка и поиск ошибок проще, так как весь код и логика находятся в одном приложении.В микросервисной архитектуре необходимо отслеживать и отлаживать каждый отдельный сервис.
5. Гибкость и скорость развертывания.
В микросервисной архитектуре возможно быстрое развертывание и масштабирование новых сервисов без переписывания всего приложения.В монолитной архитектуре это затруднительно.
6. Риски при обновлениях.
В монолитной архитектуре обновление всего приложения может быть рискованным, так как любая ошибка может привести к недоступности всей системы.В микросервисной архитектуре можно обновлять каждый сервис независимо и минимизировать риски.Микросервисная архитектура WMS позволяет более гибко управлять и развивать систему, но требует дополнительных усилий по управлению и координации отдельных сервисов.Выбор между этими двумя подходами зависит от конкретных потребностей, ограничений и возможностей организации. Если у вас есть сомнения или вопросы, обращайтесь – wms@logareon.ru
