Как адаптировать архитектуру Enterprise-ритейла после ухода западных вендоров? На примере маркетплейса «БИ-БИ» разбираем, почему в условиях специфической бизнес-логики и высоких нагрузок кастомный подход может быть эффективнее коробочных решений. Рассказываем, как мы построили платформу на микросервисах (Laravel + Go), внедрили асинхронный обмен данными через Kafka и MongoDB и ускорили работу корзины с помощью горутин.

Всем привет! Я – Владислав Кабаев, CPO в компании QSOFT, и я хочу рассказать, как мы разрабатывали автономную ecom-платформу на смену SAP Hybris для маркетплейса «БИ-БИ».

До 2022 года российский Enterprise-ритейл во многом опирался на зарубежные решения: SAP Commerce Cloud (Hybris) и Salesforce Commerce Cloud (Demandware) были де-факто станда��том рынка. Их выбирали крупнейшие игроки — от Wildberries (использовавших SAP вместе со своей разработкой) до «Ситилинка».

После ухода западных вендоров рынок начал активно перестраиваться. Часть компаний обратилась к отечественному ПО, выбирая решения под свои масштабы. Для сегмента среднего бизнеса ими стали популярные платформы вроде 1С-Битрикс или облачные сервисы типа inSales. Игроки покрупнее начали рассматривать более гибкие или специализированные системы, такие как Ensi, или внедрять розничные модули на базе CRM-систем.

При миграции с SAP Hybris компании часто сталкиваются с тем, что стандартные рыночные решения требуют серьезной адаптации под Enterprise-процессы. Основной вызов здесь кроется не только в наборе функций, но и в самой архитектуре: многие продукты изначально проектировались как монолитные системы. Для крупного ритейла с его динамическими нагрузками и необходимостью постоянно кастомизировать узкие места такой подход может стать сдерживающим фактором.

Почему Enterprise-ритейл часто не помещается в «коробку»?

Одной из ключевых особенностей стандартных решений часто выступает их монолитная структура. Когда e-commerce платформа является частью монолитной ERP (особенно на базе 1С), возникают критические сложности:

  • Производительность. При всплесках трафика или нагруженных распродажах падает скорость всего сервиса целиком.

  • Масштабирование. Невозможно выделить ресурсы отдельно под нагруженный поиск или корзину — приходится масштабировать все решение целиком.

  • Ограниченная кастомизация. Сложно внедрять персональные предложения, динамические цены и инвентаризацию в реальном времени на сотнях тысяч SKU из-за архитектуры БД.

  • Медленный Time-to-Market. Типовой функционал реализуется максимально универсально, что часто идет в ущерб скорости работы и гибкости доработок.

При детальном анализе требований проекта «БИ-БИ» мы пришли к выводу: главная ценность здесь заключается в максимально гибком управлении бизнес-логикой. Учитывая объем специфических задач, на первый план вышла необходимость создать полностью автономную среду. Это позволило бы клиенту не зависеть от вендорских лицензий и жестких рамок поддержки, а также обеспечило бы неограниченное пространство для кастомных доработок и быстрого масштабирования инфраструктуры под нужды бизнеса.

Кейс «БИ-БИ»: задачи, продиктованные спецификой рынка

«БИ-БИ» — это крупная федеральная сеть магазинов автозапчастей и аксессуаров с сотнями тысяч SKU и развитой розничной сетью. Проект содержит много специфики, которую крайне сложно реализовать в рамках стандартного смарт-фильтра или коробочного обмена данными:

  1. Гибридный каталог. Система объединяет собственные стоки и товары внешних поставщиков. Основной вызов — обеспечить высокую скорость загрузки данных при проценке (запросах к партнерам). Мы реализовали интеграцию, которая позволяет обрабатывать массивы внешних данных без задержек для пользователя.

  2. Кастомная 1С. У клиента используется сильно доработанная версия 1С с нестандартным функционалом, что потребовало создания уникальной асинхронной интеграции.

  3. Динамическое ценообразование. Цена на сайте зависит от множества параметров: региона, роли пользователя и даже конкретного офлайн-магазина.

  4. Специфический подбор. Система подборщиков запчастей по марке и конкретному автомобилю, а также интеграции с внешними каталогами и поисковиками по VIN или госномеру.

  5. Высокие нагрузки на фильтрацию. Стандартный каталог со смарт-фильтрацией в коробочном исполнении не выдержал бы такие нагрузки при текущем объеме SKU.

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

Выбор в пользу кастомной архитектуры стал для «БИ-БИ» инвестицией в гибкость системы. Такой подход позволил чисто реализовать сложную логику «нативно», сохранив высокую скорость работы и возможность беспрепятственного масштабирования платформы в будущем. 

Архитектура решения: микросервисы в кластере Kubernetes

Мы построили приложение на микросервисной архитектуре. Большая часть сервисов реализована на Laravel, а критические узлы, требующие высокой производительности и асинхронности — на Go. Все это развернуто в кластере Kubernetes, что позволяет масштабировать каждый контейнер отдельно.

Каталог на ElasticSearch

Каталог работает через ElasticSearch с использованием двух процессов:

  • Полный ночной сбор индексов по всем регионам.

  • Порционная переиндексация (раз в 15 минут) для накопления текущих изменений. Индексы разделены по регионам, так как состав доступных товаров зависит от остатков в конкретной локации пользователя.

Высокая производительность на Go

Сложные задачи мы вынесли в отдельные Go-сервисы:

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

  • Конвертация изображений. Реализована через события в S3-хранилище (Minio) и Kafka. Сервис подхватывает событие о новом файле, конвертирует его в WebP и возвращает в хранилище.

Асинхронное взаимодействие с 1С

Обмен данными с 1С построен полностью асинхронно через REST API, Kafka и MongoDB. Это обеспечивает высокую пропускную способность и позволяет использовать retry-политику.

Направление 1С -> Сайт:

  1. 1С отправляет сообщение по API.

  2. Сервис интеграции (Go) валидирует его и отдает ответ о приемке.

  3. Тело сообщения сохраняется в MongoDB, а ID записи публикуется в Kafka. Использование MongoDB обусловлено тем, что пакеты данных (полные цены региона, файлы сертификатов) часто превышают стандартный лимит Kafka в 1 Мб.

  4. Конечные сервисы забирают данные из Mongo по ID из Kafka и применяют изменения.

Направление Сайт -> 1С. Событие на сайте (например, заказ) -> Kafka -> Сервис интеграции (Go) -> Внутренняя очередь -> REST API в 1С.

Идемпотентность и актуальность данных

Чтобы избежать ситуации, когда старое сообщение (например, об остатке товара) перезаписывает новое из-за задержки в очереди, мы внедрили:

  • Уникальные UUID для каждого сообщения.

  • Расчет хеша и метки времени для каждой сущности. Данные из «старых» сообщений просто не перетирают более актуальные изменения.

Трассировка и логирование (Graylog)

В асинхронной среде простого логирования недостаточно. Мы использовали Graylog, где каждый процесс помечается уникальным UUID (Trace ID). Этот ID помещается в контекст лога и передается между микросервисами через HTTP-заголовки.

Зная UUID, можно проследить всю цепочку: от входящего сообщения 1С или запроса пользователя до финального действия в базе данных. Также в контекст сохраняются ID заказа, корзины или пользователя, что позволяет видеть все связанные логи по конкретной сущности.

Итог

Замена SAP Hybris на кастомную платформу позволила «БИ-БИ» получить инструмент, полностью адаптированный под уникальную бизнес-логику рынка автозапчастей. Микросервисный подход обеспечил отказоустойчивость и возможность гибко управлять ресурсами системы, что невозможно в рамках стандартных коробочных решений.

Для конечных потребителей эти архитектурные сложности конвертировались в стабильную работу сайта в пиковые нагрузки и актуальность цен в корзине даже при их резких колебаниях у поставщиков. Команда «БИ-БИ» при этом получила прозрачную и управляемую систему: сквозное логирование и микросервисы позволяют быстро локализовать проблемы и внедрять новый функционал, не затрагивая стабильность всей платформы.

Поделитесь, были ли у вас похожие проблемы при миграции с зарубежных решений? Как вы их решали?