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

С каждым годом бизнес-показатели электронной коммерции набирали обороты: в 2023 году объемы реализованной через интернет-магазин продукции составили уже 50% от продаж. В какой-то момент начали появляться узкие места в работе сайта.

Задача

В начале 2021 года ритейлер обратился к нам сразу с несколькими задачами.
Первым большим направлением развития интернет-магазина стала оптимизация импорта продуктов из PIM, основными целями которого были:

1) Увеличить пропускную способность (для начала в 2 раза, но забегая вперед — мы сделали в 4!).
2) Как следствие — ускорить доставку продукта до полки интернет-магазина.
3) Сделать импорт более стабильным (с возможностью валидации и просмотра истории импортируемых данных).

Этапы реализации проекта

1. Анализ и проектирование.
Было принято решение сначала проанализировать текущую интеграцию через REST запросов в Magento API. В старой реализации использовался импорт продуктов через RESTful API Magento, что автоматически накладывало большие ограничения как на пропускную способность импорта, так и на его стабильность в целом.

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

Под сложным продуктом понимается конфигурируемый, состоящий из нескольких простых. Например, духи могут быть 30 ml, 50 ml и 100 ml — это всё один конфигурируемый товар из нескольких простых.

2) Перевод на асинхронный импорт

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

Также команда внедрила батчинг (пакетную обработку) сообщений, чтобы импорт Magento получал продукты в привычном ему виде. В итоге получили прирост в 70%, что уже больше целевого прироста оптимизации, поставленного изначально.

3) Отказ от стандартного импорта и перевод его на точечные импорты напрямую в базу данных (ускорение на 400%)

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

4) Реализация полного маппинга контракта из PIM с атрибутами в Magento. С созданием опций атрибутов и брендов на лету (порядка 200 новых значений ежедневно при общем количестве ~200.000).

Следующей задачей бизнеса стало автоматическое создание и маппинг атрибутов в процессе импорта, чтобы не было необходимости создавать их вручную — система Magento самостоятельно определяет, какие атрибуты поступили с импортом. Эта потребность возникла из-за появления большего количества потребителей данных из PIM. Ответственность за подготовку данных перешла на потребляющие системы, и Magento не стала исключением.

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

В результате работы этого решения в Magento, по данным на январь 2024 года, создано порядка 200.000 новых опций атрибутов и прирост каждые сутки порядка 500.

5) Мгновенная актуализация витрины из DAX 365

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

В рамках задачи по актуализации разработчики перевели все импорты из DAX (цены, ассортименты и стоки) на очереди из Kafka, что улучшило стабильность системы работы с продуктами. Также реализовали включение продуктов по триггерам, чтобы полностью автоматизировать этот процесс при появлении необходимых данных по товарам.

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

Полный текст статьи читайте на CMS Magazine прочитано 5241 раз