Монолит или микросервисы: какую архитектуру выбрать для ERP-системы

Проблемы монолитной архитектуры ERP

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

1. Сложные и рискованные релизы

Даже небольшое изменение, например добавление поля «срочность» в заказ, может повлиять на связанные отчеты, расчеты или бизнес-процессы. Чем больше зависимостей между модулями, тем сложнее тестировать изменения и выпускать обновления.

2. Ограниченные возможности масштабирования

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

3. Высокая связанность усложняет развитие системы

Отдельный модуль сложно перевести на другой язык программирования или фреймворк, если он тесно связан с остальной системой. Поэтому монолитные ERP часто долго остаются на первоначальном технологическом стеке, а его постепенное обновление требует значительных ресурсов.

Почему полный переход ERP на микросервисы может создать новые проблемы

Полный переход ERP на микросервисы может решить одни архитектурные проблемы, но одновременно создать другие. Особенно это касается транзакций, эксплуатации и согласованности данных.

Причина № 1. Сложнее поддерживать ACID-транзакции

ACID, то есть атомарность, согласованность, изоляция и долговечность, лежит в основе финансовых операций. В монолите связанные изменения можно выполнить в рамках одной транзакции: обновить несколько таблиц и отменить все операции, если на одном из этапов возникла ошибка.

В микросервисной архитектуре сервисы обычно используют отдельные базы данных. Если одна операция затрагивает несколько сервисов, для согласования изменений требуются дополнительные механизмы, например двухфазный коммит (2PC). При большом количестве сервисов такой подход увеличивает задержки и риск блокировок.

Причина № 2. Эксплуатация становится сложнее

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

В публикациях о Segment описывается опыт сокращения количества небольших сервисов из-за высокой сложности их эксплуатации.

Причина № 3. Возникает проблема согласованности данных

При разделении системы данные об одной сущности могут храниться сразу в нескольких сервисах. Например, информация о товаре или контрагенте может дублироваться в разных базах.

В таком случае необходимо определить основной источник данных и обеспечить синхронизацию между системами. Для ERP расхождения особенно критичны: складской и финансовый контуры должны работать с согласованной информацией.

Так что полный переход ERP на микросервисы подходит не во всех случаях. Гибридная архитектура позволяет сохранить критически связанные процессы в едином контуре, а независимые компоненты вынести в отдельные сервисы.

Какие функции ERP лучше оставить в монолитном ядре

В отдельные сервисы целесообразно выносить компоненты, которые часто меняются, требуют независимого масштабирования и не связаны напрямую с критическими финансовыми операциями. При необходимости для них можно использовать другой технологический стек, например PHP для монолита и Go для WMS.

1. Складская логистика (WMS)

Маршруты сборки, размещение товаров по ячейкам и управление паллетами зависят от процессов конкретного склада и могут регулярно меняться. При этом таким операциям не всегда требуется мгновенная синхронизация с финансовым контуром.

2. Расчет заработной платы

Расчет заработной платы создает значительную вычислительную нагрузку и выполняется периодически. Его выделение в отдельный сервис позволяет не увеличивать нагрузку на процессы, связанные с обработкой заказов.

3. Личные кабинеты сотрудников и порталы

Внешние интерфейсы и мобильные приложения можно отделить от основного ядра. Тогда временная недоступность портала не влияет на выполнение критически важных операций внутри ERP.

4. Интеграции с внешними системами

CRM, маркетплейсы и другие внешние системы могут иметь собственные форматы данных, ограничения и нестабильное время ответа. Отдельный интеграционный слой позволяет изолировать эти особенности от внутренней структуры ERP.

Основной принцип

В отдельные сервисы выносятся компоненты с высоким темпом изменений и низкой связностью с финансовым контуром. Изменения в монолитном ядре при этом сводятся к необходимому минимуму.

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

Как разделить систему на домены с помощью DDD

DDD (Domain-Driven Design) помогает разделить бизнес-логику на ограниченные контексты (bounded contexts). В каждом контексте формируются собственная модель данных, бизнес-правила и зона ответственности.

Одна из задач аналитика состоит в проведении Event Storming, метода совместного моделирования бизнес-процессов с участием экспертов. В ходе работы определяются агрегаты, ключевые сущности, требования к согласованности данных и границы между контекстами.

На основе этой информации команда определяет, какие части системы должны оставаться связанными, а какие можно выделить в самостоятельные сервисы.

Результатом работы становится карта контекстов (Context Map). Она фиксирует границы доменов, связи между ними и точки взаимодействия между монолитным ядром и микросервисами.

Как Anti-Corruption Layer защищает монолитное ядро ERP

Микросервисы могут возвращать некорректные данные, становиться временно недоступными или менять формат взаимодействия. Если учитывать все эти особенности непосредственно в монолите, ядро постепенно обрастает логикой обработки внешних ошибок и исключений.

Для изоляции таких зависимостей применяется ACL (Anti-Corruption Layer). Этот слой располагается между внешним сервисом и ядром, проверяет входные данные и преобразует их во внутреннюю модель системы.

Задача системного аналитика состоит в том, чтобы определить требования к ACL, в том числе:

• какие форматы и значения допустимы, например вес товара в килограммах в установленном диапазоне;
• как обрабатывать некорректные данные: отклонять запрос, отправлять сообщение в очередь недоставленных сообщений или применять допустимое преобразование;
• как сопоставлять поля внешнего сервиса с моделью данных ядра.

Этот подход позволяет отделить особенности внешних сервисов от критически важной логики ERP и снизить риск ошибок в основном контуре системы.

Как синхронизировать данные между монолитом и микросервисами

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

Паттерн 1. Event-Driven

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

Паттерн 2. Batch

Используется для больших объёмов данных, если допустима задержка в несколько минут или часов. Например, остатки между складским сервисом и монолитом можно сверять с заданной периодичностью. По расписанию запускается задача, которая получает накопившиеся изменения и передает их в другой компонент системы. Для такой задачи, например, можно использовать Laravel Scheduler.

Результатом работы аналитика может быть таблица, в которой для каждого процесса указаны допустимая задержка, требования к объему и актуальности данных, выбранный способ синхронизации и условия его применения.

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

Управление ссылочной целостностью между монолитом и сервисами

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

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

В качестве альтернативы применяется паттерн Saga. Он представляет собой последовательность локальных транзакций, для каждой из которых при необходимости определяется компенсирующее действие.

Задача системного аналитика состоит в том, чтобы описать каждую Saga: определить последовательность шагов, компенсирующие действия, правила обработки частичных сбоев и способ координации процесса.

Пример: «Оплатить и отгрузить заказ»

1. Сервис платежей: списать деньги со счёта клиента.Компенсация: вернуть списанную сумму.
2. Монолитное ядро: создать счет-фактуру и провести операцию в учете.Компенсация: выполнить сторнирование.

Если второй шаг завершается ошибкой, Saga инициирует компенсирующее действие для первого шага. В результате списанная сумма возвращается клиенту, а система возвращается в согласованное состояние.

Кейс: Как мы вынесли отгрузки из монолита на PHP

У нас был ERP-монолит на Laravel. Все работало терпимо, пока не пришел крупный клиент с тремя складами.

Проблема: при создании накладной запускался тяжелый расчет остатков. Монолит заблокировал таблицу на 2–3 секунды. В час пик (500 накладных) база вставала в очередь. Сотрудники склада ждали. Время от времени все падало.

Мы не стали переписывать все в микросервисы (финансовое ядро трогать побоялись). Сделали гибрид.

Что оставили в монолите:

• Расчет себестоимости.
• Проводки и остатки в бухгалтерском учете.

Что вынесли в микросервис: логику резервирования и сборки заказа на складе (WMS-логику). Для связи использовали RabbitMQ.

Схема стала такой:

1. Монолит создает заказ и кидает событие в очередь.
2. Микросервис читает событие, резервирует товары в своей Redis-базе.
3. После сборки сервис шлет событие.
4. ACL внутри монолита ловит событие, проверяет данные и финально списывает остатки через локальную транзакцию.

Монолит, микросервисы или гибрид: что выбрать для ERP

В этой статье мы рассмотрели разные подходы к проектированию архитектуры. На основе этого выделим ключевые мысли.

1. Микросервисы подходят не для всех задач ERP

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

2. Гибридная архитектура позволяет разделить задачи по требованиям

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

3. Системный аналитик определяет границы и правила взаимодействия

DDD помогает определить границы доменов, ACL изолирует ядро от особенностей внешних сервисов, а паттерны синхронизации и Saga задают правила обмена данными и обработки распределенных операций.

Ошибки, допущенные при разделении системы на домены и проектировании взаимодействий, впоследствии могут потребовать значительных изменений в архитектуре и увеличить стоимость разработки и поддержки.