Потолок производительности «Битрикс» и что делать, когда вы его достигли

Потолок производительности «Битрикс» и что делать, когда вы его достигли

Платформа «1С-Битрикс» для управления интернет-магазинами занимает лидирующую позицию среди ритейлеров российского рынка. Действительно, преимущества, которыми она обладает, для запуска магазина со средним объемом продаж неоспоримы:

  • быстрые сроки запуска интернет-магазина

  • оптимальная стоимость

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

  • встроенные интеграции с сервисами 1C

  • обширный набор встроенных функций для управления интернет-продажами

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

Спойлер - от Bitrix рано или поздно потребуется уходить.

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

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

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

Если онлайн-витрина уже столкнулась с проблемами производительности (периодической недоступностью в моменты пиковых нагрузок или, например, импортов товаров), то до перехода к следующим шагам следует стабилизировать работу backend-а. Сюда может входить:

  • доработка кэширования (усовершенствование существующего и добавление еще одного слоя) и правильной стратегии его прогрева

  • добавление или усовершенствование индексного хранилища для ускоренной выдачи данных

  • оптимизация запросов и взаимодействия с базой данных

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

Точный список зависит от состояния проекта.

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

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

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

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

3й этап - перевод frontend части интернет-магазина на новый современный технический стек. Современные технологии - Vue, React и т. п. легче кастомизируются и поддерживаются, лидеры рынка используют их в реализации своих проектов, однако, для работы с этими технологиями требуется API, чтобы выдавать нужные данные для формирования страниц. После перехода на микросервисную архитектуру не составит проблем реализовать API, чтобы передавать нужные данные на frontend и заменить его на современный стек. При этом есть другой путь - реализация API для перехода на другой стек frontend-а внутри Bitrix, но более оптимальным будет последовательное движение по обозначенным выше шагам с постепенным переходом на микросервисную архитектуру и уходом от “коробочного” решения frontend-части.

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

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

2
4 комментария

А как же масштабируемость и балансировка кластера? Вообще битрикс себя очень хорошо ведет и многое что можно разнести по разным серверам и т.д.
Не могу ничего сказать, однако микросервисы решение ровно такое же....
Да, в статье вы правы, если мы берем DNS - то тут битрикс не вывезет и т.д, но и статья - откровенная реклама микросервисов, которых уже написались с 2015 года.
Лучше бы написали на чем вы пишите - laravel, lumen, yii? Какие метрики у вас сейчас и какие были на битриксе? А так - статья реклама - фактов 0

2
1

Вадим, приветствую, спасибо за комментарий.

bitrixVM: решение верное (в рамках монолита), но так же требующее devops для обслуживания и настройки. Разделение на фронт+бек приложения даёт больше гибкости в использовании микросервисов и их балансировке. Волшебной кнопки "сделать хорошо и дёшево", к сожалению, не существует.

Если ИМ выходит на федеральный уровень, то нас уже не спасает шардирование БД или кеша - требуются решения, в которые заложено масштабирование. К примеру:
- ElasticSearch (поиск)
- Couchbase (кеширование)
- Kafka (очереди)
- gRPC (RPC С балансировкой)
- Log storage/engine (мониторинг)

Данные сервисы подразумевают не просто написание новых модулей, а скорее отказ от существующих.

В рамках Битрикса можно выделить и слабые стороны:
- ORM и DBAL: крайне слабое решение в отношении формирования как запросов, так и (де)гидрации объектов
- IoC или service locator (как вариант): отсутствует как понятие
- Локализация: требует оптимизации по слиянию, для уменьшения iops
- Отсутствие понятия репозиториев и хранения "рабочих" сущностей в рамках запроса, что порождает лишние выборки одних и тех же данных

1

У вас статья рекламная. Чтобы плясать на якобы уже почти трупе огромной системы - могли бы хотя бы статейку в оборот не пускать) ох уж эта "нативность" 🤣

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