Ensi: микросервисная архитектура для крупного интернет-магазина

Монолит или микросервисы: в чём разница для магазина

Классический интернет-магазин на Битриксе или Prestashop — монолит. Каталог, корзина, заказы, личный кабинет и админка живут в одном приложении и одной базе. Пока магазин небольшой, это удобно: один репозиторий, один деплой, один разработчик понимает систему целиком.

Проблемы начинаются с ростом. Каталог на сотни тысяч позиций, десяток интеграций с 1С, WMS и маркетплейсами, несколько команд, которые правят код одновременно, — и любое изменение в модуле цен может уронить оформление заказа. Термин «микросервисы» в 2014 году описали Мартин Фаулер и Джеймс Льюис: приложение собирают из небольших сервисов, у каждого своя зона ответственности, своя база и свой цикл выпуска.

Чудес тут нет. Микросервисы переносят сложность из кода в инфраструктуру и во взаимодействие сервисов.

Есть и организационная сторона. Ещё в 1967 году Мелвин Конвей сформулировал закон: структура системы повторяет структуру коммуникаций в компании, которая её делает. Если у ритейлера отдельные команды каталога, заказов и маркетинга, сервисы по тем же границам снимают споры о том, кто и когда выкатывает свой код.

Из чего состоит архитектура крупного интернет-магазина

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

PIM в архитектуре магазина: каталог и атрибуты

PIM (Product Information Management) хранит карточки товаров: названия, атрибуты, категории, фото, описания для разных каналов. Для ритейла с 50–100 тысячами SKU это отдельная большая система. Контент-менеджеры работают в ней, не трогая заказы и цены.

OMS: заказы и их жизненный цикл

OMS (Order Management System) ведёт заказ от оформления до доставки: статусы, разбиение на отправления, резервы на складах, возвраты. Через неё идут интеграции со службами доставки и учётной системой. Когда OMS отделена от витрины, распродажа с пиковой нагрузкой на каталог не мешает обрабатывать уже оформленные заказы.

Остальные домены: цены, клиенты, контент

• ценообразование и промоакции — скидки, купоны, персональные цены;
• клиенты — профили, адреса, программа лояльности;
• корзина и чекаут — расчёт итоговой суммы и оплата;
• контент — баннеры, лендинги, страницы акций;
• фронтенд — отдельное приложение, которое ходит в сервисы по API.

Инфраструктура: Kubernetes и CI/CD

Десяток сервисов вручную на сервер не выкатишь. Каждый сервис упаковывают в Docker-контейнер, а запуском, перезапуском и масштабированием управляет Kubernetes — оркестратор, который Google открыл в 2014 году. CI/CD-конвейер, например на GitLab CI, собирает образ, прогоняет тесты и выкатывает новую версию без остановки сайта.

Готовые конфиги для Kubernetes и CI/CD в Ensi экономят команде недели на старте. Без них первые месяц-два уходят на инфраструктуру, а не на функции магазина.

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

Когда магазину нужна сервисная архитектура

Я делю проекты по масштабу так же, как в посте: небольшим и средним магазинам — Битрикс, крупному ритейлу — Ensi на Laravel. Признаки, что монолит пора разбирать на сервисы:

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

Почему PHP и Laravel, а не Java или Go

Сервисы для e-commerce пишут на чём угодно: Java, Go, Node.js, PHP. Выбор стека для ритейла упирается не столько в скорость языка, сколько в людей. Найти и удержать команду на PHP в России проще, чем на Go, а разработчики с опытом Битрикса уже знают PHP и переходят на Laravel за несколько недель.

Laravel — PHP-фреймворк, который Тейлор Отвелл выпустил в 2011 году. У него зрелая экосистема: ORM Eloquent, очереди и планировщик задач, Horizon для мониторинга очередей, Octane для долгоживущих процессов. Сервисы общаются по REST API или через брокер сообщений вроде RabbitMQ и Kafka, а язык каждого сервиса при желании можно сменить, не трогая остальные. Для сервисов магазина Laravel хватает с запасом: узкое место обычно в базе данных и внешних интеграциях, а не в языке.

Мне нравится, что один стек закрывает и средние проекты на заказной разработке, и крупные внедрения. Команда не переучивается, а переносит практики с проекта на проект.

Ошибки при переходе на сервисы

• Дробить слишком мелко. Сервис на каждую таблицу превращает систему в распределённый монолит, где один релиз требует обновить шесть сервисов.
• Делить по технологиям, а не по бизнес-доменам. Сервис «база данных» или «API» не даёт командам независимости.
• Общая база на все сервисы. Тогда изменения схемы снова ломают соседей.
• Переписывать всё разом. Надёжнее выносить домены по одному: сначала PIM, потом OMS.
• Забыть про мониторинг и трассировку до первого серьёзного сбоя.