Меня зовут Максим, я руководитель проектов в ИНТЕРВОЛГЕ.
Мы с командой уже несколько лет развиваем сеть B2B/B2C интернет-магазинов нашего клиента. Хочу сегодня рассказать про рефакторинг. И кода, и потоков данных.
Не всегда легко объяснить бизнесу зачем нужно чинить то, что казалось бы, и так работает – но в нашем случае руководители проекта сами ждали этой реформы.
Исторически сложилось, что сайты нашего клиента, международной компании Levenhuk, подтягивали информацию (очень много и очень часто!) из внутреннего самописного хранилища данных о товарах на СУБД PostgreSQL. Цены шли из 1С, а вот контент — из отдельной базы.
Эта база использовалась еще с тех времен, когда сайты были написаны на нескольких разных платформах, и было много отдельных импортов. Мы запускаем новые сайты и языковые версии, и параллельно наводим порядок.
Дисклеймер — с PostgreSQL все отлично, проблема не в конкретной СУБД, а в самом подходе к работе с данными.
Мы уже описывали архитектуру этого мультиязычного B2B-сайта с большим количеством магазинов в разных странах.
Проект активно развивается: добавляются и функции, и языки и товарные группы. Нужна скорость и легкость. А вот дополнительная база со временем стала мешать.
Мы нашли решение — самописное хранилище данных на СУБД PostgreSQL перенести в ту же БД MySQL, на которой работает сам сайт.
Фактически огромный кусок информационной архитектуры проекта мигрировал в БУС (Битрикс: Управление Сайтом), все бизнес-сущности перешли в инфоблоки и Highload-блоки.
Для желающих понять суть: highload-блок Битрикса — это просто физическая таблица с набором довольно низкоуровневого API. А вот инфоблок штука более сложная, предназначенная для задач построения логики высокого уровня. Она много чего умеет, но она не держит действительно высоких нагрузок.
Разницу между ними мы понимаем и выбираем инструменты по целям. Собственно про это и вся статья — про выбор инструментов под цели.
Поехали!
Предыстория и бизнес-задача
В проекте много сайтов, розничных и оптовых, на разных языках.
Архитектура была такой:
Нужно было:
Ускорить обновление товаров (в старой архитектуре на получение обновления товара могло уйти до 20 часов, обмен работал медленно и потому шел постоянно, свежие обновления попадали в хвост очереди).
Создать одно хранилище, которое встроится в информационную систему и будет работать для новых проектов.
Ранее было два одинаковых скрипта, которые работают с двумя разными сайтами, что уже избыточно. Был и еще скрипт для поиска и обновления товаров.
Для ускорения обновления мы решили заменить эти два скрипта на один агент — Enrich, который позволял бы распределить процесс обновления товаров на сайте. Далее расскажем о нем и его структуре — подробнее.
Почему решили что-то менять? Почему просто не «досыпать ресурсов».
В самописном хранилище содержатся данные для «обогащения» сайта информацией о свойствах товаров: свойства, описания, картинки — и все это на 10+ языках.
Критическая проблема с масштабированием проекта — это увеличение памяти под каждый сайт.
Каждый раз требуется больше памяти — как оперативной, так и постоянной (эта проблема, в целом, решаема и не такая страшная).
Была и экономическая причина:
старая админка — неудобно работать;
слабая поддержка — медленно вносятся изменения, долго ждать и дорого платить;
бизнес (что неудивительно) хочет больше продавать и меньше разговаривать с программистами. Нужно чтобы изменения в логику и контент вносились быстрее, а настройки были проще.
Архитектура Enrich
Enrich — особый агент на сайте, который следит за товарами. Он их «обогащает» переводами (много языковых версий), свойствами из базы данных и активирует.
Вот схема работы Enrich в связке с PostgreSQL.
Мы стали записывать товары в HighLoad-блоки (физические таблицы) из которых Enrich брал информацию и распределял между таблицами SKU и товаров в интернет-магазинах.
Дальнейший рефакторинг системы Enrich
Что это даст? Как минимум оптимизирует хранение всех данных в БД, а также многократно ускорит процесс обновления информации на стороне сайта.
По шагам, то получается следующий порядок процесса рефакторинга:
При импорте из 1С GUID раздела сохранять в SKU.
Настроить ActiveMQ для Enrich.
Добавить mapper'ы, которые объединяют SKU в рамках товаров.
Разместить модуль enrich в отдельный репозиторий (B2B, B2C).
Что переносим из старого хранилища?
Переносим все поля свойств из PostgreSQL в highload-блок Битрикса, мы называем его LOC.
Это простой, но в тоже время самый нагруженный процесс, т.к. текущие таблицы очень большие и необходимо правильно и с сохранением связей передать их в highload-блок Битрикса, чтобы не нарушить целостность всей системы.
Перенеся все данные, мы можем отключать старое хранилище и пользоваться новым быстрым вариантом и дальше развивать логику магазинов.
Как выглядит обмен данными теперь
После переноса всех данных текущий механизм работает намного быстрее. Следующий этап — визуальная часть системы управления контентом LOC для удобной работы с внесением новой информации по товарам с учетом тех практик, что были на старой версии, также добавили новые решения.
Стандартная админка Битрикса в чистом виде тут не подходит, много специфических операций делаются в этом интерфейсе.
Конечная архитектура, к которой мы стремимся при рефакторинге, выглядит так:
LOC — это и есть наше быстрое хранилище данных. В нем содержатся данные для сайта: файлы, изображения, свойства товаров, адреса складов/салонов.
В Enrich у нас уходят только свойства и адреса.
Вот так выглядит связка LOC-Enrich:
Результаты
На текущий момент вся система работает, и работает хорошо. Конкретно:
Если товар изменили на стороне LOC, то практически моментально идет обновление на всех сайтах (если очередь забита, самая долгое обновление занимало ~10 мин, ранее это могло занимать до 20 часов).
Мы уменьшили нагрузку на сервер и избежали пиковых нагрузок. Если раньше нагрузка росла пропорционально количеству языковых сайтов (каждый раз когда запускается новая языковая версия сайта, мы включаем еще один экземпляр скрипта для нового сайта), то теперь количество запущенных скриптов (воркеров) постоянно. Так же все обрабатывается параллельно и примерно вдвое меньше нагружает сервер.
Новое хранилище не просто быстрее, оно и еще и меньше. Раньше все свойства занимали место на сервере ~800Гб, то теперь ~300Гб.